ЖУРНАЛ «СТА» №1/2008

дет передаваться в сеть с периодом 100 мс (один раз в четыре периода SYNC). Исходящие коммуникационные объ- екты, для которых параметру Transmission_Type задано значение 252, передаются в сеть в случае, если узел получил соответствующие запросы удалённой передачи (RTR) для указан- ных коммуникационных объектов и синхронизирующее сообщение SYNC. Значение 253 по смыслу аналогично 252, за исключением согласования пере- дачи запрашиваемого кадра с приходом синхронизирующего сообщения SYNC. Исходящие коммуникационные объ- екты, для которых установлено значение параметра Transmission_Type 254, переда- ются в сеть в случае, если истёк очеред- ной интервал времени, заданный пара- метром Event_Timer (в миллисекундах). Внимательный читатель мог заметить, что перечисленные значения параметров исходящих коммуникационных объек- тов не предусматривают возможность передачи по изменению данных. В са- мом деле, на первый взгляд кажется бо- лее разумным передавать в сеть только сообщения с изменившимися данными, тем самым уменьшая сетевой трафик и снижая нагрузку на узлыполучатели со- общений, чем «грузить» сеть постоян- ным трафиком. На самом деле все не так просто, как кажется на первый взгляд. Что означает «изменение данных»? Очевидно, изменение хотя бы одного бита информации среди восьми байт, пе- реносимых по сети одним сообщением. Значит, пользователь должен быть очень внимательным и осторожным при созда- нии конфигурации сети, дабы случайно не отобразить какуюнибудь часто изме- няющуюся переменную на поле данных некоторого коммуникационного объек- та. Если же это случилось, то сообщение будет передаваться в сеть по завершении каждого цикла прикладной программы, то есть по сути периодически. Следующее соображение. Пусть в спокойном состоянии, когда контроли- руемый технологический процесс нахо- дится в установившемся (стационар- ном) режиме и отсутствуют изменения дискретных и аналоговых сигналов, ко- торые должен «чувствовать» сервис внешней сети, в сети наблюдается пол- ная тишина, изредка прерываемая пе- риодическими сообщениями. Пусть да- лее произошли изменения в контроли- руемом процессе, концевые выключате- ли начали щёлкать, реле переключаться и т.д., и в сети начался настоящий шторм из сообщений, передаваемых по изменению данных. Очевидно, что пользователь должен при этом иметь стопроцентную уверенность, что он смоделировал все подобные ситуации во время тестирования системы и ни один из узловполучателей информа- ции не оказался перегруженным «вне- запно» возникающим сетевым трафи- ком. Однако стопроцентная уверен- ность возможна только в одном случае, если система изначально спроектирова- на и протестирована с расчётом на мак- симально возможный сетевой трафик, когда все сигналы изменяются макси- мально быстро. Наконец, последнее. Узлы (контрол- леры, рабочие станции и т.п.) могут на- чинать «слушать» сеть в произвольные моменты времени (изза выключения, обновлений, обслуживания и т.п.), а значит не иметь представления о том, что передавалось по сети минуту или час назад, если только не предприняты специальные меры по доставке данных таким узлам. Одной из специальных мер является настройка исходящих коммуникационных объектов таким об- разом, чтобы они передавались в сеть по изменению данных и с некоторым пе- риодом. Совершенно очевидно, что пе- риод этот должен быть согласован с максимальной скоростью изменения передаваемых значений параметров контролируемого процесса. Из сказанного следует простой вы- вод, который, вероятно, несколько не соответствует расхожим представлени- ям о способах построения промышлен- ных сетей: постоянная периодическая выдача всех данных по сети является не- обходимым и достаточным условием для создания корректной системы. Ра- зумеется, периоды выдачи разных сооб- щений должны соответствовать частоте дискретизации (или максимальной час- тоте изменения) соответствующих пе- редаваемых сигналов. Входящие коммуникационные объекты Сообщения, принимаемые контрол- лером по сети CAN, далее называются входящими коммуникационными объ- ектами. Пользователь добавляет в кон- фигурацию контроллера требуемое ко- личество описаний входящих комму- никационных объектов в поддерево CANopen InterfaceReceiving PDOs сек- ции PLC Configuration проекта при- кладной программы CoDeSys. Для каж- дого входящего коммуникационного объекта достаточно задать только иден- тификатор (COB_ID). Параметр Transmission_Type со значе- нием, равным 1, обеспечивает синхро- низацию ввода данных соответствующе- го коммуникационного объекта (PDO) в область входных данных приложения с появлением в сети синхронизирующего сообщения SYNC. То есть, если некото- рый ожидаемый на данном узле комму- никационный объект передаётся в сеть другим узлом по синхросообщению SYNC, то информация из этого комму- никационного объекта поступит прило- жению на данном узле при появлении в сети следующего сообщения SYNC. З н а ч е н и я 2  2 5 4 п а р а м е т р а Transmission_Type для входящих комму- 46 СТА 1/2008 АППА РАТ НЫ Е С Р Е Д С Т В А / П Р ОМЫШЛ Е ННЫ Е КОН Т Р ОЛЛ Е Р Ы www.cta.ru %IB0 %IB1 Область входных данных VAR_INPUT canInput0 AT %IB0: BYTE; canInput1 AT %IB1: BYTE; canInput2 AT %IB2: REAL; canInput3 AT %IB6: INT; END_VAR RxPDO1 BYTE Input BYTE Input %IB2 %IB6 DWORD Input WORD Input 0 1 2 3 4 5 6 7 8 COB ID Входящий коммуникационный объект Описатель входящего коммуникационного объекта Поле данных Рис. 27. Отображение входных переменных среды исполнения CoDeSys на поля данных входящих коммуникационных объектов CANopen