CAN и CANopen: основы

 

Что может CANopen? Функциональные возможности сетей принято называть сервисами (Service). Вся распределённая периферия функционально является частью контроллера, по этому, сервисы промышленных сетей полевого уровня в идеале должны обеспечить те же функции, что и внутренняя шина модульного контроллера. Для примера, возьмём процессорный модуль ПЛК (CPU) и два очень популярных типа распределённой периферии: выносной модуль ввода/вывода (модуль I/O) и преобразователь частоты (ПЧ). Если бы они находились на локальной шине, функционирование системы можно бы было представить в виде, изображённом на рис.1. CANopen, как промышленная сеть полевого уровня, обеспечивает следующие базовые типы сервисов: обмен данными процесса, диагностику, управление режимом и конфигурирование устройств в сети.

Что такое данные процесса? В принципе это то, для чего и создается сеть полевого уровня. Данные процесса - это значения входных (I) и выходных (Q) данных ПЛК, использующиеся приложением для управления объектом в реальном времени. Все остальные данные и команды служат для обслуживания системы ПЛК. В CANopen обмен данными процесса реализован через сервис PDO.

Что такое параметрические данные? При включении ПЛК (холодный старт) процессорный модуль согласно конфигурации проекта конфигурирует все модули. Конфигурационные данные также называют параметрическими. В отличие от данных процесса, параметрические данные передаются только в момент конфигурирования или параметрирования (настройки) модулей и не требуют реального времени. Однако объём этих данных может быть довольно большим. В CANopen обмен параметрическими данными реализован через сервис SDO. 

Какие возможности диагностики в CANopen? Самодиагностика распределенной периферии определяет состояние модуля подобно модулю на локальной шине ПЛК. Аварийное состояние модуля определяется системой ПЛК в реальном времени с использованием диагностических сервисов. Так, например, в случае ошибки или отказа модуля, CPU ПЛК сможет сгенерировать тревогу или перейти в режим аварийной остановки.    

Зачем нужно управлять рабочим режимом? В приведенном примере CPU ПЛК является центральным узлом системы. По этой причине все остальные модули, в большинстве случаев, должны зависеть от рабочего режима ПЛК. Для примера, при останове ПЛК (режим STOP) все выходные каналы в системе должны перейти в безопасное состояние. Другой пример: при замене модуля ввода/вывода, сначала он должен пройти процедуру конфигурирования, а потом только перейти в операционный режим работы. Управление рабочим режимом узлов CANopen производится посредством сервисов NMT.                 

 

Физическое подключение.

Как соединяются устройства в сети CANopen? Для передачи и приёма битов в CANopen используется приёмопередатчики ISO 11898-2. Согласно этого стандарта все устройства (также называемые узлами сети) подключаются к общей шине, состоящих из двух потенциальных линий, обозначенных как CAN_H и CAN_L. На концах шины, между линиями обязательно устанавливаются терминирующие резисторы номиналом 120 Ом для исключения эффекта отражения. В качестве кабеля рекомендуется использовать экранированную витую пару.   

 

        Разрешается питание модулей по шине? В CANopen разрешается вместе с сигнальными проводами использовать в кабеле питающие жилы 0 В и 24 В.

Какая максимальная длина шины? До 1000 м без использования повторителя. Следует отметить, что длина линий связи и ответвлений влияет на максимальную скорость. Например, при 1000 м можно достичь скорости порядка 10 кбит/с.  

Какое ограничение на количество устройств? До 64 узлов. Если используется повторитель, количество узлов можно увеличить.

Какие скорости доступны? От 10 кбит/с до 1 Мбит/с (при длине < 40м). При этом поддержка узлами скорости 20 кбит/с является обязательной. Следует отметить, что большое количество передаваемых битов является служебными, поэтому битовая скорость это не скорость передачи битов данных.         

CAN и CANopen.

CAN и CANopen это синонимы? Нет, CANopen использует кадры CAN в качестве носителя данных. Иными словами кадры CAN доставляют данные от одного узла сети к другим. Доставка кадров – это задача канального уровня (data link layer) модели OSI. Таким образом, CANopen на канальном уровне использует протокол CAN.

Что такое кадр CAN? Кадр (Frame) - это битовая последовательность доминантных и рецессивных битов, которой обмениваются узлы в сетях. Задача кадров данных (Data Frame) -  доставить данные от узла-отправителя, узлам-получателям. Кадр CAN в общем случае состоит из набора полей, среди которых наиболее важны для понимания - поле данных и поле арбитража. В CAN кроме кадров данных существуют и другие типы кадров (Remote Frame, Error Frame, Overload Frame), отличающихся форматом и назначением.

Чем отличаются доминантные биты от рецессивных? Приемопередатчики CAN, в том числе и ISO 11898-2 могут передавать два уровни сигналов. Несколько передатчиков могут одновременно передавать свои биты. При этом, при передаче двух различных уровней сигналов, на шине остается доминантный бит. В CANopen доминантным битом является логический "0".    

Что такое поле данных кадра CAN? Поле данных – это единственное поле, содержащее информационную нагрузку в кадре данных. Это поле может содержать от 0 до 8 байт. Остальные битовые поля используются для служебных целей.     

Зачем нужно поле арбитража в кадре CAN? Кадр CAN начинается с поля арбитража. Приемники узлов всегда прослушивают шину, даже при передаче. Когда шина CAN свободна от передачи, любой узел может начать передавать кадр (случайный метод доступа). Однако в этот момент могут начать передавать также другие узлы. В таком случае узлы, в поле арбитража передающего кадра которых раньше будут появляться рецессивные биты, обнаружат на шине доминантные биты, и прекратят передачу (рис.3). Иными словами поле арбитража обеспечивает безколлизионный метод решения одновременного доступа передатчиков, определённый приоритетностью кадров. Требования к нормальному функционированию CAN требует, чтоб все кадры в сети имели уникальное содержания поля арбитража. Поле арбитража содержит идентификатора кадра и бит RTR. 

  

Зачем кадрам CAN идентификатор? В кадре CAN идентификатор используется не только для определения приоритета при арбитраже. С помощью идентификатора кадра CAN узлы на шине фильтруют сообщения. То есть каждый узел настроен на приём кадров только с идентификаторами, принадлежащему определённому перечню. В зависимости от версии CAN  идентификатор может содержать 11 бит или 29 бит. Обязательным для CANopen есть использование 11-битного идентификатора, а 29-битный является опциональным. Тем не менее, на одной шине может происходить обмен с использованием обеих типов кадров.     

Как настраиваются фильтры на CAN идентификаторы? Это зависит от используемой службы CANopen, о чём будет сказано позже.

Зачем кадрам CAN бит RTR? В CAN передача кадров данных может инициироваться узлом отправителем, либо узлом получателем. В первом случае отправитель посылает кадр по внутреннему событию, а во втором – при получении кадра запроса (Remote Frame), идентификатор которого совпадает с кадром данных, а бит RTR=1.    

Каких функций не хватает CAN? Используя CAN-кадры можно обмениваться какими-то данными (до 8 байт), не зависимо от их предназначения. Для обеспечения функций из рис.1, используя CAN, пришлось бы придумывать свои правила обмена (свой протокол). Так, например, в CPU ПЛК надо бы было написать микропрограмму для формирования последовательности байтов данных в кадре, а в модуле - микропрограмму для их интерпретации и наоборот. В реальных ПЛК обмен между CPU и модулями проходит неявно, то есть без участия программы пользователя. Подобного функционала не хватает CAN. Эти сервисы обеспечивают протоколы прикладного уровня CANopen, описанные в стандарте CiA DS 301 (www.can-cia.org ).

Словарь Объектов.

Как это работает? Каждый узел CANopen содержит центральную базу данных всех Объектов – Словарь Объектов (Object Dictionary) (рис.4). Функционирование CANopen полностью базируется на этом Словаре: там содержатся данные процесса, параметрические данные, а также вся необходимая информация для работы узла в сети. Приложение или микропрограмма узла взаимодействует со Словарём (записывает и считывает данные), а сервисы CANopen обеспечивают взаимодействие между Объектами Словаря разных узлов.    

Какая структура Словаря Объектов? Каждый Объект в Словаре имеет уникальный адрес, состоящий с Индекса (Index) и Под-Индекса(SubIndex). Объекты с индексами с 0000hex по 009Fhex используются для определения типов данных, с индексами 1000…1FFFhex нужны для настройки обмена узлов по CAN, 2000-5FFFhex - могут содержать значение любых данных по выбору производителя оборудования. Объекты с индексами 6000-9FFFhex используются в зависимости от стандартного профиля устройства.

Что такое профиль устройства? Чтоб легче интегрировать децентрализованную периферию в систему, не зависимо от её производителя, на наиболее популярные устройства созданы стандартные профили устройства. В этих профилях определены, какие Объекты Словаря за какие функции отвечают. Так, например (рис.4), если устройство поддерживает профиль модуля ввода/вывода (DS 401), в Объекте с Индексом=6000hex и Под-Индексом=1 будет значение первых 8 дискретных входов (8DI1). Если же устройство поддерживает профиль для приводов (DS 402) то в Объекте с Индексом=6040hex и Под-Индексом=0 будет находиться значение командного слова управления (CTW).

Как узнать список всех доступных Объектов Словаря конкретного устройства? Для этого производитель устройства предоставляет текстовый файл специального формата - EDS. С такими файлами умеют работать утилиты конфигурирования CANopen.

Как значения Объектов передаются между Словарями? Передача значений (запись или чтение) может осуществляться двумя механизмами: посредством PDO или SDO. PDO нужен для обмена данными процесса в реальном времени, а SDO – в основном для обмена параметрическими данными.

Обмен данными процесса посредством PDO.

Как функционирует PDO?  Этот сервис настраивается при конфигурации сети, а потом работает без участи программы пользователя. Он базируется на коммуникационных Объектах T-PDO (передача PDO) и R-PDO (приём PDO). Данные с T-PDO узла-отправителя (PDO Producer) попадают в R-PDO узлов-получателей (PDO Consumer) одним CAN-кадром (рис.5). Задачу передачи данных  посредством PDO можно поделить на несколько подзадач:

1)       связи T-PDO отправителя и нужных R-PDO получателей;

2)       определения Объектов Словаря для передачи данных с T-PDO;

3)       определения Объектов Словаря для приёма данных с R-PDO;

4)       определения событий, при которых нужно производить отправку данных;                             

 

Сколько всего доступно PDO на каждом узле? До 512 T-PDO и до 512 R-PDO. Однако многие узлы содержат не более 4-х PDO.

Сколько данных может передать один PDO? PDO может переносить до 8 байт данных, поскольку это максимальная длина поля данных CAN-кадра.   

Как связываются T-PDO отправителя и R-PDO получателей?  В настройках T-PDO и R-PDO указывается идентификатор CAN-кадра, с помощью которого передается T-PDO. В терминах CANopen, этот идентификатор называется COB-ID (идентификатор коммуникационного Объекта). Таким образом, все R-PDO, со значением COB-ID равным идентификатору CAN-кадра, примут значение данных с этого кадра (рис.5).

Как определяются Объекты Словаря для передачи данных с T-PDO? В настройках T-PDO указывается Индексы и Под-Индексы тех Объектов Словаря, значение которых будут передаваться с T-PDO. Такое связывание Объектов Словаря с PDO называется PDO Отображением (PDO Mapping).

Как определяются Объекты Словаря для приёма данных с R-PDO? Аналогично, как и для передачи, с использованием PDO Отображения, но только для R-PDO.

Как определяются события отправки и приёма PDO? В настройках PDO указывается тип передачи (transmission type), определяющий событие, по которому производится отправка T-PDO. Тип передачи может принимать значения от 0 до 255. T-PDO можно отправлять синхронно или асинхронно, циклично или ациклично, или по кадру запроса. Соответственно типу передачи, PDO также называются синхронными, асинхронными, цикличными или ацикличными.

Что такое синхронные PDO? Передача синхронных T-PDO осуществляется после получения узлами специального Объекта SYNC. Учитывая, что синхронных T-PDO в сети может быть несколько, определяется временная граница после Объекта SYNC (synchronous window length, Index=1007hex), в которой могут отправляться синхронные T-PDO.

Синхронные T-PDO с типами передачи 1-240 передаются с каждым n-ным Объектом SYNC, где n – номер типа передачи PDO. Поэтому такие PDO называются также циклическими. Синхронный T-PDO с типом передачи равным 0, передаётся только по определённому событию, определённому в устройстве. Синхронные R-PDO, сначала получают данные от T-PDO, и только на следующем Объекте SYNC записывают их в Словарь Объектов.

Что такое Объект SYNC? Это специальный Объект, передающийся одним из узлов в сети, выполняющим функции SYNC Producer. В этом узле для SYNC настраивается периодичность (communication cycle period, Index=1006hex), с которой будет отправляться кадр SYNC, и его COB-ID (Index=1005hex). Все узлы, в которых для Объекта SYNC будет настроен тот же COB-ID, будут являться его потребителями (SYNC Consumer),  то есть их синхронные PDO будут привязываться именно к этому SYNC.

Как работают асинхронные PDO? Передача и прием асинхронных PDO не зависит от Объекта SYNC. T-PDO может передаваться: по кадру запроса RTR (тип передачи 253); по внутреннему событию, определённому производителем устройства (тип 254); по внутреннему событию, определённому профилем устройства (тип 255).

Что такое RTR? Тип передачи с RTR определяет передачу T-PDO после получения CAN кадра запроса с таким же COB-ID.

Какие внутренние события могут активировать передачу T-PDO? Асинхронная передача может осуществляться по таймеру, который определён в настройках T-PDO (Event Timer). Другим вариантом может быть событие, вызвано изменением значения одного из Объектов Словаря, отображенного на этот T-PDO.

Если данные в асинхронном T-PDO часто меняются, не зависнет ли сеть? Для того, чтоб часто изменяющиеся данные не вытеснили все Объекты с меньшим приоритетом, в настройках T-PDO выставляется значение минимального интервала между двумя передачами (Inhibit Time).

Где настраиваются PDO? Как и всё, что связано с CANopen, настройки PDO хранятся в Словаре Объектов. Для каждого T-PDO и R-PDO настраиваются два Объекта Словаря: параметры Отображения (PDO Mapping Parameters) и коммуникационные параметры (PDO Communication Parameters).

Где и что настраивается в параметрах Отображения PDO? Объекты 1600-17FFhex содержат информацию о Отображении Объектов Словаря на R-PDO, а 1A00-1BFFhex - на T-PDO (рис.6). Для каждого PDO указывается количество Отображаемых Объектов (до 64, так как PDO переносит 8 байт максимум), а также Индекс, Под-Индекс и длина в битах отображаемого Объекта. 

    

Где и что настраивается в коммуникационных параметрах PDO? Объекты 1400-15FFhex содержат коммуникационные параметры R-PDO, а 1800-19FFhex - T-PDO (рис.7). Коммуникационные параметры содержат все настройки для связи T-PDO и R-PDO между собой: COB-ID, тип передачи (transmission type), минимальный интервал между передачами (inhibit time), время событийного таймера (event timer).     

Какими средствами можно изменить настройки PDO и SYNC, чтоб работал сервис PDO? Выше мы рассмотрели, что сервис PDO настраивается через специальные объекты Словаря. Эти объекты являются параметрическими данными, и для их настройки нужно использовать сервис SDO.

 

 

 

 

 

Обмен данными посредством SDO.

Сервис SDO используется только для передачи параметрических данных?  Нет, его можно использовать для обмена любыми данными, включая данные процесса. Однако этот сервис требует управления со стороны программы пользователя, а кадры имеют меньший приоритет, нежели кадры PDO. Тем не менее, при малом количестве доступных PDO, и не жёстких требованиях к реальному времени, для обмена данными процесса можно использовать SDO. 

Как функционирует SDO?  Этот сервис даёт возможность записать (download) или прочитать (upload) Объекты из Словаря другого узла по их Индексу и Под-Индексу. Функционирование сервиса SDO имеет много нюансов, однако для пользователя достаточно понимать только основные механизмы, по этому, далее приводится упрощённая модель.

Для записи или чтения значений Объектов Словаря используется Клиент-Серверная схема обмена. Приложение-Клиент, желающее прочитать или записать значение из Словаря Объектов другого узла, инициирует запрос, в котором указывает Индекс и Под-Индекс Объекта Словаря, желаемую операцию (чтение или запись), и значение Объектов (при операции записи). Узел, содержащий нужные Объекты, отвечает на запрос. При чтении данных, в ответе содержатся также значения Объектов Словаря.

Как запросы SDO попадают на нужный узел?  Каждый Словарь Объектов должен содержать как минимум два коммуникационных Объекта: Server R-SDO1 для приёма CAN-кадров с запросами, и Server T-SDO1 - для передачи CAN-кадров с ответами (рис.8).  Словарь Объектов на узле с клиентским приложением должен также содержать по одному Client T-SDO и Client R-SDO. В параметрах каждого SDO указывается COB-ID. То есть COB-ID для соединяемых Client T-SDO и Server R-SDO должны быть одинаковыми, то же самое касается COB-ID Client R-SDO и Server T-SDO. Значения параметров Server SDO находятся в Объектах c Индексами 1200-127Fhex, Client SDO - в  1280-12FFhex.

Как настроить соединение между клиентскими и серверными SDO, ведь параметризация проходит через эти же SDO?  Для такой связи существует предопределенная схема установки соединений, по которой самые ключевые Объекты Словаря каждого узла получат по умолчанию уникальные настройки, позволяющие обойтись без внешнего конфигурирования. 

                            

Конфигурирование CANopen и предопределённая схема установки соединений.

Как работает предопределенная схема установки соединений? Каждый узел должен иметь уникальный адрес в сети (NODEID) в диапазоне от 1 до 127, выставляемый иными средствами (например, встроенным переключателем). После включения, узлы на основании NODEID получат начальные настройки некоторых Объектов Словаря: параметров для Server T-SDO1 и Server R-SDO1, параметров для первых 4-х PDO (T-PDO1…T-PDO4, R-PDO1…R_PDO4), и некоторых других Объектов Словаря.

Какие предопределенные параметры для SDO? Server T-SDO получает COB-ID=NODEID+580hex, Server R-SDO получает COB-ID=NODEID+600hex. Таким образом, если все узлы получат уникальные COB-ID для SDO,  клиентское приложение сможет обратиться к Словарю нужного узла исходя из адреса NODEID.

Какие предопределенные параметры для PDO? Кроме SDO, по умолчанию настраиваются также PDO. COB-ID для них распределяются следующим образом:

T-PDO1=NODEID+180hex, T-PDO2=NODEID+280hex, T-PDO3=NODEID+380hex, T-PDO4=NODEID+480hex

R-PDO1=NODEID+200hex, R-PDO2=NODEID+300hex, R-PDO3=NODEID+400hex, R-PDO4=NODEID+500hex

Также, в зависимости от профиля устройства, настраиваются коммуникационные параметры, и параметры Отображения.

Если PDO всех узлов получат уникальные COB-ID, как свяжутся T-PDO отправителя и R-PDO получателей? Среди всех узлов выделяется одно Ведущее устройство (Master), а все остальные являются Ведомыми устройствами (Slave). В нашем примере Ведущим устройством является CPU ПЛК. По такой схеме R-PDO Ведомых связываются с T-PDO Ведущего и наоборот. То есть Ведомые по предустановленной схеме соединений могут обмениваться данными только с Ведущим. Такая конфигурация даёт возможность построить обмен с центральным контроллером, не конфигурируя остальные узлы. При этом для каждого узла могут быть доступны до 32 байт (4PDO*8) данных для чтения и столько же для записи.

Предопределённая схема соединений для Ведомых CANopen является обязательной. А вот произвольное назначение COB-ID и Отображения PDO являются опциональными, и настраиваются посредством сервисов SDO.

Как можно сконфигурировать узлы CANopen? Конфигурирование Ведущего узла производится специальными программными средствами, например средой программирования ПЛК, или специальной утилитой конфигурирования сетевой карты (или модуля) CANopen. Эта конфигурация включает всю необходимую информацию для функционирования всех сервисов CANopen. Конфигурирования Ведомых узлов может происходить посредством внешних утилит (не относящихся к CANopen), либо посредством SDO с Ведущего устройства.

Можно ли конфигурировать всю сеть, меняя только настройки Ведущего узла? Можно. Во первых, можно оставить предопределённую схему соединений. Во вторых, многие Ведущие устройства CANopen поддерживают возможность формирования списка изменяемых в Словарях Ведомых узлов Объектов. Для этого, в утилите конфигурирования проектируется вся сеть, и настраиваются значения нужных Объектов Словарей. Например, на рис.9 показан вариант реализации постановочной задачи. В результате для коммуникационной карты Ведущего узла сформируется перечень Объектов Словаря этого Ведомого, которые будут автоматически записаны посредством сервиса SDO. Для работы со Словарём Объектов конкретного устройства нужно иметь EDS-файл. Описанная функциональность доступна Ведущим устройствам с функцией Конфигурационного Менеджера (Configuration Manager).

Когда производится запись конфигурационных данных в Ведомые узлы CANopen? В классическом варианте конфигурирование должно производиться до операционного режима, аналогично как в ПЛК: сначала CPU ПЛК конфигурирует все остальные модули, а потом переводит всю систему в операционный режим выполнения. В CANopen для управления операционным режимом узлов сети существуют сервисы NMT. 

 

Управление рабочим режимом узлов CANopen.

Как работают сервисы NMT? Каждый узел CANopen может находиться в одном из рабочих режимов (состояний), в которых доступны определенные функции. Один из узлов выделяется с правами NMT Master, который может переводить остальные узлы (NMT Slave) в нужное состояние. Функции Ведущего узла, описанные в предопределённой схеме соединений, совпадают с функциями NMT Master, а функции Ведомого - с NMT Slave. Поэтому далее будем считать эти понятия синонимами.

В каких режимах может находиться NMT Slave? На рис.10 показана диаграмма состояний NMT Slave. После включения питания он  проходит стадию Инициализации (Initialization), в которой проводит тестирование и настраивает параметры коммуникационной связи (выставляет скорость, NODEID, настраивает предопределённую схему). После этого, при отсутствии внутренних ошибок узел сам переходит в Предоперационный режим (Pre-Operational), при этом посылая NMT MasterBootUp-сообщение. В Предоперационном режиме доступны SDO-сервисы, а значит в этом режиме Ведущий может сконфигурировать данный узел.

Сервисы PDO работают только в Операционном режиме (Operational), в который узел переводится командой NMT Master. В Операционном режиме доступны все коммуникации, включая SDO. NMT Master может переводить узел в любой из режимов, в том числе и Стоп (Stopped), при котором не доступны ни PDO ни SDO.

Как формируется команда от NMT Master? NMT Master посылает NMT-команду используя один кадр CAN с  COB-ID=0. NMT Master в поле данных кадра указывает команду и адрес NMT Slave (NODEID), которому она предназначена. При NODEID=0, команда посылается всем NMT Slave. Доступны команды: 1 – старт Операционного режима, 2 – переход в Стоп, 128 – переход в Предоперационные режим, 129 – рестарт узла, 130 – отключение коммуникации.

 Как задается последовательность, которую должен проводить NMT Master при загрузке NMT Slave? Как правило, такая последовательность задаётся при конфигурировании NMT Master. Там указывается необходимость загрузки конфигурации посредством SDO, перевода в Операционный режим и т.д.      

Диагностические сервисы CANopen.

Как узнать состояние узла? Для этого в CANopen функционируют диагностические сервисы NodeGuard/LifeGuard и Heartbeat. Для каждого NMT Slave выбирается только один из сервисов. В любом случае NMT Slave отправляет в сеть сообщение состояния с COB-ID=NODEID+700hex. В поле данных этого сообщения указывается состояние  NMT Slave: 0 – (BootUp), 4 – Stopped, 5 – Operational, 7Fhex - Pre-Operational.

Как работает NodeGuard/LifeGuard? При этом выбранном сервисе NMT Slave отправит сообщение состояния только при запросе от NMT Master. NMT Master каждому NMT Slave посылает кадр запроса с периодичностью Guard Time. Кроме состояния, NMT Slave также постоянно переключает 7-й бит данных, что свидетельствует о работоспособности коммуникации. Со своей стороны, получая запрос состояния,  NMT Slave может проверять работоспособность NMT Master. Если запрос состояния не приходил от NMT Master более чем время LifeTime, узел может перейти в аварийное состояние.     

Как работает Heartbeat? Heartbeat – является опциональным сервисом, но рекомендуется как лучшая альтернатива NodeGuard/LifeGuard. Каждый узел, где активирована функция Heartbeat (Heartbeat Producer), сам посылает сообщение состояния с указанной периодичностью (Producer Heartbeat Time, Индекс=1017hex). Прослушивать  Heartbeat-посылку может не только NMT-Master, но и любые другие узлы.

Что такое BootUp? BootUp – переход из состояния Initialization в  Pre-Operational. После перехода NMT Slave автоматически отправляет кадр с сообщением состояния.

 Как узнать о ошибке на узле? Для этого можно использовать опциональный Emergency Object, который отправляется узлом по сети при ошибке на узле. В поле данных кадра указывается код ошибки. Для Объекта Emergency также действует предопределённая схема установки соединений.        

Последовательность создание сети.

В какой последовательности создаётся сеть CANopen? Ориентировочная последовательность действий для создания приведённой в начале системы может быть следующей:

1.      Настраиваются все узлы распределённой периферии: выставляются адреса (NODEID), скорость, дополнительные параметры связанные и не связанные с функционированием CANopen;

2.      Создаётся проект конфигурации CANopen для CPU ПЛК, в который импортируются все файлы EDS;

3.      В проекте конфигурации настраивается сеть, для которой указываются:

·         для каждого NMT Slave адрес и название (опционально);

·         для каждого NMT Slave настройки PDO: параметры Отображения и коммуникационные параметры;

·         для каждого NMT Slave изменяемые значения Объектов (посредством SDO), если таковые требуются;

·         для каждого NMT Slave последовательность управления при включении;

·         для каждого NMT Slave настройки диагностических сервисов;

·         для NMT Master параметры сети: адрес NODEID, битовая скорость, параметры SYNC (если NMT Master является SYNC Producer);

·         для NMT Master, коим является ПЛК, адреса входов и выходов для принимаемых и отправляемых данных посредством PDO, а также поведение узлов в сети при останове ПЛК или при ошибках;

В какой последовательности производится запуск сети CANopen? Ориентировочная последовательность действий сетевых узлов может быть следующей:

1.       На узлы сети подаётся питание;

2.       Все узлы проходят стадию самодиагностики и инициализации;

3.       NMT Master переходит в Операционный режим (в зависимости от системных настроек), активирует объекты SYNC, диагностические сервисы;

4.       NMT Slave переходит в Предоперационный режим и посылает BootUp сообщение, активируются диагностические сервисы, сервис SDO, сервис NMT;

5.       NMT Master конфигурирует NMT Slave посредством SDO (если требуется);

6.       NMT Master переводит  NMT Slave в Операционный режим, NMT Slave активирует PDO обмен;

 

                  

 

 
 
Comments