Реализовать CANOpen на CAN МК Freescale DSP56F805, Разобрался с аппартным CAN, надо накрутить поверх CANOpen Опции

[Phantom_]

В этом МК есть аппаратный CAN интерфейс. С ним я разобрался, вот только могу пользоваться им лишь для связи с другим таким же МК.
А мне требуется интегрироваться в сетку с протоколом CANOpen.
Вопрос: Возможно ли такое выполнить ? И как ? Очень нужны базовые примеры и документы.
Сам я пока лопачу документацию. Но без вашего опыта буду долго возиться.
Уважаемое сообщество, прошу помощи.

[Седой]

В этом МК есть аппаратный CAN интерфейс. С ним я разобрался, вот только могу пользоваться им лишь для связи с другим таким же МК.
А мне требуется интегрироваться в сетку с протоколом CANOpen.
Вопрос: Возможно ли такое выполнить ? И как ? Очень нужны базовые примеры и документы.
Сам я пока лопачу документацию. Но без вашего опыта буду долго возиться.
Уважаемое сообщество, прошу помощи.

Документацию на что?

[AlexandrY]

CANopen так с бодуна не делается.
Помимо стека с реализацией коммуникационного уровня по спецификации DS301
нужно еще реализовать профиль из набора спецификаций DS4XX
Ну и еще понадобится конфигуратор на PC для формирования dcf файлов
Ну и менеджер сети нужен как минимум для отладки.
Т.е. солидный набор тулсов. Возьмите лучше готовый стек CANopen .

В этом МК есть аппаратный CAN интерфейс. С ним я разобрался, вот только могу пользоваться им лишь для связи с другим таким же МК.
А мне требуется интегрироваться в сетку с протоколом CANOpen.
Вопрос: Возможно ли такое выполнить ? И как ? Очень нужны базовые примеры и документы.
Сам я пока лопачу документацию. Но без вашего опыта буду долго возиться.
Уважаемое сообщество, прошу помощи.

[Phantom_]

Спасиб за мнение.
На данный момент смотрю в сторону CANFestival.

[Forger]

На данный момент смотрю в сторону CANFestival.

Тогда уж лучше CANopenNode - в нем исходники гораздо внятнее и есть хорошая документация по ним и примеры.
Хороший покупной стек стоит очень дорого. На практике не требуются абсолютно все фичи CANopen. Да и не так уж и сложен CANopen. А сложности в нем другого рода: перестраховки на самые "нелепые" случаи работы других узлов и самого мастера сети, исчерпывающий набор методов отправки/приема важных и критичных ко времени данных и т.п. Но в большинстве узлов (девайсов) это все не нужно и хватает основных базовых возможностей CANopen (например, см. стек от Microchip).

В моем случае я реализовывал CANopen slave самостоятельно (узлы для работы с ПЛК под CoDeSys).
На полное понимание CANopen ушло около двух недель. Вполне достаточно одного документа DS301 и какого-нибудь "профильного" документа, например, DS401.
Еще примерно месяц на реализацию (на С++ удалось отказаться от шаблонов).
Конечно похвастаю: у меня получилось абсолютно кросплатформенное решение, хотя это - и не цель.
Я не все сделал (просто не требуется для текущего проекта), но спроектирован практически весь стек CANopen. На одном кристалле могут абсолютно без ущерба друг другу работать более одного стека, каждый из которых может висеть на своем CAN драйвере (мне это нужно для реализации надежной сети с дублированием шин CAN - девайс далеко не бытового назначения).

Вот пример простейшего проекта на моей реализации стека:

Код

// Экземпляр драйвера для работы с платформой
TTargetSTM32    target;

// Экземпляр драйвера для работы с шиной CAN
TCANDriverSTM32    driver;

// Экземпляр протокола CANopen
TCANopenSlave    CANopenSlave;

// Обязательные (mandatory = M) и необязательные (optional = O) объекты устройства
TObject0x1000    deviceTypeObject;            // Регистр типа устройства (M)
TObject0x1001    errorRegisterObject;        // Регистр ошибок (M)
TObject0x1002    manufacturerStatusRegisterObject; // Регистр состояния от производителя  (O)
TObject0x1018    identityObject;                // Объект идентификации устройства (M)
TObject0x1400    receivePDO1_CommunicationParameter;

// ......

static unsigned numberOfRecievedFrames = 0;
static TCANFrame recievedFrame;

int main()
{
    CANopenSlave.run();

    for (;;)
    {
        while (numberOfRecievedFrames > 0)
        {
            numberOfRecievedFrames--;
            CANopenSlave.dispatch(recievedFrame);
        }
    }
}

// CAN RX0 interrupts requests
extern "C" void USB_LP_CAN_RX0_IRQHandler()
{
   numberOfRecievedFrames++;
   driver.getFrame(recievedFrame);
}

void TTargetSTM32::initialize() // Инициализация платформы
{
    setSystemFrequency(SYSTEM_FREQUENCY_72MHz);
// ..........
}

void TCANDriverSTM32::initialize() // Инициализация драйвера CAN
{
    _configuration.portNumber    = 0;
    _configuration.baudRate    = BR_1000Kbps;
}

void TCANopenSlave::initialize()
{
    _configuration.deviceNodeId    = 2; // TODO ????
    _configuration.driverHandle    = &driver;
    _configuration.targetHandle    = ⌖
}


void TObject0x1000::initialize()
{
    _deviceType.deviceDS401.digitalInputEnabled        = true;
    _deviceType.deviceDS401.digitalOutputEnabled    = true;
    _deviceType.deviceDS401.analogInputEnabled        = false;
    _deviceType.deviceDS401.analogOutputEnabled        = false;
    _deviceType.deviceDS401.specificFunctionality    = 0; // No specific function
}


void TObject0x1018::initialize()
{
    _deviceIdentity.productCode                = 0;
    _deviceIdentity.vendorID                = 0;
    _deviceIdentity.revisionNumber.major    = 1;
    _deviceIdentity.revisionNumber.minor    = 0;
    _deviceIdentity.serialNumber            = 0;
}

// ......

К сожалению, код я не могу выкладывать - меня за это... чи-чи.
Но, готов поделиться принципами реализации, если этого кого-то заинтересут. И с радостью выслушаю советы бывалых, да и просто советы, мнения.

Кстати, скажу по-секрету, военные и космические заинтересовались CAN-ом. И можно понять почему: в настоящее время в отечественной авиации, космосе и войне для связи девайсов используется старая шина MIL-STD-1553 (успешно "спертая" военными у янков аж в далеком 1973). Так вот, трансивер + контроллер этой шины для одного узла стоит минимум 1000$ !!! Все решение полностью покупается у янок. А в космосе это обходится и того больше. А цена решения CAN шины обойдется в 1000 руб (для военных) или того меньше, если военные/космос догадаются купить исходники CAN-контроллера и запихать их в рад-стойкую ПЛИС.

[syoma]

Так все-таки CANopenNode или CANfestival?
Что лучше, если надо реализовать и мастер и слейв?

[Serega]

По мне так CANopenNode будет попроще в реализации для контроллера, а вот для ПК надо CANfestival использовать.

[syoma]

Я имел ввиду, конечно контроллер. Например STM32F. Хоть и как сдесь сказали, CANopenNode лучше документирован, но на форуме CANFestival есть информация, что его достаточно легко можно портировать под STM.
Еще интересно - имеет ли смысл все это дело на CANpie заворачивать, или стандартных библиотек и функций достаточно?

[Serega]

А что такое CANpie?

[syoma]

Но, готов поделиться принципами реализации, если этого кого-то заинтересут. И с радостью выслушаю советы бывалых, да и просто советы, мнения.

Привет.
В общем я теперь вроде нахожусь на том уровне понимания стека, что как работает - понятно, но теперь вижу ущербность Open-source стеков и даже некоторых не-Opensource. Поэтому есть пара вопросов.
1. Я так понял что у Вас, как и у многих других реализаций, есть функция CANOPen.dispatch, которая должна циклически вызываться из главной программы и выполнять раскидку и создание PDO,SDO сообщений и реакцию на NMT. То есть время выполнения такой функции зависит от загрузки сети и точно не детерминировано - что мне как-то не нравится. Или это нормально?
2. Как у Вас выглядит Object Directory - просто массив данных одинаковой длины? Как вы к нему обращаетесь? Через функции, чтобы избежать порчи данных при чтении и чтобы CANopen знал, когда слать PDO? Или просто?
3. Как насчет NMT master и сервисов LSS. Реализовывали ли их?
4. Что посоветуете для первой попытки связи с CANopen устройством?
У меня есть CANanalyzer с IXXATшным USB адаптером. Как я понял, NMT и PDO сообщения я еще смогу сгенерить самостоятельно, но SDO - надо бы что-то получше. Я думал, действительно какой-нибудь ПЛК взять для экспериментов, но не могу понять, какой.
5. Вы брали какой нибудь стек за основу или полностью свой лепили?
6. Отправка сообщений - используете ли Вы какой-нибудь буфер или по одному шлете?

[Forger]

Поэтому есть пара вопросов.
1. Я так понял что у Вас, как и у многих других реализаций, есть функция CANOPen.dispatch, которая должна циклически вызываться из главной программы и выполнять раскидку и создание PDO,SDO сообщений и реакцию на NMT. То есть время выполнения такой функции зависит от загрузки сети и точно не детерминировано - что мне как-то не нравится. Или это нормально?

От загрузки сети это почти не будет зависеть, если отсев левых кадров будет производится еще в прерываниях по приему кадров.
Более того вызов dispatch я делаю в отдельной задаче RTOS по событию (сообщению) из прерывания по приему.
Разумеет, контроллер должен иметь достаточную производительность.
В RTOS есть анализ загрузки, типа профайлинг. Так что, все под контролем

2. Как у Вас выглядит Object Directory - просто массив данных одинаковой длины? Как вы к нему обращаетесь? Через функции, чтобы избежать порчи данных при чтении и чтобы CANopen знал, когда слать PDO? Или просто?

Нет, не массив. Список с абстрактным интерфейсом для доступа к объекту.
Т.е. TObject - полностью абстрактный класс, все методы - виртуальные.
CANopen стек имеет доступ ко всем объектам только через этот абстактный класс.
Подобное построение реализовано во всем стеке.

3. Как насчет NMT master и сервисов LSS. Реализовывали ли их?

Нет. Не требовалось. Но, если понадобиться, добавить недолго - стек построен прозрачно.

4. Что посоветуете для первой попытки связи с CANopen устройством?
У меня есть CANanalyzer с IXXATшным USB адаптером. Как я понял, NMT и PDO сообщения я еще смогу сгенерить самостоятельно, но SDO - надо бы что-то получше. Я думал, действительно какой-нибудь ПЛК взять для экспериментов, но не могу понять, какой.

Я использовал ПЛК от BECK@IPC: SC23/24. Среда CoDeSys.
http://www.beck-ipc.com

5. Вы брали какой нибудь стек за основу или полностью свой лепили?

Исключительно свой, по документам CANopen CIA.

6. Отправка сообщений - используете ли Вы какой-нибудь буфер или по одному шлете?

Разумеется, буфер. По передаче тоже. Более того, у CAN контроллера есть как правило свои аппаратные буферы.

[syoma]

CANopen стек имеет доступ ко всем объектам только через этот абстактный класс.
Подобное построение реализовано во всем стеке.

Я не имел ввиду со стороны стека, а как обстоит дело с доступом со стороны приложения?

Я использовал ПЛК от BECK@IPC: SC23/24. Среда CoDeSys.
http://www.beck-ipc.com

Можете подсказать во сколько это примерно обойдется по деньгам, если у меня ничего нету - ни железа ни софта под это дело.

[Forger]

Я не имел ввиду со стороны стека, а как обстоит дело с доступом со стороны приложения?

При объявлении класса объекта (TObjectXXX) он должен обязательно наследоваться от шаблона TObjectCustom<>.
При статическом (желательно) или динамическом объявлении экзэмпляра этого класса TObjectXXX, он автоматически включается в список объектов и доступен стеку через закрытые и уже реализованные самим стеком методы (для приложения они недоступны).
Для приложения необходимо реализовать лишь одну чисто виртуальную функцию updateInputs, которую будет вызывать сам стек CANopen, это обновляет выходные сигналы (со стороны узла), т.е. RPDO.
В самом классе TObjectXXX можно наделать сколько угодно своих методов, но для обновления входов (со стороны узла), т.е. TPDO,
необходимо в этих методах в нужных местах вызывать уже реализванную в TObjectCustom<> функцию updateOutputs.

Можете подсказать во сколько это примерно обойдется по деньгам, если у меня ничего нету - ни железа ни софта под это дело.

Я этого не могу сказать, поскольку я - не руководитель фирмы, а лишь ее сотрудник: платил не я
Одно знаю: преобразователь CAN-USB и софт (все от отечественной компании Марафон) обошелся в ~20 тыр.
Но этот вариант не советую, все ж лучше один раз раскошелиться на нормальный набор, например, от IXXAT.
Без сторонних железок и софта нормальный CANopen практически невозможно реализовать.

[syoma]

Я вот смотрю, что вы с STM32 работаете. Я тоже собираюсь на нем реализовывать.
Вопрос - у вас, я так понял, реализация с использованем ООП?
На CANopenNode - есть вариант обычной реализации и ООП - правда он еще полностью не протестеный, но доступный. Вот я и не понимаю, чего тот чел тоже перелез на объекты, если и без них все прекрасно работало. Зачем для микроконтроллера объектная реализация?
Или может есть весомые преемущества ООП реализации CANopen стека, по сравнению с обычной реализацией, с точки зрения понимаемости программы в будущем и расширяемости, если основное приложение будет оставаться обычным - без объектной реализации?

ПС. Я это спрашиваю еще потому, что посмотрел документацию на основные коммерческие CANopen стеки от IXXAT, Vector и т.д - там все без ООП. Но это наверное в угоду портируемости.

[garry_]

...
Одно знаю: преобразователь CAN-USB и софт (все от отечественной компании Марафон) обошелся в ~20 тыр.
Но этот вариант не советую, все ж лучше один раз раскошелиться на нормальный набор, например, от IXXAT.
..

А у кого вы купили за такую цену? На сайте марафона он 6 тысяч рублей стоит.

[Forger]

А у кого вы купили за такую цену? На сайте марафона он 6 тысяч рублей стоит.

5 тыр. коробка USB-CAN
15 тыр. софт: CANWize+CANopen (DLL-ка)
Год назад покупали

Я вот смотрю, что вы с STM32 работаете. Я тоже собираюсь на нем реализовывать.
Вопрос - у вас, я так понял, реализация с использованем ООП?

Ну, типа того

На CANopenNode - есть вариант обычной реализации и ООП - правда он еще полностью не протестеный, но доступный. Вот я и не понимаю, чего тот чел тоже перелез на объекты, если и без них все прекрасно работало. Зачем для микроконтроллера объектная реализация?

1. Простота реализации и отладки. Дешевле выходит, но требуются хороший навыки использования C++ и соотв. абстактное мышление. Мне последного слегка недостает
2. Простота применения в новом очередном проекте. Это факт. Проект выходит предельно прозрачным.
3. Б'ольшая безопасность применения, из-за преимуществ C++.
4. Меньший объем кода (на С будет тяжелее из-за больших проблем с правильным проектированием). Проверял.
Но данных (ОЗУ) нужно больше. Хотя и это решаемо.

Или может есть весомые преемущества ООП реализации CANopen стека, по сравнению с обычной реализацией, с точки зрения понимаемости программы в будущем и расширяемости, если основное приложение будет оставаться обычным - без объектной реализации?

В том-то все и дело, что если основное приложение тоже - ООП, то применения CANopen стека, RTOS (у меня C++ обертка для TNKernel, так намного удобнее), других стеков (TCP/IP, например) становиться намного удобнее и меньше ошибок.

Что-то типа этого:

Код

class TApplication
{
public:
//    TApplication(void);
    void initialize(void);
    void run(void);
    inline void synchronize(void) { _rtos.synchronize(); }

private:
    class TThreadCANopen : public TThread<THREAD_CAN_OPEN_STACK_SIZE>
    {
        virtual void initialize(void * bodyArgument);
        virtual void body(void);
        THardwareSTM32 *    _hardware;
        TCANopenSlave        _CANopenSlave;
        TEventSemaphore        _isRecievedCANFrame;
    };
    
    class TThreadLeds : public TThread<THREAD_LEDS_STACK_SIZE>
    {
        virtual void initialize(void * bodyArgument);
        virtual void body(void);
        TTargetSTM32 * _target;
    };

    class TThreadWatchDog : public TThread<THREAD_WATCH_DOG_STACK_SIZE>
    {
        virtual void initialize(void * bodyArgument);
        virtual void body(void);
        TTargetSTM32 * _target;
    };

private:
    TKernel            _rtos;
    TTargetSTM32        _target;
    TThreadCANopen        _threadCANopen;
    TThreadLeds        _threadLeds;
    TThreadWatchDog        _threadWatchDog;
};

void TApplication::initialize(void)
{
    _rtos.initialize();
    _target.initializeSystem(SYSTEM_FREQUENCY_72MHz);
    _target.initializeMainTimer(1); // Период 1 мс
    _target.initializePorts();
}


void TApplication::run(void)
{
//    _threadCANopen.run("CANopen", THREAD_CAN_OPEN_PRIORITY, &_target);
    _threadLeds.run(THREAD_LEDS_PRIORITY, &_target);
    _threadWatchDog.run(THREAD_WATCH_DOG_PRIORITY, &_target);
    _rtos.run(); // Never returns here
}




TApplication application;

int main()
{
   application.initialize();
   application.run();
}

extern "C" void SysTickHandler()
{
   application.synchronize();
}

void TApplication::TThreadLeds::initialize(void * bodyArgument)
{
   _target = (TTargetSTM32*)bodyArgument;
}

void TApplication::TThreadLeds::body(void)
{
   _target->setPinToLOW(PORT_LED_GREEN, PIN_LED_GREEN);    // Включить зеленый светодиод
   sleep(50);
   _target->setPinToHIGH(PORT_LED_GREEN, PIN_LED_GREEN);    // Выключить зеленый светодиод
   sleep(50);
}

void TApplication::TThreadWatchDog::initialize(void * bodyArgument)
{
   _target = (TTargetSTM32*)bodyArgument;
   _target->initializeWatchDogTimer(12); // Период сторожевого таймер 12 мс
}

void TApplication::TThreadWatchDog::body(void)
{
   _target->updateWatchDogTimer(); // Сбрасывать сторожевой таймер каждые 10 мс
   sleep(10);
}

ПС. Я это спрашиваю еще потому, что посмотрел документацию на основные коммерческие CANopen стеки от IXXAT, Vector и т.д - там все без ООП. Но это наверное в угоду портируемости.

Пожалуй,...
К тому же далеко не для всех процов есть C++ компилер.

[syoma]

Спасибо за ответ

5 тыр. коробка USB-CAN
15 тыр. софт: CANWize+CANopen (DLL-ка)

Ага, значит Вы еще и CANopen модуль к анализатору докупали.
Блин, а он дороже чем сам анализатор будет.

[Forger]

Ага, значит Вы еще и CANopen модуль к анализатору докупали.
Блин, а он дороже чем сам анализатор будет.

А как иначе?
По опыту работы с этим набором скажу, что CANopen DLL-ка от Марафон не особо нужна -
она там весьма упрощенная, поэтому все можно сделать без нее.
Достаточно купить софтину CANwize, впрочем, даже эта софтина не блещет удобствами.
Вполне можно написать софтину своими силами. Благо марафоновцы дают исчерпывающий
набор примеров и документации на USB-CAN коробку.
Однако, есть у этой коробки одна серьезная беда.
При очень интенсивном обмене по шине (1 МБит скорость, кадрый сыпяться без перерыва) -
эта коробка теряет кадры и получает некоторые битыми.
Буфер в ней забивается настоко, что драйвер не успевает выбирать все кадры.
Явные софтовые проблемы.
Я бы все-таки не советовал покупать этот вариант, несмотря на его очень низкую цену.
Если б я знал это раньше, то лучше попросил у кого-нить в долг за деньги нормальный набор от IXXAT или подобное.
Или вовсе убедил бы боссов купить этот набор.
А делать свою коробку USB-CAN не советую - на первых порах лучше, чем у марафон не выйдет, а обойдется намного дороже. Да и времени на это тоже нужно немало - много заморочек и косяков с софтовой частью: прошивка контроллера, драйвер под винду, софт для пользователя.

[Marathon]

По опыту работы с этим набором скажу, что CANopen DLL-ка от Марафон не особо нужна -
она там весьма упрощенная, поэтому все можно сделать без нее.
Вполне можно написать софтину своими силами. Благо марафоновцы дают исчерпывающий
набор примеров и документации на USB-CAN коробку.

По-видимому, Вы имеете ввиду CANopen анализатор. Это лишь один из модулей набора, который и должен быть достаточно простым. Ведь большинство CANopen протоколов являются "однокадровыми" т.е. поддерживаются одним CAN кадром канального уровня. Анализатор лишь интерпретирует такие кадры в терминах стандарта CANopen DS301.
Одним из достоинств анализатора является отслеживание контекста SDO обмена, в том числе для блочного протокола, который в большинстве свободных CANopen библиотек не реализован (вообще говоря, он и используется не очень часто). Вот это свойство без опыта программирования CANopen систем реализовать самостоятельно весьма непросто. Наибольшую пользу CANopen анализатор может принести как раз на начальном этапе освоения CANopen. Если Вы преодолели этот этап без помощи анализатора, в дальнейшем его ценность будет для вас снижаться (до определенной степени).

Достаточно купить софтину CANwize, впрочем, даже эта софтина не блещет удобствами.

Данная "софтина" является бесплатным приложением к любому CAN контроллеру Марафон и может быть загружена с сайта компании. Стоимость CAN-USB интерфейса - 5000 рублей без НДС, CANopen анализатора - 9500 рублей без НДС.

Однако, есть у этой коробки одна серьезная беда.
При очень интенсивном обмене по шине (1 МБит скорость, кадрый сыпяться без перерыва) -
эта коробка теряет кадры и получает некоторые битыми.
Буфер в ней забивается настоко, что драйвер не успевает выбирать все кадры.
Явные софтовые проблемы.
Я бы все-таки не советовал покупать этот вариант, несмотря на его очень низкую цену.
Если б я знал это раньше, то лучше попросил у кого-нить в долг за деньги нормальный набор от IXXAT или подобное.
Или вовсе убедил бы боссов купить этот набор.

Есть такая беда-проблема. Она связана с использованием устаревшего FTDI USB контроллера, а также с некоторыми ограничениями используемого USB протокола. У IXAAT контроллеров таких проблем нет - сказывается почти 15 летняя фора по CAN разработкам, да и возможность привлечь к ним заметно бОльшие ресурсы. Вместе с тем, отметим, что такая ситуация (минимум проблем) наблюдается лишь у CAN разработчиков первого эшелона (Vector, IXXAT). Нам доводилось сталкиваться с CAN-USB интерфейсом, также разработанным в Германии, который при переполнении буферов на максимальном CAN трафике просто и тихо зависал. Марафоновский контроллер, теряя кадры, не виснет, но ругается, сообщая о различных оверранах и прочих неприятностях.
В настоящее время Марафон выпускает новый вариант CAN-USB контроллера. Он является двухканальным и свободен от недостатка производительности, в том числе на максимальной скорости CAN сети 1 Мбит.

[Forger]

Данная "софтина" является бесплатным приложением к любому CAN контроллеру Марафон и может быть загружена с сайта компании.

Что ж, выходит, что набор от Марафон вообще самый дешевый!

Есть такая беда-проблема. Она связана с использованием устаревшего FTDI USB контроллера, а также с некоторыми ограничениями используемого USB протокола.

В настоящее время Марафон выпускает новый вариант CAN-USB контроллера. Он является двухканальным и свободен от недостатка производительности, в том числе на максимальной скорости CAN сети 1 Мбит.

Тоже за 5 тыр?


А не планируете CAN-ETHERNET коробку?
Очень была бы удобна.

[repairDV]

Можно вопрос чуть-чуть в сторону от темы. Я, вообще-то, пользуюсь CodeWarrior 8.2. В нём вроде CAN не программируется. Вы как его программируете?

[Forger]

Можно вопрос чуть-чуть в сторону от темы. Я, вообще-то, пользуюсь CodeWarrior 8.2. В нём вроде CAN не программируется. Вы как его программируете?

Компилятор и среда тут не имеют значения.
Какой контроллер?

[repairDV]

MC56F8037 Freescale. Насколько я знаю, там к CAN нужно что-то дополнительно в CodeWarrior.

[Forger]

MC56F8037 Freescale.

Заходите на сайте Freescale, качайте оттуда даташит на контроллер, примеры программ и т.п.
В CodeWarrior есть HELP и мануал.
Короче, RTFM

[Седой]

Что ж, выходит, что набор от Марафон вообще самый дешевый!

C чего бы это.

см. http://projects.caxapa.ru/?ID=23

Двухканальные на Cortex-M3 будут в районе 3000 - 3500 http://www.mcutool.ru/products/connectivit...ser/us-can.aspx

Одноканальные, недорогие ( но без пропуска пакетов) - 1500-2000 http://www.mcutool.ru/products/connectivit...n/uccanlhs.aspx

В начале июня начнем.

[garry_]

C чего бы это.

см. http://projects.caxapa.ru/?ID=23

Двухканальные на Cortex-M3 будут в районе 3000 - 3500 http://www.mcutool.ru/products/connectivit...ser/us-can.aspx

Одноканальные, недорогие ( но без пропуска пакетов) - 1500-2000 http://www.mcutool.ru/products/connectivit...n/uccanlhs.aspx

В начале июня начнем.

А софт какой ? Чето по ссылке не нашел, так железку можно за пару дней сделать, прицепить SJA1000 к FT2232HL (апноут даже есть)

[syoma]

см. http://projects.caxapa.ru/?ID=23

Двухканальные на Cortex-M3 будут в районе 3000 - 3500 http://www.mcutool.ru/products/connectivit...ser/us-can.aspx

Одноканальные, недорогие ( но без пропуска пакетов) - 1500-2000 http://www.mcutool.ru/products/connectivit...n/uccanlhs.aspx

В начале июня начнем.

IMHO - Это все игрушки для наколенных проектов. Сам в свое время такой CAN-анализатор купил - поигрался и на полку положил. Потому, что смысл не в железе а в софте.
Во первых драйвера - тот же адаптер от IXXAT имеет драйвера и под LabView и под MATLAB и библиотеки под C - куда хочешь его прилепить можно. А тот, что за 70$ - с каким софтом его можно будет использовать?
Тот же CANanalyzer - жалко, что нет взломаного, намного круче любого монитора, который идет в комплекте со всеми этими игрушками. Про более навороченые вещи типа CANopen модуля я вообще молчу - их просто для таких девайсов нет и не будет.
Так что, если на фирму брать - это 100% выкинутые на ветер деньги. Купите IXXAT CAN-to-USB - за 300$ и этот адаптер 10 лет будет работать и дрова на него всегда будут, а разработчики спасибо скажут. Эта инвестиция намного лучше.

[garry_]

IMHO - Это все игрушки для наколенных проектов. Сам в свое время такой CAN-анализатор купил - поигрался и на полку положил. Потому, что смысл не в железе а в софте.
Во первых драйвера - тот же адаптер от IXXAT имеет драйвера и под LabView и под MATLAB и библиотеки под C - куда хочешь его прилепить можно. А тот, что за 70$ - с каким софтом его можно будет использовать?
Тот же CANanalyzer - жалко, что нет взломаного, намного круче любого монитора, который идет в комплекте со всеми этими игрушками. Про более навороченые вещи типа CANopen модуля я вообще молчу - их просто для таких девайсов нет и не будет.
Так что, если на фирму брать - это 100% выкинутые на ветер деньги. Купите IXXAT CAN-to-USB - за 300$ и этот адаптер 10 лет будет работать и дрова на него всегда будут, а разработчики спасибо скажут. Эта инвестиция намного лучше.

+1

[syoma]

Привет. Если кому интересно.
Короче запустил я этот CANfestival на STM32F103. Заняло это дело 2 месяца подходов к компьютеру и чтения документации и аж 2 дня на перелопачивание драйверов на CAN контроллер и таймер. Исходники могу выложить.
Аж сам удивился, но буквально при первой компиляции эта штука запустилась и начала генерить heartbit и даже реагировать на NMT команды.
На следующий день запустил PDO обмен - тоже работает без проблем. Несмотря на приличную навороченность (стек занял 20кБ места в МК) стек пока выглядит довольно стабильно. Работает все - и SDO и PDO и NMT сервисы (на слэйве).
Вчера даже получилость прикрутить к нему запись параметров во FLASH, а-ля EEPROM. Правда не все скопом, а для заданных объектов при записи.
2 Штуки мне очень понравились по сравнению с CanOpenNode.
1. Во-первых тут есть редактор eds файлов (правда хитро устанавливается, но вполне сносно) который позволяет создать профиль своего устройства и затем по этой информации генерирует .с и .h файлы для стека и сам .eds файл. Работает очень не плохо. Созданные файлы просто копируются в проэкт и перекомпилируются, а eds файл скармливается программе - монитору CANopen шины. О ней дальше внизу.
2. Во-вторых CANfestival имеет намного более развитые возможности. Например программа пользователя общается со стеком только через глобальные переменные, которые являются объектами словаря. При приходе нового PDO переменные сами собой обновляются. При изменении переменной программой - нужно только выполнить функцию послыки PDO и CANfestival сам определит, какая переменная в какой PDO пойдет и нужно ли его слать. Даже по таймеру все работает.
В общем я доволен пока.
Кстати насчет программы. Есть такой сайт: http://www.canwizard.de Там можно скачать одноименную программу.
Она хоть и предназначена для лифтов, но достаточна полезна и для простых CANopen сетей. Она позволяет подключаться к CANopen сети, искать узлы, читать eds файлы, генерить NMT и LSS команды, общаться с любыми узлами по SDO протоколу и т.д. Даже софт по сети обновлять может. Правда лог файлы она не ведет. Единственное ограничение, что бесплатная версия может работать толька максимум с тремя узлами. Поддерживает она Vector, Ixxat, Peak адаптеры.

[Forger]

Короче запустил я этот CANfestival на STM32F103. Заняло это дело 2 месяца подходов к компьютеру и чтения документации и аж 2 дня на перелопачивание драйверов на CAN контроллер и таймер. Исходники могу выложить....

Было бы очень интересно взглянуть и сравнить!

[syoma]

Было бы очень интересно взглянуть и сравнить!

Дык чего там сравнивать - взял исходники на CANконтроллер и Таймер со всем известной библиотеки FWlib от ST. Все остальное - родное CANfestivalевское.
Ладно, исходники дров выложу вечером, так как я еще туда кучу всего приделал, чего в CANfestivale не было - запись и чтение параметров из EEPROM - приделал пример эмуляции от ST. Еще добавил управление светодиодиками по DS303-3.
Единственное - обработка Heartbeat в CANfestival не очень реализована - добавил обработчик ошибки по Heartbeatу.

Вот что хочется изменить - не нравится мне функция посылки сообщений от ST - в F103 есть всего три буффера, и если они полны, то новое сообщение можно потерять. Я думаю - либо сделать посылку блокируещей - чтобы все ждали пока сообщение отошлется, либо добавить FIFO буфер побольше.

[Forger]

Вот что хочется изменить - не нравится мне функция посылки сообщений от ST - в F103 есть всего три буффера, и если они полны, то новое сообщение можно потерять. Я думаю - либо сделать посылку блокируещей - чтобы все ждали пока сообщение отошлется, либо добавить FIFO буфер побольше.

Я тоже сталкивался с этой проблемой. Решил применением программного FIFO как на передачу и на прием заодно.

Ну, а щас сделано у меня по-другому: использование RTOS позволило использовать ее встроенные сервисы для работы очередями сообщений. А обертка вокруг них создана на базе smart pointer (только C++). Теперь не нужно беспокоиться за валидность указателя на очередное сообщение: если хоть кто-то его еще использует, оно лежит в буфере. А как только все, кому нужно было сообщения, "отстали" от него - это сообщение автоматом освобождается из очереди. Работает изумительно! Оптимизатор компилятора прекрасно работает, удаляя, казалось бы, избыток кода.

[syoma]

обертка вокруг них создана на базе smart pointer (только C++).

К сожалению, мне это пока не грозит. Мне пока достаточно мучений с обычными С указателями.

[Forger]

К сожалению, мне это пока не грозит. Мне пока достаточно мучений с обычными С указателями.

Я тоже мучался на чистом С, пока не начал всерьез осваивать С++ не под ПК, а именно под обычные МК.
После перехода, полного перехода на С++, многие детские болезни из С по-просту отпали

[DmitryDI]

Привет. Если кому интересно.
Короче запустил я этот CANfestival на STM32F103. Заняло это дело 2 месяца подходов к компьютеру и чтения документации и аж 2 дня на перелопачивание драйверов на CAN контроллер и таймер. Исходники могу выложить.
Аж сам удивился, но буквально при первой компиляции эта штука запустилась и начала генерить heartbit и даже реагировать на NMT команды.
На следующий день запустил PDO обмен - тоже работает без проблем. Несмотря на приличную навороченность (стек занял 20кБ места в МК) стек пока выглядит довольно стабильно. Работает все - и SDO и PDO и NMT сервисы (на слэйве).
Вчера даже получилость прикрутить к нему запись параметров во FLASH, а-ля EEPROM. Правда не все скопом, а для заданных объектов при записи.
2 Штуки мне очень понравились по сравнению с CanOpenNode.
1. Во-первых тут есть редактор eds файлов (правда хитро устанавливается, но вполне сносно) который позволяет создать профиль своего устройства и затем по этой информации генерирует .с и .h файлы для стека и сам .eds файл. Работает очень не плохо. Созданные файлы просто копируются в проэкт и перекомпилируются, а eds файл скармливается программе - монитору CANopen шины. О ней дальше внизу.
2. Во-вторых CANfestival имеет намного более развитые возможности. Например программа пользователя общается со стеком только через глобальные переменные, которые являются объектами словаря. При приходе нового PDO переменные сами собой обновляются. При изменении переменной программой - нужно только выполнить функцию послыки PDO и CANfestival сам определит, какая переменная в какой PDO пойдет и нужно ли его слать. Даже по таймеру все работает.
В общем я доволен пока.
Кстати насчет программы. Есть такой сайт: http://www.canwizard.de Там можно скачать одноименную программу.
Она хоть и предназначена для лифтов, но достаточна полезна и для простых CANopen сетей. Она позволяет подключаться к CANopen сети, искать узлы, читать eds файлы, генерить NMT и LSS команды, общаться с любыми узлами по SDO протоколу и т.д. Даже софт по сети обновлять может. Правда лог файлы она не ведет. Единственное ограничение, что бесплатная версия может работать толька максимум с тремя узлами. Поддерживает она Vector, Ixxat, Peak адаптеры.

Добрый день!

Я так же запустил CANfestival в AT90CAN128. Все как бы работает. Но непонятен ряд вещей. Если с контролер в мастер шлеца PDO, то как контроллер узнает о том, что PDO дошло – в программе CAMmonitor – никаких подтверждений я не видел? Как этим протоколом передавать большие объемы данных – есть ли стандартные профили? Как передавать метку времени?
C уважением

[syoma]

Если с контролер в мастер шлеца PDO, то как контроллер узнает о том, что PDO дошло

Насколько я понял PDO протокол - подтверждения в нем не предусмотренно. То есть - никак. Но как пишут умные книжки - в этом нет смысла, так как применение PDO подразумевает применение Heartbeat - то есть мониторинга состояния узлов. И если принимающий узел будет мониторить все узлы, с которых он принимает PDO, то вероятность непринятия PDO будет весьма низка.
Также можно настроить event таймер, чтобы PDO передавалось не только по изменению, но и периодически.

Как этим протоколом передавать большие объемы данных

PDO для этого не предназначен. Смотрите SDO - это типа peer-to-peer соединения. По нему можно передавать большие объемы данных. Вроде в CANfestival реализован и клиент и сервер, но я еще не разбирался.

[slimjack]

Добрый день!
Не хотел плодить новые ветки и решил написать сюда, т.к. похоже тут собрались знатоки CANopen.
Не ругайте сильно (возможно будут глупые вопросы), но очень хочется получить простое, доступное объяснение основ CANopen. Я перерыл форум, почитал стандарты, читал статьи, но все равно как-то все смутно. Правда я не разглядывал исходники (CANfestival и CANopenNode).
Попытаюсь объяснить как я понимаю CANopen, попутно задавая вопросы в непонятных местах.


Итак, пользовательское приложение не видит сеть напрямую - оно видит словарь обектов, который представляет собой массив переменных, которые связаны с параметрами, допустим, технологического процесса (температуры, токи и т.д.), а также с параметрами настройки режимов работы самого устройства. Т.е. (как я понимаю) часть словаря - личные данные конкретного устройства, а другая часть - общие данные всей сети (т.е. такие же данные могут находиться и в словаре другого устройства). Т.о. пользовательскому приложению не нужно знать о существовании сети, оно просто берет данные из словаря (например, чтоб узнать текущую влажность воздуха) или записывает данные в словарь (например, давление масла, если это давление измеряется непосредственно данным устройством). Перемещением данных между словарями занимается CANopen.
Обмен между словарями производится посредством сетевых объектов PDO и SDO.
PDO сообщения могут переносить до 8 байт полезной информации и используются для передачи данных о тех. процессе. PDO являются широковещательными сообщениями. Источником (производителем) PDO должно быть устройство которое непосредственно вычисляет или измеряет какой-то параметр, входящий в PDO. Каждый PDO имеет свой уникальный идентификатор (именно он и указывается в качестве идентификатора в сообщении CAN). Т.о. устройство измеряет какие-то параметры и пишет их в словарь. В этом же словаре хранится информация о том, какие данные, в каком порядке и в какое PDO нужно упаковать. Также для каждого PDO существуют правила отправки в сеть (по времени, по изменению, по синхроимпульсу и т.д.). Если выполняется условие отправки, CANopen упаковывает данные со словаря в PDO и отправляет их в сеть. Другие устройства в сети, если они настроены на прием данного PDO (определяется по идентификатору), принимают это PDO и распихивают его содержмое по словарю в определенные ячейки. Теперь вопрос: для чего разделяются PDO на входящие и исходящие (Rx Tx)? Правильно ли я понял, что идентификатор PDO не подразумевает привязки к устройству (т.е. в нем отсутствует информация, о том кто именно в сети отправил PDO)?

Если требуется передать какую-то часть словаря размером более 8 байт, необходимо применять SDO сообщения.
Существует два типа SDO (для передачи информации и для подтверждения). В виду необходимости подтверждения SDO подразумевает только соединение точка-точка. Через SDO одновременно передается только один объект словаря (а в PDO можно несколько), но он может быть большим (более 8 байт).
Дальше у меня практически одни вопросы.
1. При передаче SDO, что из себя представляет идентификатор сообщения? Есть ли в нем адрес конкретного устройства?
2. Какое отношение приложение имеет к SDO?
3. Как устанавливается связь между SDO и объектом словаря?

Просьба - разъясните мне "на пальцах", я не смог найти ответы на свои вопросы из спецификаций.

[Ruslan1]

вы очень все внятно разложили по полочкам

Мой опыт разработки кэн-приложения был таков:

Исходники
1) использовал CANopenNode. У меня тоже PIC-процессор, но другой. Но переписывать ничего не пришлось, забегало сразу.
2) там же редактор словаря, мощная штука, без этого загнулся бы. Но нужен FireFox.
3) даже автора нашел на каком-то форуме, на письма очень быстро отвечает

Документация по протоколам
1) протоколы запросил прямо на их сайте (www.can-cia.org) при регистрации. Любопытно, они очень внимательно проверяют чего там в регистрации им пишут. Мне прислали запрос, почему указанный мной почтовый адрес не совпадает с адресом, написанном на указанном мной www сайте. Для ускорения позвонил им голосом, объяснил, через 10 минут все выслали
2) советую посмотреть также профили, если подойдет готовый- то меньше придумывать придется.
3) ну конечно и дополнительно неофициально гуляющими версиями документации пользовался.
4) посмотрите аппноты, мне помогло: http://www.microcontrol.net/en/know-how/canopen.html
5) еще цикл статей "CAN basics", 8 частей : http://www.can-cia.de/index.php?id=66 ( от "CAN basics: CAN in Automation history and CAN, part 1 of 8" до "CAN basics: Traffic control, part 8 of 8")

Внутрь исходников практически не лазил, по мелочам под себя дорисовывал (ну и LSS протокол написал). Как результат- от запроса документации до сдачи пилот-проекта прошел месяц (вместе с железом). Супербыстро, учитывая что до этого ничего с кэном я вообще не делал.

Правильно ли я понял, что идентификатор PDO не подразумевает привязки к устройству (т.е. в нем отсутствует информация, о том кто именно в сети отправил PDO)?

ага.

Я не пользовал SDO, про это не подскажу. А Вы уверены что оно Вам надо (SDO)?

[slimjack]

А Вы уверены что оно Вам надо (SDO)?

В сети предполагается два "умных" устройства. Одно собирает инфу с цифровых датчиков, а второе - тоже что-то типа датчика, но оно собирает высокочастотные куски осциллограмм (т.е. размер большой, до 1 Мб) и некоторые из них отправляет на первое устройство. Т.е. без SDO никак.

По поводу PDO можете подсказать для они чего разделяются на входящие и исходящие (Rx Tx)? Какой смысл? Я пока для себя понял, есть PDO с каким-то идентификатором. Он попадает в сеть (неважно откуда) и тот, кому надо, подбирает его. Зачем тут делить на входящие и исходящие?

У меня есть устройство (датчик) с контроллером ATTiny (128 б ОЗУ), получится ли реализовать хоть что-нибудь от CANopen?

[Forger]

По поводу PDO можете подсказать для они чего разделяются на входящие и исходящие (Rx Tx)? Какой смысл? Я пока для себя понял, есть PDO с каким-то идентификатором. Он попадает в сеть (неважно откуда) и тот, кому надо, подбирает его. Зачем тут делить на входящие и исходящие?

У каждого узла в сети CANopen есть всегда 4 TPDO и 4 RPDO. Данные, которые отправляются узлом в сеть - именуются TPDO, принимаемые из сети - RPDO. Какие именно данные (точнее, объекты словаря) в них входят - настраиваются один раз после сброса устройства мастером сети CANopen (в подавлющем числе случаев мастер всегда один) через SDO. Далее настроенные таким узлы мастер переводит в состояние Operational, в котором данные уже идут к узлу и от узла только по PDO (в подавлющем числе случаев). CANopen практически не используются для передачи огромных массивов данных. Для этого лучше сделать свой простой протокол, используя шину CAN. Хотя в документации на CANopen я находил такой объект словаря, предназначенный для удаленной смене прошивки узла.

У меня есть устройство (датчик) с контроллером ATTiny (128 б ОЗУ), получится ли реализовать хоть что-нибудь от CANopen?

Все возможно
А вам так важен именно CANopen?
Я бы в вашем случае значительно быстрее "накидал" свой простенький протокольчик для указанной задачи, чем пытался бы использовать CANopen, т.к. на это у меня вышло бы гораздо больше времени и сил.
Исключение составляет тот случай, когда ваш узел должен встраиваться в УЖЕ существующую сеть CANopen.
Распишите по-подробнее сеть, в которой все это будет делаться. Какие узлы, сколько их всего?

[slimjack]

Все равно не понял на счет PDO.

У каждого узла в сети CANopen есть всегда 4 TPDO и 4 RPDO.

Значит все-таки в идентификатор PDO закладывается nodeID? Но зачем? Кому нужно знать с какого узла пришли данные?

Данные, которые отправляются узлом в сеть - именуются TPDO, принимаемые из сети - RPDO.

Кому нужна информация о направлении сообщения? Зачем разделять на входящие и исходящие? Если устройство передает PDO, то, естественно, оно знает, что для него это сообщение исходящее. И совсем непонятно, что такое входящее сообщение? Что устройство с nodeID=99 может принимать только те PDO, в идентификаторе которых зашит nodeID=99? А если оно хочет принять PDO от других устройств в сети?

А вам так важен именно CANopen?

Ну может в первом варианте нет, но в итоге понадобится гибкость и совместимость.
Проектируется распределенная система сбора данных. Разрабатывается не одно устройство, а несколько - контроллер и несколько типов датчиков. Предполагается возможность использования устройств ввода-вывода сторонних производителей (хотя это не обязательно). Но система должна быть масштабируема и универсальна. Если разрабатывать свой протокол, в итоге получу исковерканую версию какого-нибудь стандартного протокола. Зачем тогда мучаться - можно использовать уже готовый протокол.

И по поводу SDO. Правильно ли я понял - каждому узлу в сети назначается по 2 SDO (не более)?

[Forger]

Значит все-таки в идентификатор PDO закладывается nodeID? Но зачем? Кому нужно знать с какого узла пришли данные?

CANopen изначально проектировался для ОДНОГО мастера и кучи узлов.
Поэтому в RPDO nodeID хранит тот узел, которому это PDO предназначен. TPDO - от какого узла эти данные идут, чьи они.
Так мастер и другие узлы точно знают предназначение кадров.

Кому нужна информация о направлении сообщения? Зачем разделять на входящие и исходящие? Если устройство передает PDO, то, естественно, оно знает, что для него это сообщение исходящее.

Если вам не нравиться или не понятна логичность CANopen - используйте другой протокол или пишите свой.
В сети полно инфы по CANopen, даже на русском, ищите, и все получится

И совсем непонятно, что такое входящее сообщение? Что устройство с nodeID=99 может принимать только те PDO, в идентификаторе которых зашит nodeID=99? А если оно хочет принять PDO от других устройств в сети?

Изначально в шине CAN ВСЕ узлы могут принимать ВСЕ кадры. CANopen тут не накладывает ограничений.

Проектируется распределенная система сбора данных.

Если уж так нужен CANopen, то есть простое решение (я сам делал что-то подобное): через один PDO организовать свой минипротокол: например, 1-й байт (а всего из в PDO может быть до 8 включ.) - код команды, 2..4 байты - адрес, 5...8 байты - 32-битное слово данных. А в конце желательно передавать контрольную сумму всего массива данных. По SDO выйдет значительно дольше.

p.s. Я вижу, что вам пока туго даются даже базовые понятия CANopen. Поэтому, может оказаться, что эта задача вам пока что будет не по силам. Особенно если сроки жесткие.
Но, в любом случае, желаю удачи

[slimjack]

Если вам не нравиться или не понятна логичность CANopen

Дело не в этом-просто не до конца понятна идеология.
Но спасибо за советы. Буду копать дальше.

[syoma]

CANopen изначально проектировался для ОДНОГО мастера и кучи узлов.

Откуда Вы это взяли? CANopen никак не лимитирует мультимастерность CANа, а наоборот ее расширяет.
PDO расширяются на исходящие и входящие по одной простой причине - так их легче обрабатывать в устройстве. А на самом деле каждый PDO уникален - имеет свой идентификатор и набор данных. Разделение сделано для того, чтобы пользователь знал - источником данного PDO может быть только один узел в сети. В нем и настраивается TPDO с определенным идентификатором - необязательно соответсвующему адресу узла и совсем необязательно ограничение в 4шт на узел. Может быть и 8 и 100 TPDO в одном узле. Приемником же данного PDO могут быть множество узлов в сети. Чтобы они начали принимать это PDO - в них настраивается RPDO с таким же идентификатором, как уже указанное TPDO. Таким образом устанавливается связь между узлами.
А насчет SDO обмена - к сожалению в моей системе он нужен только для конфигурации. И для этого есть комп с купленной конфигурационной программой и CAN-адаптером. Когда я запустил CANfestival, SDO обмен заработал сразу и комп увидел мои устройства и смог обмениваться с ними по SDO. Как он это делает, я к сожалению не вникал.
Но по идее SDO - это как доступ через заднюю дверь ко всему словарю. Поэтому:

2. Какое отношение приложение имеет к SDO?

У меня - никакого. Т.е SDO обмен производится вообще без участия приложения. Так как при этом сам стек обрабатывает сообщения и посылает ответ.

3. Как устанавливается связь между SDO и объектом словаря?

Тот кто спрашивает - сам определаяет какой объект он хочет прочитать или записать.

Я не могу сказать, как все это дело будет работать с данными объемом 1Мб. Но с меньшими данными это работало так:
У меня было желание присвоить имя плате. В итоге я создал тектовый объект в словаре с тектом: "Тестовая плата №1. Разработчик ФИО"
В eds файле этот объект был описан, как текст с неопределенной длиной.
Размер этого обхекта более 8 байт. Естественно через PDO я его не передавал и ничего в программе с ним не делал. Но когда конфигурационная программа с компа сконнектилась с моим устройством, то она просканировала весь словарь согласно eds файлу и прочитала мой текст - я его увидел на компе. Как она это сделала - без малейшего понятия. Но это работает!

Есть неплохой интернет курс по CANopen - я постараюсь ссылку найти.
Ну и все спецификации есть тут, для Своих.

[slimjack]

Спасибо!
Похоже, что уже для меня все стало ясно.
Еще вопрос - словарь ограничивает объем данных для одной ячейки или нет? Можно ли тот же 1 Мб в нем хранить?

Есть неплохой интернет курс по CANopen - я постараюсь ссылку найти.

Буду благодарен!

[Forger]

Откуда Вы это взяли?

Я имею ввиду самые ранние версии CANopen. Когда еще не было такого кол-ва DS4xx. Впрочем, я могу ошибаться, т.к. очень давно это было.

совсем необязательно ограничение в 4шт на узел. Может быть и 8 и 100 TPDO в одном узле.

Да, это так. Максимум 512 TPDO и 512 RPDO (128 узлов * 4 в каждом узле).
Но четыре PDO железно зафиксированы за одним nodeID. Но, если узел хочет больше PDO, то он может "заимствовать" PDO из других nodeID. Т.е. занять больше, чем один nodeID. Проблема возникнет, если к сети поключать тот самый узел, nodeID которого уже кто-то использует. Тут сеть усложняется. Для отлавливания таких непрятностей нужен доп. софт, например, IXAAT.
Одна из прелестей CANopen в том, что в одну и ту же сеть можно подключать узлы разных производителей. Поэтому, чтобы не мучиться с настройкой сложной сети, где много nodeID принадлежит одному узлу, производители узлов (коробочек) по-умолчанию настраивают их на четыре пары PDO. Так железно все будет работать. Остальные извращения делает юзер. Я говорю про "коробочки", которые используются в промышленной автоматизации. Всякие там ПЛК (PLC). Узлы там маленькие как внешне, так и по трафику - несколько релюшек, какой-нить концевик, датчик. Т.е. на один узел никогда не вешается стопитсот видеокамер с HDTV трафиком Но узлов может быть довольно много, обычно до 20..30.

Но по идее SDO - это как доступ через заднюю дверь ко всему словарю.

Точно, но, к сожалению (может, даже к лучшему), SDO транзакции идут однократно после сброса узла или подачи ему питания.
В принципе, можно "обмануть" стек CANopen и в этом случае - узлу просто нужно "имитировать" то, что он якобы сбросился. В этом случае SDO посыпяться от мастера заново, все! (точнее только те, которые прописаны в конф. файл к конкретному узлу).
В этом случае можно уже "подсовывать" в один и тот же объект словаря уже другие данные.
Но представьте себе трафик по шине! И как себя поведет мастер при таких "фортелях" некоторых узлов - неизвестно.
Короче, через SDO слать периодически изменяющиеся данные, на мой взгляд, не очень разумное решение. Для этой цели как раз и предназначен PDO.

[syoma]

Но четыре PDO железно зафиксированы за одним nodeID.

Не железно, а назначены ему по умолчанию. Их идентификаторы обычно можно спокойно поменять. Хотя, наверное в самых убогих реализациях они могут быть привязаны и железно к номеру узла. Я таких пока не встречал.

Поэтому, чтобы не мучиться с настройкой сложной сети, где много nodeID принадлежит одному узлу, производители узлов (коробочек) по-умолчанию настраивают их на четыре пары PDO.Так железно все будет работать.

Так железно все как раз будет не работать. TPDO еще будут назначены правильно, но RPDO по умолчанию настроены в пустоту. Ведь по умолчанию RPDO тоже имеют идентификаторы, привязанные к этому узлу и отличные от всех TPDO, естественно PDO с такими идентификаторами слать будет некому. А на самом деле RPDO наоборот нужно настроить на PDO других узлов, чтобы узел начал их слышать. Это тот минимум, который нужно настроить, чтобы CANopen сеть начала работать.

Точно, но, к сожалению (может, даже к лучшему), SDO транзакции идут однократно после сброса узла или подачи ему питания.
В принципе, можно "обмануть" стек CANopen и в этом случае - узлу просто нужно "имитировать" то, что он якобы сбросился.

Я чего-то не понимаю, че Вы имеете ввиду. SDO обмен возможен всегда. Ничего узлу имитировать не надо.
Нужен просто будет периодический поллинг от мастера конкретного объекта словаря. Или даже проще. Узел должен послать мастеру PDO, что новые данные готовы и их можно загрузить. После этого сообщения мастер инициирует SDO запрос и скачивает не спеша новую инфу в 1Мб из узла. Вот и все.

Кстати вот ссылка:
http://www.softing.com/home/en/industrial-...vanchor=3010572

[Forger]

Не железно, а назначены ему по умолчанию. Их идентификаторы обычно можно спокойно поменять. Хотя, наверное в самых убогих реализациях они могут быть привязаны и железно к номеру узла. Я таких пока не встречал.

Вот структура CAN кадра:

В них из 11 бит cobID 7 отводятся под номер узла (0...127), а старшие 4 бита определяют тип протокола.
из 16 возможных значений этих 4-бит восемь значений отводятся под PDO (4 пары PDO).
Это сделано железно и изменить их нельзя. Суть большего числа PDO на один узел в том, что сам узел может занять под себя не один номер из nodeID, а несколько, и именно их дополнительно к своему родному nodeID и использовать как свои PDO. В принципе в сети может существовать один узел, занимающий все 512 пар PDO.
Кстати, для передачи кучи объектов словаря через один PDO существует еще MPDO (multiplexed). Что-то типа минипротокола поверх PDO.

Так железно все как раз будет не работать.

Под железно я подразумеваю типовую реализацию CANopen в промышленной автоматизации. Например, в CoDeSys (codesys.com) чтобы использовать SDO в ПЛК (обычно он мастер), нужно лезть в глубины их библиотеки CANopen. А PDO доступны через удобный графический конфигуратор прямо в среде CoDeSys. Юзеру так удобнее. Повторюсь, такая реализация очень удобна в относительно простых сетях пром. автоматизации.

Я чего-то не понимаю, че Вы имеете ввиду. SDO обмен возможен всегда.

Согласен, тут я перепутал с PDO: в режиме PreOperational PDO не доступен, но доступен SDO. А в рабочем режиме - Operational - доступен не тока PDO, но и SDO.
Но в том же моем любимом CoDeSys чтобы использовать SDO, нужно лезть в дебри их (3-S Software) библиотеки, доку на которую они не дают обычным юзерам. Юзеру же доступны только PDO, а точнее - объекты словаря более 0x6000.
Можно выбрать те, которые у узла будут использоваться (т.е. реализовано динамическое маппирование PDO). Все это делается в соотв. окошках среды, весьма удобно, т.к. в этом случае шину CANopen может настроить малообразованый юзер. Это выгодно и удобно.
Ежели все узлы в сети самописные, то тут я согласен, лучше делать, как вы описали - одим PDO сообщать мастеру о свежих данных, а через SDO их забирать.

[syoma]

В них из 11 бит cobID 7 отводятся под номер узла (0...127), а старшие 4 бита определяют тип протокола.
из 16 возможных значений этих 4-бит восемь значений отводятся под PDO (4 пары PDO).
Это сделано железно и изменить их нельзя.

То что Вы привели - это так называемый Predefined Connection Set - параметры по умолчанию, которые имеют устройства при первом включении в сеть.
http://www.softing.com/home/en/industrial-...vanchor=3010650
Из этих параметорв только SDO и NMT сообщения должны иметь фиксированные и привязанные к Node-ID идентификаторы. Идентификаторы остальных сервисов пользователь может спокойно менять. Кстати в некоторых профилях CANopen есть PDO, идентификаторы которых - фиксированны и не зависят от номера узла.
Параметры по умолчанию просто сгенерированы для того, чтобы устройства не конфликтовали между собой при первом включении.
Я смотрю Вы описание какого-то ПЛК читаете, у которого все ограничено пром.автоматизацией и юзеру не разрешены самовольности, чтоб он там ничего не натворил. А надо читать сам стандарт.
CANopen не ограничен автоматизацией - есть еще профили для лифтов, кранов, грузовиков и куча всего - где использование PDO более гибкое, чем в автоматизации.

[Forger]

Из этих параметорв только SDO и NMT сообщения должны иметь фиксированные и привязанные к Node-ID идентификаторы. Идентификаторы остальных сервисов пользователь может спокойно менять. Кстати в некоторых профилях CANopen есть PDO, идентификаторы которых - фиксированны и не зависят от номера узла.

Под nodeID - я подразумеваю не просто некий номер узла в сети, а конкретное содержимое 7 младших бит cobID. Поэтому и утверждаю, что на каждый конкретный nodeID отводится железно 4 пары PDO. Но, повторюсь, узел с конкретным nodeID может использовать PDO, по-умолчанию пренадлежащие другим nodeID. Т.е. всего в одной сети CANopen может быть максимум 512 пар PDO, которые могут быть как угодно распределены между всеми узлами этой сети.
Мы, похоже, говорим одно и то же , но разными словами

[slimjack]

А что если узел с одним nodeID будет использовать все 8 PDO на передачу? Какие проблемы тут возникнут?

[syoma]

А что если узел с одним nodeID будет использовать все 8 PDO на передачу? Какие проблемы тут возникнут?

Никаких. Каждый узел может задать до 512 различных PDO на передачу и 512 PDO на прием.
Для них даже свои адреса под коммуникационные параметры выделены. http://www.softing.com/home/en/industrial-...vanchor=3010610
Единственное, что количество одновременно используемых PDO ограничивается возможностями стека. Для каждой реализации это пишется в спецификации. Коммерчесские стеки, обычно, поддерживают до 512шт, как в спецификации CANopen.
http://www.ixxat.com/canopen_stack_en.html
Есть урезанные модификации - http://www.canopenstore.com/pip/microcanopen.html
Бесплатные - еще меньше.
В CANopennode - помоему 8 шт возможно.
Но в любом случае Ваше устройство должно в eds файле указать - сколько конкретно PDO штук оно поддерживает путем указания, какие адреса в области 1400h-1BFFh существуют.

[slimjack]

Т.е. 512 PDO одного направления - это чисто такая договоренность для конкретизации структуры словаря (ну или способа настройки узлов)?!
Изначально я думал, что возможен такой вариант: допустим, в сети всего два устройства и объявлены 1024 PDO. Одно из устройств является производителем всех этих 1024 PDO, а другое является потребителем этих же 1024 PDO. Т.о. у одного устройства обьявлено 1024 TPDO, а у другого - 1024 RPDO (с теми же идентификаторами).

Попытаюсь еще одним способом выразить как я себе представляю PDO в CANopen. В сети возможно существование 1024 PDO с различными идентификаторами (тут вроде все ясно). Эти PDO периодически возникают в сети и тот кому интересен тот или иной PDO вылавливает его и обрабатывает. А возникают PDO в сети благодаря производителям этих PDO. Т.о. возможно просто 1024 PDO, а какие они Tx или Rx - зависит кто с этим PDO работает: для производителя - это TPDO, а для потребителя - это RPDO. А то, что в CANopen описано 4 PDO на вход и 4 PDO на выход - это всего лишь рекомендации (которые меня сбивают с толку). Может быть 0 на вход и 8 на выход, или 200 на вход и 0 на выход.

Правильно ли я понимаю?

[Forger]

у одного устройства обьявлено 1024 TPDO, а у другого - 1024 RPDO

Арифметика здесь простая:
В CAN кадре из 11 бит cobID 7 бит идут на идентификатор (0...127), 2 бита - на номер пары PDO (0...3), и 1 бит - направление PDO (RPDO или TPDO).
Всего выходит 10 бит, 2^10 = 1024 PDO (512 RPDO + 512 TPDO).
http://electronix.ru/forum/index.php?act=a...st&id=53581

Единственное, что количество одновременно используемых PDO ограничивается возможностями стека.

Это точно! На каждый поддержанный PDO мастер сети должен выделить кусок памяти для обслуживания этого PDO.
Делается это либо статически, или динамически, но однократно при запуске стека.
Т.о. памяти 512x2 PDO кушают довольно много, особенно, если PDO требуют таймера (циклическая передача).
Да и на обслуживание такого массива требуется недюженных ресурсов проца. Такая реализация потянет тока довольно мощном проце.
С другой стороны, процы щас стали намного быстрее (в смысле, микроконтроллеры), дешевле и ОЗУ у них стало уже довольно.
Поэтому может и заработать на обычном дешевом ARM-е, например, на каком-нить Cortex-M3, коих щас навалом.
Но мне все же нравиться идея syoma: использовать PDO для сигнализации свежих данных от узла, а по SDO их забирать у узла. Размер таких данных, в теории, ничем не огораничен.

[slimjack]

1 бит - направление PDO (RPDO или TPDO)

Не понял. Допустим, устройство с nodeID 05h посылает в сеть сообщение PDO, например, с номером b0011 (согласно таблицы). Т.о. у устройства с nodeID 05h есть TPDO с идентификатором 185h. Где-то в сети есть устройство с nodeID 06h и оно хочет принять PDO с идентификатором 185h. Но у этого PDO бит направления установлен на передачу. Как быть? Я к тому - зачем нужен этот бит направления? Если для того, чтобы принять сообщение, его придется прогигнорить?

Может я тут глупые вопросы задаю, но хочется до конца все хорошо понимать.

[Forger]

Не понял. Допустим, устройство с nodeID 05h посылает в сеть сообщение PDO, например, с номером b0011 (согласно таблицы). Т.о. у устройства с nodeID 05h есть TPDO с идентификатором 185h. Где-то в сети есть устройство с nodeID 06h и оно хочет принять PDO с идентификатором 185h. Но у этого PDO бит направления установлен на передачу. Как быть? Я к тому - зачем нужен этот бит направления? Если для того, чтобы принять сообщение, его придется прогигнорить?

Может я тут глупые вопросы задаю, но хочется до конца все хорошо понимать.

Нет там никакого бита направления, это я условно написал для случая, если бы нумерация протоколов CANopen шла от нуля.
Таблица - это основа протокола, именно на нее и ориентируйтесь.

[syoma]

Т.е. 512 PDO одного направления - это чисто такая договоренность для конкретизации структуры словаря (ну или способа настройки узлов)?!

Это ограничение CANopen на то количество сообщений, которое может генерить один узел. Ну зачем вам в одном узле больше чем 512 различных сообщений, если в каждое можно по 8 байт данных запихать?
А приведенная таблица - это такая рекомендация, которая в случае простой сети и наличия устройств "из коробки" позволяет одному узлу (мастеру) обмениваться индивидуально данными со 127 узлами. При этом каждый из 127 узлов имеет 4 TPDO, с помощью которых он передает мастеру данные и 4 RPDO, с помощью которых он принимает информацию от мастера. В итоге 128-ой узел - мастер должен иметь 127*4=508 настроенных RPDO и 508TPDO. То есть 508 PDO служат для того, чтобы один мастер передавал информацию 127 узлам, и 508 PDO нужно, чтобы 127 узлов передавали мастеру свою информацию. Ну а оставшиеся 8 PDO - для мастера. Еще раз повторюсь - это только пример.

Изначально я думал, что возможен такой вариант: допустим, в сети всего два устройства и объявлены 1024 PDO. Одно из устройств является производителем всех этих 1024 PDO, а другое является потребителем этих же 1024 PDO. Т.о. у одного устройства обьявлено 1024 TPDO, а у другого - 1024 RPDO (с теми же идентификаторами).

Теоретически такой вариант возможен, но практически нет - так как в стандарте CANopen прописаны адреса в словаре только для 512 TPDO или RPDO. Т.е лимит 512TPDO из одного узла.

Попытаюсь еще одним способом выразить как я себе представляю PDO в CANopen. В сети возможно существование 1024 PDO с различными идентификаторами (тут вроде все ясно). Эти PDO периодически возникают в сети и тот кому интересен тот или иной PDO вылавливает его и обрабатывает. А возникают PDO в сети благодаря производителям этих PDO. Т.о. возможно просто 1024 PDO, а какие они Tx или Rx - зависит кто с этим PDO работает: для производителя - это TPDO, а для потребителя - это RPDO. А то, что в CANopen описано 4 PDO на вход и 4 PDO на выход - это всего лишь рекомендации (которые меня сбивают с толку). Может быть 0 на вход и 8 на выход, или 200 на вход и 0 на выход.

Да - абсолютно правильно понимаете.

Допустим, устройство с nodeID 05h посылает в сеть сообщение PDO, например, с номером b0011 (согласно таблицы). Т.о. у устройства с nodeID 05h есть TPDO с идентификатором 185h. Где-то в сети есть устройство с nodeID 06h и оно хочет принять PDO с идентификатором 185h. Но у этого PDO бит направления установлен на передачу. Как быть?

Никак. В принимающем узле прописываете RPDO с идентификатором 185h и принимаете нужное PDO. Бит направления - это просто условность.

[slimjack]

Ну теперь все ясно!
Спасибо за разъяснения всем!
И еще дайте совет. Что нужно приобрести для разработки устройств с CANopen? Какая программа нужна для компьютера (для наладки и диагностики сети), какое железо? Посоветуйте фирму, пожалуйста. Я так понимаю стек покупать не совсем выгодно, потому что дорого и, судя по некоторым отзывам, очень тяжко для контроллера (из-за универсальности платных стеков).

[syoma]

Смотрите это сообщение: http://electronix.ru/forum/index.php?showt...st&p=790098
У меня железо - USB-to-CAN от IXXAT.
Платный стек стоит от 5000$. Бесплатных - есть 3шт. CanopenNode, CANfestival и бесплатная библиотека от Microchip для PICов.
Ну и тот контроллер, который Вы назвали - помоему совсем CANopen не потянет. или нужно будет извращаться.

[GreyM]

Бесплатные - еще меньше.
В CANopennode - помоему 8 шт возможно.

Это не совсем так. CANopenNode предоставляет 8 шт. по умолчанию (т.е. для них прописано отображение и тому подобное). Однако, в самом стеке (в мануале и в файлах CO_OD .c и .h) оговаривается, что нет никаких принципиальных проблем руками дописать необходимое количество PDO. То же самое относится и к heartbeat'у.

[Minti]

Привет. Если кому интересно.
Короче запустил я этот CANfestival на STM32F103. Заняло это дело 2 месяца подходов к компьютеру и чтения документации и аж 2 дня на перелопачивание драйверов на CAN контроллер и таймер. Исходники могу выложить.

работаю с Atollic TrueStudio. Пока не получается запустить. Было бы полезно сравнить.
Выложите пожалуйста исходники на smalholz[at]stud[.]fh-dortmunde[.]de
Спасибо!

ПС: на этом форуме личные сообщения отключены?

[Minti]

E-MAIL не правильно написал и кнопку корректировать не нашёл.
Вот правильный e-mail: smalholz[at]stud[.]fh-dortmund[.]de

[yanvasiij]

Раз уж здесь собрались все знатоки CANopen, то спрошу тут. Скачал либу CANopenNode. Кто нибудь сможет объяснить, почему не пашет редактор словаря объектов: при запуске device.xul выскакивает ошибка, что нехватает каких файлов в директории elements. А после обновления Firefox вообще при запуске пишет "Эта страница использует неподдерживаемую технологию, которая по умолчанию более недоступна в Firefox". Заранее спасибо!

Сообщение отредактировал yanvasiij - Jan 20 2012, 15:47

[Forger]

Кто нибудь сможет объяснить, почему не пашет редактор словаря объектов:

Да, забудьте вы про все эти пердо-программки и скачайте нормальный EDS-редактор, например, этот, (бесплатный): CANeds
Далее ручками добавьте в исходники все нужные объекты в соответсвтвии с уже правильно настроенным EDS-файлом.

[yanvasiij]

Да, забудьте вы про все эти пердо-программки и скачайте нормальный EDS-редактор, например, этот, (бесплатный): CANeds
Далее ручками добавьте в исходники все нужные объекты в соответсвтвии с уже правильно настроенным EDS-файлом.

Скачал CANeds, не пойму как создать именно файл с расширением eds. Он может сделать xdd, а при попытке сохранить как eds пишет "electronic datasheet could not be saved". И еще, если кому не трудно не могли бы дать ссылку на какое нить готовое устройство с доступным eds, чтобы я мог его открыть и "покурить". Теории то у меня до фига, а вот с готовыми примерами туговато.

[Forger]

Скачал CANeds, не пойму как создать именно файл с расширением eds. Он может сделать xdd, а при попытке сохранить как eds пишет "electronic datasheet could not be saved".

Странно, я специально только что попробовал в CANeds 3.6 SP1 создать и сохранить новый EDS файл. Все сохраняет...
Короче, ищите баги в своем компе и руках ))

И еще, если кому не трудно не могли бы дать ссылку на какое нить готовое устройство с доступным eds, чтобы я мог его открыть и "покурить". Теории то у меня до фига, а вот с готовыми примерами туговато.

Поиск в сети рулит! Буквально за минуту я нашел вот эти:
http://www.frenzel-berg.de/index.php?id=33&L=1
http://www.bihl-wiedemann.de/englisch/down/downldeds.htm#esd
http://akb.lenze.de/AKB-englisch/resource..../EDS044_V21.zip

[yanvasiij]

Странно, я специально только что попробовал в CANeds 3.6 SP1 создать и сохранить новый EDS файл. Все сохраняет...
Короче, ищите баги в своем компе и руках ))

Поиск в сети рулит! Буквально за минуту я нашел вот эти:
http://www.frenzel-berg.de/index.php?id=33&L=1
http://www.bihl-wiedemann.de/englisch/down/downldeds.htm#esd
http://akb.lenze.de/AKB-englisch/resource..../EDS044_V21.zip

Спасибо! Не понимаю как вам это удалось, я скоко не гуглил ничего не вышло, прорва книг и ни одного eds файла )

[yanvasiij]

Блин, да че такое?! Уже все весь мануал изрыл. Создаю пустой файл, с расширением xdd сохраняет, а когда пытаюсь сохранить как eds пишет ошибка

[Forger]

Блин, да че такое?! Уже все весь мануал изрыл. Создаю пустой файл, с расширением xdd сохраняет, а когда пытаюсь сохранить как eds пишет ошибка

Ну, думайте.... пробуйте на другом компе, на другой ОС.
У меня на работе - WinXP x32, дома - Win7 x64, так на обеих машинах все отлично создает, сохраняет и открывает.
Никаких проблем.

[yanvasiij]

Могут ли ошибки в проекте быть причиной не сохнранения EDS файла? Когда я нажимаю проверить вылазит 3 ошибки. Сдела все по видопримеру с сайта Vector, вылезло 3 ошибки, как xdd опять же сохранил, а в eds отказывается.

Сообщение отредактировал yanvasiij - Jan 24 2012, 06:54

[Forger]

Могут ли ошибки в проекте быть причиной не сохнранения EDS файла?

Нет, не влияет - щас проверил.
Говорю ж, проверьте работу CANeds на другом компе.

[yanvasiij]

Проверил уже на трех машинах, нигде сохранить не получается. На пиратской 32 разрядной XP на ноуте, потом на лиценцзионной 64 разрядной ХP и наконец на 32рзарядной семерке. А какая у вас версия CANeds? а то у меня 3.6.57 SP1, может послденяя версия кривая...

Сообщение отредактировал yanvasiij - Jan 24 2012, 07:16

[Forger]

Проверил уже на трех машинах, нигде сохранить не получается. На пиратской 32 разрядной XP на ноуте, потом на лиценцзионной 64 разрядной ХP и наконец на 32рзарядной семерке. А какая у вас версия CANeds? а то у меня 3.6.57 SP1, может послденяя версия кривая...

Странно. У меня такая же версия, самая свежая.
Я создаю новый файл, накидываю туда объекты и все норм. сохраняется.
Открываю старый файл (из старой версии CANeds), редактирую, сохраняю. Все ОК.
Может, проблема с файлом, который вы создаете? Выложите его тут, я у себя проверю.
Единственная особенность: файлы с русскими буквами в названии после сохранения меняют имя,
т.е. старый файл остается нетронутым, а просто создается новый файл с именем из иероглифов.
Лечится просто переименованиеме нового файла в нормальное имя.

[yanvasiij]

выкладываю xdd файл, иначе никак )
 1234.rar ( 1.61 килобайт ) Кол-во скачиваний: 123

[Forger]

выкладываю xdd файл, иначе никак )
 1234.rar ( 1.61 килобайт ) Кол-во скачиваний: 123

Проверил ваш файл - все ОК:

Код

Load c:\1234.xdd ...
Compare read EDS with database...
End of comparison.


Checking EDS...
Loading Checker...
Use database 'C:\PROGRA~1\VECTOR~1.6SP\CANchkEDS\v301.codb'
Use database 'C:\PROGRA~1\VECTOR~1.6SP\CANchkEDS\v302.codb'
CANchkEDS 2.2.70
VSemChecker running...
Error 200: XML-Scheme error in Line 154 Schema validation: Empty content not valid for content model: '(supportedBaudRate,)'

Error 200: XML-Scheme error in Line 0 XML schema validation: 1 errors detected

2 errors detected!
Leaving Checker...
Checking done.


C:\1234.eds saved.

Вот он:  1234.zip ( 648 байт ) Кол-во скачиваний: 71


А если открыть полученный 1234.eds и выполнить проверку, то вот что пишет:

Код

Checking EDS...
Loading Checker...
Use database 'C:\PROGRA~1\VECTOR~1.6SP\CANchkEDS\v301.codb'
Use database 'C:\PROGRA~1\VECTOR~1.6SP\CANchkEDS\v302.codb'
CANchkEDS 2.2.70
error 26: Entry "FileVersion" in section [FileInfo] not found.
error 26: Entry "FileRevision" in section [FileInfo] not found.
error 26: Entry "Description" in section [FileInfo] not found.
error 26: Entry "CreatedBy" in section [FileInfo] not found.
error 26: Entry "ModifiedBy" in section [FileInfo] not found.
error 26: Entry "VendorName" in section [DeviceInfo] not found.
error 26: Entry "VendorNumber" in section [DeviceInfo] not found.
error 26: Entry "ProductName" in section [DeviceInfo] not found.
8 errors detected!
Leaving Checker...
Checking done.

[yanvasiij]

Проблема решена! Собака порылась в названиях директорий. CANeds не может сохранить eds файл, если путь к директории содержит русские названия. Понял, когда увидел, где вы сохранили свой файл и вспомнил про то что Вы говорили: файлы с русскими буквами в названии после сохранения меняют имя . Спасибо!

[yanvasiij]

Теперь у меня вопрос по самому протоколу. PDO, которые конкретный узел может принимать хранятся в объектном словаре в записях с индексами 1400h – 15FFh. Я не пойму за что отвечают записи под индексами 1600h – 17FFh (Receive PDO Mapping). По тому описанию, что я читал там хранится индекс записи объектного словаря, которая должен отображаться. аналогично не совсем опнятно с отправляемыми PDO: параметры отправляемых PDO хранятя в записях с индексами 1800h – 19FFh Transmit PDO Parameters . А что хранится в записях Transmit PDO Mapping (1A00h – 1BFFh)?

[Forger]

Теперь у меня вопрос по самому протоколу. PDO...

А вот тут без знаний основ CANopen (а то, что вы описали - одна из основ CANopen) мои объяснения вряд ли помогут ((
Потому как за моим ответом неизбежно полезут другие вопросы...
Тут уже только сомостоятельно.
Ищите рускоязычные переводы CANopen, изучайте.
Тогда все само-собой проясниться.

p.s. В таких случаях говорят RTFM

[yanvasiij]

Проблема как раз таки в непонимании TFMа. Просто скажите правильно ли я понял: Допустим в записи объектного словаря под индексом 2000h хранится некоторая переменная подлежащая отображению в PDO. Для передачи я выбираю TPDO1 и по индексу 1800h по соответствующим субиндексам записываю необходимые параметры: COB ID, пусть будет 181, тип передачи пусть будет асинхронный 255, остальное по нулям. Чтобы указать что именно отображать в PDO, я по индексу 1A00h (Transmit PDO Mapping) субиндексу 01 прописывю 0x20000020 (32 битное число). Это для передачи. Для приема я так понял аналогично, толко индексы другие и параметр Receive PDO Mapping указывает на запись в объектном словаре куда будут записываться входящие PDO. Isn't it? Если нет то продолжу RTFM

Сообщение отредактировал yanvasiij - Jan 25 2012, 12:39

[Forger]

Просто скажите правильно ли я понял...

Правильно

[spectral1989]

здравствуйте! ковыряю CanFestival. подскажите пожалста как запустить редактор объектов(objdictgen.py)? Вроде все по мануалу делаю: Visual Studio 2005 установил, Cygwin установил, MinGW установил. Нужно что-то сконфигурировать видимо? пытаюсь запустить из командной строки - он ругается, что файл gnosis.xml.pickle отсутствует

такой вопрос еще, возможно ли запустить CanOpen в режиме, когда один и тот же процессор является и master, и slave? т.е. один микроконтроллер имеет 2 can интерфейса.

Сообщение отредактировал spectral1989 - Aug 28 2012, 04:01

[spectral1989]

с gnosis.xml.pickle разобрался, установил либу. но генератор все равно не запускается. как его вызывать правильно? я пишу так: python c:/VOLODYA/CanFestival2/objdictgen/objdictgen.py Node.od Node.c

node.od is not a valid file.

подскажите что делать?

[spectral1989]

продвинулся еще чуток. файл objdictgen.py преобразует xml файл node.od в сишный node.c, а чтобы редактировать node.od видимо необходимо запустить objdictedit.py, но он тоже не запускается. выдает ошибку:

import wx
import error: no module named wx

возможно вопрос глупый, но для меня решение не очевидно. подскажите пожалста как все таки запустить редактор объектов?
в мануале сказано:

double click on objdictedit.py

но это не помогает)

разобрался!
нужно было еще одну либу установить, wxpython называется.

[Maks455]

Здравствуйте.
2 недели назад начал изучать CANopen. Удалось успешно портировать библиотеку CANopennode под STM32.
устройство генерирует heart, реагирует на NMT.
Но вот больше у меня ничег сделать не получается.
Можете предоставить пару примеров как, например, отправлять SDO сообщения, принимать?
Буду очень благодарен за готовый проект c применением CANopennode.
Спасибо.

[syoma]

Если устройство реагирует на NMT и шлет Heartbeat, то я бы сперва попробовал побомбить его SDO из любой CANopen конфигурационной проги. По крайней мере в CANfestival - когда он у меня запустился, сразу заработал и SDO сервер. Я думаю в CANopennode тоже может так получиться.
Надеюсь CAN адаптер для PC у Вас есть?(типа IXXAT или Vector). Тогда советую установить демку CANwizard - http://canwizard.de/en/demoversion-download Она хоть под лифты заточена, но имеет в своем составе нормальный SDO клиент и позволяет просканировать сеть и залазить в объектные словари любых устройств. Просто запустите ее и попытайтесь просканировать сеть.
Кстати, никто больше не знает бесплатных конфигурационных прог для CANopen?

[Maks455]

В том то и дело, что есть только CAN анализатор, и две платы c stm32 и CAN. Нужно запустить между ними обмен информацией.
Достать CANopen возможности нет.

[syoma]

Какой CAN анализатор?

[Maks455]

Microchip CAN BUS Analyzer.

[syoma]

Microchip CAN BUS Analyzer.

Мда. Печально отлаживать протокол, не имея хотя бы одной железяки, которая его 100%-но поддерживает.
Просто SDO обмен с контроллера на контроллер - это сложновато сразу с ходу. Тогда лучше попробуйте PDO настроить хотя-бы.

[spectral1989]

Печально отлаживать протокол, не имея хотя бы одной железяки, которая его 100%-но поддерживает.

нормально разобраться можно

2 недели назад начал изучать CANopen. Удалось успешно портировать библиотеку CANopennode под STM32.
устройство генерирует heart, реагирует на NMT.
Но вот больше у меня ничег сделать не получается.

если у вас работает heart beat - вы без проблем можете запустить синхронные ПДО, почитайте про механизм генерации.

как, например, отправлять SDO сообщения, принимать?

с помощью СДО клиента/сервера. смотрите соответствующие записи в объектном словаре. если не понимаете что такое объектный словарь - нужно прежде всего разобраться с ним, четко понять цели его создания и тогда 75% вопросов отпадет.

UPD
скачайте доку на свой стандарт, или в крайнем случае есть более-менее переведенный DS301, поищите в интернете. и попробуйте вникнуть в суть написанного.

Сообщение отредактировал spectral1989 - Nov 9 2012, 01:29

[EvgeniyR]

Привет. Если кому интересно.
Короче запустил я этот CANfestival на STM32F103. Заняло это дело 2 месяца подходов к компьютеру и чтения документации и аж 2 дня на перелопачивание драйверов на CAN контроллер и таймер. Исходники могу выложить.
Аж сам удивился, но буквально при первой компиляции эта штука запустилась и начала генерить heartbit и даже реагировать на NMT команды.
На следующий день запустил PDO обмен - тоже работает без проблем. Несмотря на приличную навороченность (стек занял 20кБ места в МК) стек пока выглядит довольно стабильно. Работает все - и SDO и PDO и NMT сервисы (на слэйве).
Вчера даже получилость прикрутить к нему запись параметров во FLASH, а-ля EEPROM. Правда не все скопом, а для заданных объектов при записи.
2 Штуки мне очень понравились по сравнению с CanOpenNode.
1. Во-первых тут есть редактор eds файлов (правда хитро устанавливается, но вполне сносно) который позволяет создать профиль своего устройства и затем по этой информации генерирует .с и .h файлы для стека и сам .eds файл. Работает очень не плохо. Созданные файлы просто копируются в проэкт и перекомпилируются, а eds файл скармливается программе - монитору CANopen шины. О ней дальше внизу.
2. Во-вторых CANfestival имеет намного более развитые возможности. Например программа пользователя общается со стеком только через глобальные переменные, которые являются объектами словаря. При приходе нового PDO переменные сами собой обновляются. При изменении переменной программой - нужно только выполнить функцию послыки PDO и CANfestival сам определит, какая переменная в какой PDO пойдет и нужно ли его слать. Даже по таймеру все работает.
В общем я доволен пока.
Кстати насчет программы. Есть такой сайт: http://www.canwizard.de Там можно скачать одноименную программу.
Она хоть и предназначена для лифтов, но достаточна полезна и для простых CANopen сетей. Она позволяет подключаться к CANopen сети, искать узлы, читать eds файлы, генерить NMT и LSS команды, общаться с любыми узлами по SDO протоколу и т.д. Даже софт по сети обновлять может. Правда лог файлы она не ведет. Единственное ограничение, что бесплатная версия может работать толька максимум с тремя узлами. Поддерживает она Vector, Ixxat, Peak адаптеры.

Добрый день, если можно вышлите исходники на Rogovskiy@outlook.com. Заранее благодарен.

[syoma]

Я исходники вроде ж здесь выкладывал.

[VAlex999]

Добрый вечер.
Тема прошлая, но всё же может у кого осталась программка CANwizard, на официальном сайте так понимаю уже недоступно скачать, поиск то же результатов не дал. Надеюсь на этот форум.