Process Data Objects (PDO)

Вступление

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

CANopen использует сегменты данных размером до 8 байт, которые называются объектами данных процесса (PDO). PDO соответствуют кадрам CAN, которые имеют свой уникальный идентификатор для распределения и определения приоритета. Существуют приемные PDO (RxPDO) и передающие PDO (TxPDO), название зависит от точки зрения устройства: модуль ввода-вывода отправляет свои данные с помощью TxPDO и получает данные в RxPDO. Это соглашение об именах используется в платформе CAN bp.

Параметры связи

PDO имеют различные параметры связи, которые соответствуют требованиям приложения. Все параметры CANopen доступны в каталоге объектов устройств и могут быть доступны через объекты служебных данных. Записи для приемных PDO начинаются с индекса 0x1400 (RxPDO1) и продолжаются до 0x15FF (RxPDO512). Аналогично, записи для передающих PDO располагаются с индекса 0x1800 (TxPDO1) по 0x19FF (TxPDO512).

Модули предоставляют 16 RxPDO и TxPDO для обмена данными процесса. При необходимости можно увеличить до 32 TxPDO и 32 RxPDO.

Для каждого существующего объекта данных процесса существует соответствующий объект параметров связи.

Идентификатор PDO

Идентификатор CAN (также известный как идентификатор связи объекта или COB-ID) является наиболее важным параметром в PDO. Он используется для идентификации данных и определения их приоритета при доступе к шине. В каждой посылке данных CAN может быть только один отправитель (производитель), хотя все сообщения, отправленные во время широковещательной рассылки CAN, могут быть получены любым количеством узлов (потребителей). Поэтому узел может сделать свои входные данные доступными для нескольких устройств шины.

PDO-связывание

По умолчанию все узлы публикуют свои дискретные данные в TxPDO1, аналоговые в TxPDO2, TxPDO3 и принимают данные для управления дискретными выходами (например реле) RxPDO1, аналоговые (например 0..10В) RxPDO2, RxPDO3. Таким образом для получения телеметрии и телеуправления никакой дополнительной настройки не требуется.

Рисунок: Связывание по умолчанию

В модели где узлы обмениваются данными с одной центральной станцией (главной), необходимо настроить в ней RxPDO5…RxPDO16 поскольку ведомые узлы по умолчанию не прослушивают идентификатор передачи любого другого ведомого узла. В качестве станции может выступать любой узел в платформе CAN bp.

Рисунок: Связывание с одной станцией

Если модель PDO потребитель-производитель должна использоваться для прямого обмена данными между узлами (без ведущего устройства), необходимо соответствующим образом адаптировать PDO, чтобы идентификатор TxPDO производителя согласовывался с идентификатором RxPDO потребителя: Эта процедура известна как связывание PDO. Это позволяет, например, легко создавать электронные приводы, в которых несколько ведомых осей одновременно прослушивают фактическое значение в TxPDO ведущей оси.

Рисунок: Связывание нескольких модулей

Типы связи PDO

CANopen предлагает несколько возможных способов передачи данных процесса (см. также: Примечания по параметрированию PDO).

Рисунок: передача данных процесса CAN

По событию

«Событие» — это изменение входного значения. Данные передаются сразу после изменения. Потоки, управляемые событиями, могут оптимально использовать пропускную способность шины, так как обрабатываются только изменения, а не весь образ процесса. Это обеспечивает короткое время реакции, так как при изменении входного значения не нужно ждать следующего запроса от ведущего устройства.

По запросу

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

Синхронно

CANopen предоставляет объект SYNC, который является посылкой CAN с высоким приоритетом и не содержит пользовательских данных. Прием этой посылки используется синхронизированными узлами как триггер для чтения входных данных или настройки выходных данных. В таком режиме можно сначала передать каждому узлу данные поочереди, а затем отправить команду SYNC которую все узлы получат одновременно и начнут действовать синхронно.

Типы передачи PDO

Параметр типа передачи PDO определяет, как инициируется передача PDO или как обрабатываются полученные PDO.

Параметр	Циклический	Ациклический	Синхронный	Асинхронный	Только RTR
0		X	X
1-240	X		X
252			X		X
253				X	X
254, 255				X

241-251 зарезервированны

Тип передачи параметрируется для RxPDO в объектах по адресу 0x1400ff, субиндекс 2, а для TxPDO в объектах по адресу 0x1800ff, субиндекс 2.

Ациклический синхронный

PDO типа передачи 0 функционируют синхронно, а не циклически. RxPDO оценивается только после получения следующей телеграммы SYNC. Таким образом, например, группам осей можно присваивать новые целевые позиции одну за другой, но эти позиции становятся действительными только при следующей синхронизации - без необходимости постоянно выводить референтные точки. Устройство, TxPDO которого настроено для типа передачи 0, получает свои входные данные, когда оно получает SYNC (образ синхронного процесса), а затем передает их, если данные соответствуют произошедшему событию (например, изменению входных данных). Таким образом, тип передачи 0 объединяет передачу по причинам, которые обусловлены событиями, со временем передачи (и, насколько это возможно, выборкой) и обработкой, определяемыми приемом «SYNC».

Циклический Синхронный

В типах передачи 1–240 PDO передается циклически: после каждой «n-й» синхронизации (n = 1…240). Поскольку типы передачи можно комбинировать как на устройстве, так и в сети, это возможно, например, , чтобы согласовать быстрый цикл для цифровых входов (n = 1), тогда как данные для аналоговых входов передаются в более медленном цикле (например, n = 10). RxPDO обычно не различает типы передачи 0…240: полученный PDO становится действительным при получении следующего сигнала синхронизации.Время цикла (частота синхронизации) может отслеживаться (объект 0x1006), так что в случае сбоя синхронизации устройство реагирует в соответствии с определением в профиле устройства. , и переключает, например, его выходы в состояние ошибки.

Только RTR

Типы передачи 252 и 253 применяются к объектам данных обработки, которые передаются исключительно по запросу удаленного кадра. 252 является синхронным: когда SYNC получен, данные процесса собираются. Передается только по запросу. 253 является асинхронным. Данные здесь собираются постоянно и передаются по запросу. Этот тип передачи обычно не рекомендуется, поскольку получение входных данных от некоторых контроллеров CAN поддерживается лишь частично. Поскольку, кроме того, контроллеры CAN иногда автоматически отвечают на удаленные кадры (без предварительного запроса обновленных входных данных), возникают обстоятельства, при которых возникает сомнение в актуальности опрашиваемых данных. По этой причине типы передачи 252 и 253 не поддерживаются платформой CAN bp.

Асинхронный

Типы передачи 254 + 255 являются асинхронными, но также могут управляться событиями. Для типа передачи 254 событие зависит от производителя, тогда как для типа 255 оно определяется в профиле устройства. В простейшем случае событием является изменение входного значения — это означает, что передается каждое изменение значения. Асинхронный тип передачи может быть связан с таймером событий, обеспечивая таким образом входные данные даже тогда, когда не произошло никакого события.

Запрет на время

CANopen также предоставляет параметр «Время запрета», который может использоваться для реализации «фильтра передачи». Этот фильтр не увеличивает время реакции на относительно новые входные изменения, но активируется для изменений, которые происходят сразу после предыдущего изменения.

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

Часто используется для аналоговых датчиков частые измененные данные которых не требуются.

Таймер событий

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

PDO Сопоставление

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

PDO по умолчанию для приводов содержат по 2 байта слова управления и состояния, а также заданного или фактического значения для соответствующей оси.

Текущее сопоставление можно прочитать с помощью соответствующих записей в каталоге объектов. Они известны как таблицы сопоставления. Первое место в таблице сопоставлений (субиндекс 0) содержит количество сопоставленных объектов, перечисленных после него. Таблицы расположены в каталоге объектов по индексу 0x1600ff для RxPDO и по адресу 0x1A00ff для TxPDO.

Параметризация PDO

Несмотря на то, что большинство сетей CANopen удовлетворительно работают с настройками по умолчанию, т.е. с минимальными усилиями по настройке, разумно, по крайней мере, проверить, является ли существующая загрузка шины разумной: загрузка шины в 80% может быть приемлемой для сети, работающей исключительно в циклические синхронные режимы, но для сети с трафиком, управляемым событиями, это значение обычно будет слишком высоким, поскольку для дополнительных событий вряд ли будет доступна полоса пропускания.

Учитывайте требования приложения

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

Небольшая работа над параметризацией — используемые значения по умолчанию оптимальны. Гарантированное время реакции на конкретные события Время цикла процессов регулирования по шине Резервы безопасности на случай неисправности шины (достаточная пропускная способность для повторения сообщений) Максимальная скорость передачи данных – зависит от максимальной длины шины Желаемые пути общения – кто с кем разговаривает Определяющим фактором часто оказывается доступная пропускная способность шины (нагрузка шины).

Скорость передачи данных

Обычно мы начинаем с выбора самой высокой скорости передачи данных, которую допускает шина. Следует иметь в виду, что системы с последовательной шиной принципиально более чувствительны к помехам по мере увеличения скорости передачи данных. Поэтому действует следующее правило: настолько быстро, насколько необходимо. Скорость 1000 кбит/с обычно не требуется, и ее безоговорочно рекомендуют только в сетях внутри шкафа управления, где нет электрической изоляции между шинными узлами. Опыт также показывает, что оценки длины проложенного шинного кабеля часто бывают чрезмерно оптимистичными: фактически проложенная длина обычно оказывается больше.

Определите тип связи

После выбора скорости передачи данных целесообразно указать тип(ы) связи PDO. Они имеют разные преимущества и недостатки:

Циклическая синхронная связь обеспечивает точно прогнозируемую загрузку шины и, следовательно, определенное поведение во времени — можно сказать, что стандартный случай — это наихудший случай. Его легко настроить: параметр скорости SYNC устанавливает глобальную загрузку шины. Образы процесса синхронизируются: входные данные считываются одновременно, выходные данные устанавливаются одновременно, хотя качество синхронизации зависит от реализации.

Гарантированное время реакции при циклической синхронной связи всегда не меньше времени цикла, а полоса пропускания шины не используется оптимально, поскольку старые данные, т. е. данные, которые не изменились, передаются непрерывно. Однако можно оптимизировать сеть путем выбора различных кратностей синхронизации (типы передачи 1…240), так что данные, которые медленно изменяются, передаются реже, чем, например, критичные по времени входы. Однако следует иметь в виду, что входные состояния, длящиеся в течение времени, меньшего времени цикла, не обязательно будут переданы. Если необходимо зарегистрировать такие условия, следует предоставить соответствующие PDO для асинхронной связи. Асинхронная связь, управляемая событиями, оптимальна с точки зрения времени реакции и использования пропускной способности шины — ее можно охарактеризовать как «чистый CAN». Однако ваш выбор должен также учитывать тот факт, что одновременное возникновение большого количества событий не исключено, что приводит к соответствующим задержкам перед отправкой PDO с относительно низким приоритетом. Поэтому правильное планирование сети требует анализа наихудшего случая. Используя, например, время блокировки, также необходимо предотвратить блокировку шины постоянно меняющимся входом с высоким приоритетом PDO (технически это называется «болтущий идиот»). Именно по этой причине управление событиями по умолчанию отключено в профиле устройства аналоговых входов и должно быть специально включено. Временные окна для PDO передачи можно установить с помощью таймеров выполнения: телеграмма не отправляется повторно до истечения времени запрета и не позднее, чем время, необходимое для завершения таймера выполнения. Тип связи параметрируется посредством типа передачи. Также возможно объединить два принципа PDO. Например, может быть полезно синхронно обмениваться заданными и фактическими значениями контроллера оси, в то время как конечные выключатели или температура двигателя с предельными значениями контролируются с помощью PDO, управляемых событиями. Это сочетает в себе преимущества двух принципов: синхронность связи осей и короткое время реакции концевых выключателей. Несмотря на то, что распределенный контроль предельных значений управляется событиями, он позволяет избежать постоянного добавления к нагрузке шины аналогового значения температуры.

В этом примере также может быть полезно намеренно манипулировать распределением идентификаторов, чтобы оптимизировать доступ к шине посредством распределения приоритетов: высший приоритет отдается PDO с данными концевого выключателя, а наименьший - с температурой. ценности.

Однако оптимизация времени задержки доступа к шине за счет изменения распределения идентификаторов обычно не требуется. С другой стороны, идентификаторы должны быть изменены, если необходимо сделать возможным обмен данными без мастера (связывание PDO). В этом примере можно было бы назначить одному RxPDO для каждой оси тот же идентификатор, что и концевому выключателю TxPDO, чтобы изменения входного значения можно было получать без задержки.

Определение загрузки шины

Всегда стоит определить загрузку шины. Но какие значения нагрузки на шину разрешены или действительно разумны? Прежде всего необходимо выделить короткую пачку телеграмм, в которой сразу же следует одно за другим несколько CAN-сообщений - временная 100% загрузка шины. Это проблема только в том случае, если последовательность прерываний приема, вызванная ею на узлах CAN, не может быть обработана. Это будет означать переполнение данных (или переполнение очереди CAN). Это может произойти при очень высоких скоростях передачи данных (> 500 кбит/с) на узлах с программной фильтрацией телеграмм и относительно медленными или сильно нагруженными микроконтроллерами, если, например, серия удаленных кадров (которые не содержат байтов данных и, следовательно, очень короче) следуют друг за другом по шине (при скорости 1 Мбит/с это может генерировать прерывание каждые 40 мкс; например, мастер NMT может передавать все свои защитные запросы в непрерывной последовательности). Этого можно избежать путем квалифицированной реализации, и пользователь должен иметь возможность предположить, что поставщики устройств предприняли необходимые усилия. Например, пакетное состояние сразу после телеграммы SYNC является совершенно нормальным: при срабатывании SYNC все узлы, работающие синхронно, пытаются отправить свои данные почти одновременно. Происходит большое количество арбитражных процессов, а телеграммы сортируются в порядке приоритета передачи по шине. Обычно это не критично, поскольку эти телеграммы содержат некоторые байты данных и вызывают последовательность прерываний приема на узлах CAN, которая действительно быстрая, но тем не менее управляемая.

Под нагрузкой шины чаще всего понимают усредненное за несколько первичных циклов значение, то есть среднее значение за 100-500 мс. CAN и, следовательно, CANopen действительно способны управлять загрузкой шины, близкой к 100%, в течение длительных периодов времени, но это означает, что полоса пропускания недоступна для любых повторений, которые могут быть необходимы из-за помех, для асинхронных сообщений об ошибках, параметризации и т. д. . Очевидно, что доминирующий тип связи будет иметь большое влияние на соответствующий уровень загрузки шины: сеть с полностью циклической синхронной работой всегда в любом случае близка к наихудшему состоянию и, следовательно, может эксплуатироваться со значениями в пределах 70–70%. Диапазон 80%. Эту цифру очень сложно определить для сети, полностью управляемой событиями: необходимо оценить, сколько событий, дополнительных к текущему состоянию системы, может произойти, и как долго может длиться результирующий всплеск - другими словами, для как долго будет задерживаться сообщение с самым низким приоритетом. Если это значение приемлемо для приложения, то текущая загрузка шины приемлема. Как правило, обычно можно предположить, что управляемая событиями сеть, работающая с базовой нагрузкой 30–40 %, имеет достаточный резерв для наихудших сценариев, но это предположение не отменяет необходимости тщательного анализа, если задержки могут имеют критические результаты для завода.

Объем данных в объектах данных процесса, конечно, так же важен, как и параметры связи: отображение PDO.