Сети‎ > ‎

CANOpen в Modicon Premium

                                                                              Немного бытовой философии.

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

Известно, что CANOpen базируется на CAN. В Modicon Premium конфигурирование CANOpen для комм. карты TSX CPP110 производится в SyCON. Всегда хотел попробовать каким образом можно создать сеть, в которой NMT Slave могут послать данные другому NMT Slave, или NMT Master послать T-PDO одновременно на несколько R-PDO. Времени для проверки (такого любимого для меня занятия) у меня не было. Пока не случилось это
http://plcforum.uz.ua/viewtopic.php?f=27&t=14940, которое отодвинуло все важные дела на задний план. Теоретически задача вроде как должна быть нормально реализована. И я решил проверить действительно ли на практике это невозможно.

Начал с Premium так как M340 с CANOpen в лаборатории сейчас нет.

                                                                                                         
  Теория.

Пока знаний у меня вроде как хватает, чтобы сконфигурировать CANOpen для классической задачи: PLC (NMT Master) связывается с другими устройствами (NMT Slave) посредством PDO. В SyCON по сути идет конфигурирование сети и NMT Slave, PDO которых связываются с PDO NMT Master-а. Связи T-PDO и R-PDO проводятся по COB-ID, которые автоматически назначаются по схеме распределения по умолчанию. Наполнение PDO (PDO-Mapping) тоже конфигурируется. Для каждого PDO также указывается диапазон входов-выходов ПЛК, на которые лягут эти PDO.

Поставленную задачу можно сформулировать так: T-PDO NMT Master должен связаться с R-PDO нескольких NMT Slave. Значит, нужно чтоб:

1. Нужные R-PDO на каждом NMT Slave имели тот же COB-ID что и T-PDO на NMT Master.

2. Нужные R-PDO проецировались на те же переменные NMT Master.

Вроде как первое условие должно привести к выполнению второго, поскольку только один T-PDO связывается со всеми R-PDO. Но как это объяснить SyCONу?

                                                            Уточнение постановки задачи.

В университетской лаборатории Национального университета пищевых технологий (А-532), где я работаю, в настоящее время есть только два NMT Slave: Altivar 71 и Advantys STB. Есть две карточки NMT Master CPP 110, одна в Premium с PL7, другая в Premium с UNITY. Испытания предполагаются проводить на ПЛК с UNITY. В этих условиях предполагается создать такую систему, в которой значение одного слова с ПЛК (%MW30), одновременно запишется в слова этих девайсов. За неимением лучшего варианта это будут дискретные выходы Advantys (2 объекта 8bit Output Block No 1, Idx=6200.1 и 8bit Output Block No 2, Idx=6200.2) и дискретные выходы частотника (OL1R, Idx=2016.D). 

                                                           
  Что получилось через SyCON.

-------------------------------- часть 1. нормальная конфигурация -------------------------------

В SyCON я добавил два девайса: с именем RIO - Advantys STB и именем PDS – Altivar 71. Дальше для кратности буду их называть по имени. RIO - адрес 1, PDS - адрес 2. В оба устройства добавил по одному R-PDO1 со следующими настройками PDO Mapping:

- для R-PDO1 на RIO = 8bit Output Block No 1, Idx=6200.1 и 8bit Output Block No 1, Idx=6200.2;

- для R-PDO1 на PDS = OL1R, Idx=2016.D

Для обратной связи добавил по одному T-PDO с PDO-Mapping аналогичному T-PDO:

- для T-PDO на RIO = 8bit Input Block No 3, Idx=6200.3 и 8bit Input Block No 5, Idx=6200.5 (учитывая что у меня еще входной дискетный модуль, значения выходов следуют искать именно в этих объектах, но это не приницпиально);

- для T-PDO на PDS = OL1R, Idx=2016.D (то же самое что и для R-PDO).

Сконфигурировал на UNITY карточку, выделил для области выходов переменные %MW30:2, для области входов %MW0:2.

                                                                  Итого имеем:

RIO: R-PDO1, COB-ID=513, %MW30, синхронно по каждому SYNC – запись 2*8 дискретных выходов

T-PDO1, COB-ID=385, %MW0 – чтение состояния 2*8 дискретных выходов


PDS: R-PDO1, COB-ID=514, %MW31, синхронно по каждому SYNC – запись дискретных выходов (16 бит)

T-PDO1, COB-ID=386, %MW1 – чтение состояния дискретных выходов (16 бит)

Все пока без чудес. Запустил, проверил, все нормально работает.


------------------------------------часть 2. изощрения (или извращения ;-) )---------------

Для возможности изменения COB-ID в SyCON убрал там опции Automatic COB-ID Allocation и Process Data Autoadresing.

Поменял настройки в SyCON и получил следующую картину для R-PDO1:

RIO: R-PDO1, COB-ID=514, %MW30, по изменению

PDS: R-PDO1, COB-ID=514, %MW31, синхронно по каждому SYNC

Таким образом, оба R-PDO1 будут обновляться при каждом объекте SYNC с источника %MW31, или асинхронно, когда изменится в %MW30. Проверил, действительно так и есть. по крайней мере изменяется в обоих девайсах, когда меняю хотя-бы в одной переменной %MW30 или %MW31.

Для проекции R-PDO1 только на одну переменную NMT Master нужно прибегнуть к коду и функциям WRITE_VAR и даже SEND_REQ. Чем и буду заниматься в другой раз. Когда появится возможность поработать с самым новым М340 с CANOpen на борту, попробую и эту задачку.

 

Что не получилось через SyCON.

 Не все, конечно же, прошло так гладко.

  1. Отображение через SyCON R-PDO1 на обоих девайсах на ту же область памяти (что вроде как разрешается делать в SyCON) привело к невозможности сохранения проекта. Ну да ладно, попробую через SDO.
  2. Изменение COB-ID в RIO (Advantys) дало позитивный результат. А вот изменение COB-ID в PDS (Altivar) ни привело к ожидаемому результату. Тогда я решил проверить независимо от Advantys, можно ли вообще менять COB-ID в Altivar 71. Проверка показала что нельзя, COB-ID жестко связано с NODE-ID и не может изменяться. В данном случае это касается только Altivar 71, причем только нашего (DEMO), о других сказать ничего не могу, в доке тоже не нашел. То есть, если б нужно было б синхронно управлять такими Altivar 71, как у нас в аудитории, то ничего б не получилось. А вот с распределенкой Advantys получилось.

Общий вывод экспериментов такой. Синхронная посылка на несколько девайсов в CANOpen для карточки NMT-Master Modicon Premium – возможна. Оптимизацию этого процесса нужно пробовать через ручное конфигурирование PDO-обмена функциями для SDO WRITE_VAR.

 

24.03.2011 


Конфигурирования посредством SDO.

Итак продолжим. Рассуждения мои таковы. Если SyCON не хочет заказывать отображение на перекрывающиеся адреса, значит конфигурирование, по крайней мере частичное, нужно делать без SyCON. На самом деле, конфигурирование CANOpen Slave NMT Master-ом проходит посредством сервисов SDO, которые дают возможность считать или записать объект со Словаря Объектов по его индексу и суб-индексу. В общем случае NMT Master управляет по такой последовательности:

1. после включения питания NMT Slave он проходит стадию инициализации (диагностика, получение адреса, скорости и т.д.);

2. дальше, при отсутствии ошибок он переходит в предоперационную стадию (Pre-Operational), при которой узлы могут обмениваться только посредством SDO; на этой стадии NMT Master отправляет все конфигурационные данные на NMT Slave посредством тех же SDO; напомню, что сервис PDO настраивается тоже Объектами Словаря, то есть запись этих настроек тоже производится с помощью SDO;

3. после заливки всей конфигурации, NMT Master переводит NMT Slave в режим Operational, где доступны как SDO так и PDO.

Таким образом, нам нужно вклинится во второй этап. Чтобы управлять последовательностью этапов программным путем, UNITY дает в настройках конфигурации карты выставить режим управления: Automatic, SemiAutomatic, ByProgramm. Вот что пишет хелп по этому поводу:

            The bus start-up can be performed in three ways:

-              Automatic: the bus configuration, communication management and the updating of slave I/Os are activated at start-up, without application intervention.

-              Semi-Automatic (bus alone): the bus configuration and communication management are activated at start-up but management of I/Os must be confirmed by the application using the corresponding language objects.

-              By program: the bus start-up should be fully managed by the application using the corresponding language objects.

 

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

%QW0.m.1.0.0 This bit is only used when the bus startup is managed by the application:

  • 1: activates the bus configuration
  • 0: deactivates the bus configuration

%QW0.m.1.0.1 This bit is used when the startup is semi-automatic or managed by the application

  • 1: activates data transfer on the bus
  • 0: deactivates data transfer on the bus

m номер процессорного модуля.

Конфигурируем опцию равной By program, и пробуем играться спец объектами. После старта ПЛК, Advantys замигал RUNом что означает, что он в режиме Pre-Operational, частотник Altivar через лицевую панель показал режим Pre-Operational, окно отладчика UNITY показал все девайсы красным. Устанавливаю %QW0.0.1.0.0 в 1, в окне отладчика все посинело, потом почернело, оба девайса перешли в Operational. Но посылка данных на девайсы не производится, поскольку %QW0.0.1.0.1=0. Следует отметить, что в машине состояний CANOpen такого режима я не нашел. Тем не менее перевод %QW0.0.1.0.1=1, дал возможность организовывать обмен PDO. Для скидывания предыдущих ошибок устанавливаю, а потом обнуляю %QW0.0.1.0.2.

Переводить NMT Slave с состояния в состояние вроде как научились. Это же (и не только) можно проделать через SEND_REQ, но это попозже. Теперь нужно попробовать что-то прочитать через SDO.

Переводим %QW0.0.1.0.0 и %QW0.0.1.0.1 в 0. Это не обязательно, но эксперимент будет чище, поскольку проверим на сколько сервис SDO работает в Pre-Operational режиме. В диагностическом окне UNITY генерим запрос (Enter Request) на чтение SDO (Read SDO) у частотника (адр 2): Index=1000, Subindex=0. Это Объект Словаря, отвечающий за тип девайса. В окне Response received записался результат: 92 01 01 00. Преобразовавши в нормальный вид получим  00010192, где по доке Bits 16-23 = Type of device (=1), Bits 00-15 = Device profile number (=402). Аналогично можно проделать для Advantys, результат на рисунке

Таким образом через SDO значения объектов читать можем, аналогично можно проводить и запись. Пока это все делаем без строчки кода. Пора вернуться к исходной задаче. В проекте SyCon посмотрим список объектов, пересылаемых девайсам посредством SDO (View->SDO Table). Напомню, что это те самые объекты, которые сконфигурируют те самые PDO, которые мы настроили в SyCON. Внешний вид приведенный на рисунке. Нас интересуют те объекты, которые отвечают за конфигурацию R-PDO1 на RIO (выделено красным). Зачем? Попробую объяснить.     

 

 

Настройка обмена PDO через Объекты Словаря.

За конфигурацию каждого PDO отвечают два Объекта Словаря: с типом PDO Mapping Parameters и PDO Communication Parameters. Первый отвечает за PDO Mapping (отображение объектов Словаря на PDO), второй за настройку обмена самого PDO (инициация обмена и др.). PDO Communication Parameters для R-PDO1 лежит в объекте 1400, а  PDO Mapping в 1600. По этому выписываем себе эти настройки.

 

Теперь нужно удалить R-PDO1 из RIO, поскольку он отображается на отдельную переменную в ПЛК. Проделываем это в SyCON, после чего все изменения (количество переменных) проделываем в UNITY. Следует отметить, что нужно поправить в SyCON отображение переменных для узла PDS, то есть базовый адрес сместить с 1 на 0. Заливаем конфигурацию в ПЛК.

Пробую менять нужный объект для настройки PDO – и… UNITY ругается, что не может этого сделать. Пробую много каких объектов изменить и несколько раз … - результат аналогичный. После долгих попыток, решил прочитать какой-нить SDO, как в предыдущем случае 1000. Результат аналогичный. Как же так? Только что получалось? Установил  %QW0.0.1.0.0 в 1, потом через секунды 3 (чтоб успело все сконфигурится) перевел опять в 0. Сделал запрос на чтение 1000 объекта – ооо! получилось!.

Честно скажу, пока толком объяснить это факт я не могу. Но NMT Master делает что-то с NMT Slave, после перехода их в предоперационное состояние. Это что-то, очевидно лежит в основе BootUp процессов, детали которых мне к сожалению пока не известны. Ладно, оставим BootUp на другой раз, когда буду играться с NMT-сообщениями на уровне CAN через функцию SEND_REQ.

Итак, пробуем менять Объекты на стадии Operational но перед обменом PDO (%QW0.0.1.0.0=1 а  %QW0.0.1.0.1=0). Мы должны поменять следующие Объекты:

1400.1 = 00 00 02 02 (Unsigned32 COB-ID=202 HEX или 514 DEC )

1400.2 = 01 (Unsigned8, Transmission Type = при каждом SYNC)

1600.0 = 02 (Unsigned8, количество отображаемых (Mapping) объектов)

1600.1 = 62 00 01 08 (Unsigned32, ID=6200, SubID=01, размер = 8 бит)

1600.2 = 62 00 02 08 (Unsigned32, ID=6200, SubID=02, размер = 8 бит)

Поочередно пересылаем эти Объекты в Словарь посредством SDO из диагностического окна. Следует отметить, что последовательность байт вписывается от младшего до старшего, то есть для Index=1600, SubIndex=1 в поле Value, нужно вписывать последовательность 08 01 00 62.

Проделав все записи, я перевел %QW0.0.1.0.1 в 1 и проверил будет ли изменятся выходы на RIO (Advantys), если я поменяю переменную, которая отвечает за выходы частотника? О чудо! Все получилось! Ну, или почти все.

 

Что не получилось.

Вопрос с режимом Preoperational остался для меня не понятным. Все изменения нужно делать в режиме Operational, но перед обменом PDO (%QW0.0.1.0.0=1 и %QW0.0.1.0.0=0). То есть, то же самое можно (и наверное целесообразнее) делать в режиме Semi-Automatic. Мало того, перевод в режим Preoperational и обратно в Operational производит скидывание всех настроек PDO. На счет последнего у меня есть какие то предположения, но это я буду проверять в следующий раз. Думаю что все эти нюансы связаны только с процедурой BootUP. Вот туда и полезу.

Ну а основная цель все равно выполнена. Естественно операции перевода девайсов из состояния в состояние, а также запись Объектов, отвечающих за PDO, надо делать программным путем. Но главное – для Modicon Premium это возможно! Единственное требование – это наличие в девайсах возможности изменения COB-ID.              

25.03.2011

 

Работа на канальном уровне CAN в TSX CPP110.

У меня сложилось мнение, что Шнейдер Электрик не очень любит распространяться по поводу поддержки работы комм. карты TSX CPP110 на канальном уровне. Тем не менее, когда-то мне попался документ "Premium or Micro and Standard CAN Device System User Guide" где показан пример передачи и приема кадров CAN с программы PL7. Недавно это было мной опробовано на UNITY. Как и предполагалось, поддержка интерфейса к канальному уровню  CAN осталась. А это значительно расширяет возможности. Сейчас предполагаю использовать эту возможность для передачи NMT-сообщений. В начале – немного теоретической части использования интерфейса. Предполагаю, что с основами строения CAN-кадров Вы знакомы, если нет – в Интернете много русскоязычных статей. Соответствующая глава есть и в нашей книге, но только на украинском языке.

Для отправки и приема сообщений по CAN (и не только) используется функция SEND_REQ. В хелпе UNITY касательно использования этой функции в Premium с CANOpen указано только два предназначения: диагностика и идентификация устройств. А в вышеуказанном найденном документе есть нужные нам примеры. Вот с них и попробуем вытащить нужную нам информацию.

В обоих случаях (передача и прием кадра) используется код запроса 16#009F. Вот синтаксис:

SEND_REQ (ADR := ADR#0.m.1.SYS , (*адрес карточки (m-номер модуля)*)

          CODE := 16#009F ,

          EMIS := T_SEND (*данные запроса, ANY_ARRAY_INT*),

          GEST := PARA_SNDREQ (*параметры контроля и управления функцией, ANY_ARRAY_INT*),

          RECP => T_RECV (*возвращаемые данные запроса,ANY_ARRAY_INT*));

По синтаксису в ST набил код, для генерации запрсов:

 

где описание переменных имеет следующий вид:

  

Нужно обратить внимание на массив T_SEND. Напомню, что запрос отправляется системе комм. карточки. По этой причине кроме данных CAN кадра, он включает также заголовок с уточнением типа операции (Action Code): 101 – передача кадра, 102 – прием кадра, 103 – передача с приемом. Дальше идет 2 слова CAN-ID что в терминах CANOpen является COB-ID. Старшее слово нужно только для 29-битных идентификаторов, но в случае 11-битных в таблице это слово остается и заполняется нулями. Дальше (T_SEND[3]-T_SEND[6]) идут данные кадра. Кадр CAN типа DATA_FRAME, может включать до 8 байт данных, то есть до 4 слов.

            Следующее, о чем не надо забывать, – это последнее слово из таблицы T_SENDREQ. При отправки данных туда нужно вписать количество отправляемых байт, включая 2 байта Action Code. При получении данных, в это же место впишется количество полученных байт.

0-й бит первого слова T_SENDREQ возводится в 1 при старте функции и возвращается в 0 системой при окончании ее обработки. Контроль результата выполнения можно посмотреть во втором слове. Остальные нюансы этой таблицы упустим.

Теперь, набрав программу, приступим к испытаниям. Настроив карту на программный режим старта шины, загружаю в ПЛК всю конфигурацию. В таблицу анимаций добавляю все нужные переменные для испытаний.

Старт ПЛК осуществился, но девайсы находятся в режиме pre-Operational. Теперь отправляю кадр на запуск девайса. Для этого используется коммуникационный NMT Объект формата:

    COB-ID=0, 1-й байт данных CS (команда)=01, 2-й байт данных NodeID=01              

Проверяем (не забываем вписать 8 в PARA_SENDREQ[3]):

После запуска функции, действительно устройство перешло в операционный режим.

Переводим девайсы в режиме pre-Operational:

COB-ID=0, 1-й байт данных CS (команда)=16#80, 2-й байт данных NodeID=01

Тоже получилось. На всякий случай перезапустим узел:

COB-ID=0, 1-й байт данных CS (команда)=16#81, 2-й байт данных NodeID=01

После всех этих операций, я пробую с диагностического окна отправить запрос на чтение посредством SDO 1000-го Объекта. И получаю ответ о негативном результате чтения.

Результат опыта показал, что отправка даже запроса на старт операционного режима не дала возможности считать объекты со Словаря посредством SDO. Достаточно один раз передергнуть %QW0.0.1.0.0 (0->1->0) и все начинает работать. Но инициировав шину (%QW0.0.1.0.0=1) автоматически все девайсы переводятся в операционный режим, а это не совсем то что нам нужно.

Напомню, что в SyCon есть еще настройка BootUp процедуры для каждого девайса. Тут поправьте меня кто-то, что именно в моих рассуждениях не так.

1. BootUp процедура определенная в SyCon для девайса работает после перехода узла в режим PreOperational. Почему я так решил? После включения узел проходит стадию инициализации (Reset Node), по поводу которой стандарт DS-301 говорит следующее:

 

The „initialisation“ state is divided into three sub-states (see Figure 49) in order to enable a complete

or partial reset of a node.

1. Initialising: This is the first sub-state the device enters after power-on or hardware reset. After finishing the basic node initialisation the device enters autonomously into the state Reset_Application.

2. Reset_Application: In this state the parameters of the manufacturer specific profile area and of the standardised device profile area are set to their power-on values. After setting of the power-on values the state Reset_Communication is entered autonomously.

3. Reset_Communication: In this state the parameters of the communication profile area are set to their power-on values. After this the state Initialisation is finished and the device executes the write boot-up object service and enters the state PRE-OPERATIONAL.

Power-on values are the last stored parameters. If storing is not supported or has not been executed or if the reset was preceded by a restore_default command (object 1011H), the power-on values are the default values according to the communication and device profile specifications.

 

Исходя из выше-изложенного, в стадию PRE-OPERATIONAL узел переходит автоматически через 3 под-стадии. После этого узел, используя BOOT-UP протокол, сообщает NMT Masterу о том, что он перешел в предоперационную стадию и готов к конфигурированию. А это значит, что вмешаться в прохождение всех под-стадий до PRE-OPERATIONAL NMT Master не может. Зато он может повторить эту последовательность, уже после BOOT-UP протокола.

2. Переменная %QW0.0.1.0.0 инициирует карточку, передачей всех настроек MT Masterа и автоматическим запуском всех девайсов. То есть, когда Premium стартует холодным стартом, но девайсы в это время остаются включены, не зависимо от того, что прописано в SyCon для BootUp процедуры девайса, он его все-равно переводит в опеарционнй режим. Однако это однозначно касается только Node Start. По моим наблюдениям другие стадии (например Configuration Download) проходят одинкаво при холодном старте как NMT Master так и девайсов.  

Вот это то и меня смутило 25.03.2011 (и до сих пор смущает): для первой инициализации NMT Master-а необходимо запустить всю шину %QW0.0.1.0.0=1, тем самым перевести все девайсы в операционный режим, потом чтобы нормально обмениваться SDO опять ее остановить %QW0.0.1.0.0=0. Повторюсь, по другому у меня не получается, поскольку не активировав шину хотя бы один раз, не получится обмениваться SDO.      

 

Тогда предполагаемый путь инициализации шины для обмена PDO в мультивещателном режиме такой:

- в конфигурации девайсов в SyCON отключяем в алгоритме BootUp две последние стадии: "Start node" и "Initiate PDO Data";

- в конфигурации CPP110 выставим режим загрузки Programm

- после холодного старта ПЛК включим шину %QW0.0.1.0.0=1;

- дождемся окончания конфигурации всех девайсов;

- отключим шину %QW0.0.1.0.0=0;

- зальем нужные настройки посредством SDO через функции WRITE_VAR;

- включим шину %QW0.0.1.0.0=1;

- дождемся активности всех девайсов;

-  включим обмен PDO %QW0.0.1.0.1=1.

 

Думаю, что еще подводные камни ждут впереди. Но я надеюсь, что корпус корабля выдержит ;-).

 

29.03.2011

Короткие "философские" заметки на ходу.

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

Вчера проверял программу и наткнулся на непонятные для меня вещи. Сегодня решил перечитать то, о чем я написал до этого. И обнаружил, что в ходе вчерашних и позавчерашних экспериментов я не учел опыт и результаты 25.03! Кроме того, я обнаружил факт, на который не обратил внимание. Запишу эти два факта:

1. Я забыл о том, что: "Мало того, перевод в режим Preoperational и обратно в Operational производит скидывание всех настроек PDO." (цитата из раздела "Что не получилось", 25.03). По причине моей забывчивости, был сформирован неправильный алгоритм в 29.03, а именно:

- отключим шину %QW0.0.1.0.0=0;

- зальем нужные настройки посредством SDO через функции WRITE_VAR;

- включим шину %QW0.0.1.0.0=1;

 По этому, перед доливкой SDO, очевидно шину отключать не надо. Вчера я обнаружил, что в процессе заливки SDO функцией WRITE_VAR при работе шины возникают  коммуникационные ошибки. Пока я склоняюсь к тому, что они возникают в результате конфликта низкоприоритетных SDO с объектами SYNC, HEARTBEAT, NODE GUARD и им подобным. Если это так, эту проблему можно обойти, повторной посылкой. Но для того, чтоб это проверить, нужно хорошо попотеть над диагностикой.

2. Я не обратил внимание на то, что при записи объетов 1600.1 и 1600.2 выдается ошибка. Это происходит даже в режиме Pre-Operational и отключенном %QW0.0.1.0.0=0, когда никакого обмена кроме SDO вроде как не должно быть. Почему я не обратил внимание? Потому что там уже находились те же объекты, какие мне надо было записать. Откуда они там взялись? Они там появились при инициализации Advantys, как сконфигурировано в Advantys-конфигураторе. Мало того, когда мне надо было уравнять типы на  Advantys и Altivar (поскольку в последнем было 16-битное слово а в Advantys один модуль DO занимает 1 байт), вначале я просто добавил Объект Словаря отвечающий за несуществующий второй DO модуль. В результате у меня ничего не получилось, пока я не добавил его физически! Результаты моих рассуждений надо бы еще проверить, но пока я для себя оставлю такую заметку. Но для этого эксперимента это не принципиально, поскольку это девайс-зависимые вещи.

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

 31.03.2011

 

Диагностические DFB.

В UNITY есть возможность пользоваться диагностическим буфером, куда можно заказать бросать все системные ошибки, а также программно бросать собственные. Этот диагностический буфер поддерживается такими клиентами (Вьюверами): средствами UNITY, некоторыми панелями XBTL, встроенными средствами WEB-серверов Ethernet модулей Modicon Premium, M340, Quantum. Можно много чего говорить, но нам он нужен для того, чтоб вести лог ошибок от функций записи посредством SDO. Первоначально нужно сформировать задачу.

Нужно создать такой функциональный блок, который будет отслеживать состояние группы аварийных входов, отвечающих за результат выполнения коммуникационных функций, и записывать аварийное сообщение в диагностический буфер для каждой из функций. В качестве аварийных сообщений будут отчетные значения (Operation Report и Communication Report) этих коммуникационных функций. Для кратности определим количество аварийных входов – 16.

Для активации возможности пользовательских сообщений в буфере диагностики, в свойствах Project Settings выставляется  Application Diagnostics. Сам диагностический буфер просматривается в UNITY в онлайне, как Diagnostic Viewer.

Общая схема создания использования диагностического функционального блока может быть такова:

- создается экземпляр DFB на основе шаблонного DFB типа USER_DIAG_ST_MODEL;

- по необходимости редактируется интерефейс и программа DFB;

- екземпляр диагностического DFB вызывается в нужном месте программы

USER_DIAG_ST_MODEL – это шаблон для создания своего диагностического DFB. В нем заложена возможность отслеживания одного аварийного входа (pin), аварийное значение которого =0 (1= нет аварии). Для регистрации сообщения в диагностическом буфере используется функция REGDFB, а для удаления – функция DEREG. Каждая регистрация возвращает уникальный идентификатор ошибки в буфере, по которой она и убирается с буфера. Также в функциональном блоке ведется контроль за переполнением буфера, чтобы можно было в последующем вызове попытаться снова добавить сообщение. Что нам нужно поменять:

- количество аварийных входов увеличить до 15

- поменять функцию  REGDFB на UREGDFB, которая дает возможность еще и текст писать в диагностическом буфере;

-  соответствующе изменить интерфейс.

Вот что у меня получилось. Внизу интерфейс:

 

А вот и сама секция DFB:

Или в тесктовом виде:
----------------------------------------------------------------------------------------------------------
(* Инициализация PIN_VAL *)
WORD_TO_BIT (IN := COND_WORD, BIT0 => PIN_VAL[0], BIT1 => PIN_VAL[1], BIT2 => PIN_VAL[2], BIT3 => PIN_VAL[3], BIT4 => PIN_VAL[4],
               BIT5 => PIN_VAL[5], BIT6 => PIN_VAL[6], BIT7 => PIN_VAL[7], BIT8 => PIN_VAL[8], BIT9 => PIN_VAL[9], BIT10 => PIN_VAL[10],
               BIT11 => PIN_VAL[11], BIT12 => PIN_VAL[12], BIT13 => PIN_VAL[13], BIT14 => PIN_VAL[14], BIT15 => PIN_VAL[15]);
IF (NOT ED) THEN (*если DFB не активный *)
for PIN_NB:=0 to 15 do
    IF ERROR[PIN_NB] THEN (* если была ошибка *)
        %SW77:=DEREG(ERROR_ID[PIN_NB]);(* убрать с буфера *)
        RESET(ERROR[PIN_NB]); STATUS:=0;(* reset Error and Status *)
    END_IF;
    RESET (BUFFULL);(*обнуление индикатора буфера ошибок*)
    RETURN;
end_for;
END_IF;
for PIN_NB:=0 to 15 do (* для каждого аварийного входа*)
IF (PIN_VAL[PIN_NB]) THEN (* PIN_VAL=1 нет ошибки*)
    IF ERROR[PIN_NB] THEN (* если была ошибка *)
        %SW77:=DEREG(ERROR_ID[PIN_NB]);(* убрать с буфера *)
        RESET(ERROR[PIN_NB]);(* отключить флаг ошибки *)
    END_IF;
    RESET (BUFFULL);(* Initialization of the full diagnostics buffer write indicator *)
ELSE    (* COND=0 есть ошибка*)
    IF NOT ERROR[PIN_NB] THEN (* если не было ошибок *)
        (* регистрируем *)
        UREGDFB(AREA :=AREA_NR,    (* зона *)
               CLAS :=16#004A,    (* класс ошибки *)
               SLEN :=0,          (* длина слова статуса 0, 2 или 4 байта *)
               CTRL :=OP_CTRL,    (* нужно ли подтвержение оператора*)
               PIN  :=PIN_NB,     (* номер пина ошибки *)
               VALPIN := PIN_VAL[PIN_NB], (* значение на пине *)
               UTXT:= MSG_TEXT[PIN_NB],    (* текст ошибки *)
        RSEL:=1,           (* на текст меняем комментарий *)
        ESTS => STATUS,    (* слово Status *)
               ERID =>ERROR_ID[PIN_NB],   (* идентификатор ошибки *)
               STAT => %SW76);    (* отчет о регистрации ошибки*)
        SET (ERROR[PIN_NB]);(* включить флаг ошибки *)
        IF (%SW76 <> 0)(* если регистрация прошля неудачно *)
        THEN SET( BUFFULL); (*буфер ошибок переполнен*);
        END_IF;
    ELSE (* если ошибка была уже до этого *)
        IF (BUFFULL) (* Если была попытка записи при переполненом буфере*)
        THEN
 (* пробуем зарегистрировать заново *)
                UREGDFB(AREA :=AREA_NR,     (* Machine zone monitored by the DFB *)
                       CLAS :=16#004A,     (* Error class *)
                       SLEN :=0,           (* Status length : 0, 2 or 4 bytes *)
                       CTRL :=OP_CTRL,     (* Operator acknowledgment *)
                       PIN  :=PIN_NB,    (* error Pin Number *)
                       VALPIN := PIN_VAL[PIN_NB],  (* Expected Value *) 
                       UTXT:= MSG_TEXT[PIN_NB],     (* текст ошибки *)
         RSEL:=1,            (* на текст меняем комментарий *)
         ESTS => STATUS,     (* Status : not used in this DFB *)
                       ERID =>ERROR_ID[PIN_NB],    (* Error identifier *)
                       STAT => %SW76);     (* Error registration report *)
                IF (%SW76 = 0 )(* если регистрация прошля удачно *)
                THEN  (*буфер ошибок не переполнен*)
                       RESET (BUFFULL);
                END_IF;
        END_IF;
     END_IF;
END_IF;
end_for;
-----------------------------------------------------------------------------------------
 

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

 

31.03.2011

 

Программа инициализации шины.

Времени на этой неделе практически не было. Но ужасно не люблю незаконченные работы, их и так много насобиралось. Сломано было много "копей", но конечный результат оказался еще проще, чем я думал. В итоге, нужно:

1.            В конфигурации SyCon в Node BootUP всех девайсов выставить все шаги кроме Initate PDO Data. Это продиктовано тем, что заливка и старт девайсов будет делаться автоматически, но активация обмена с ними будет производиться после дозаливки коммуникационными функциями WRITE_VAR.   

 

2. В конфигурации карточки ПЛК выставляем режим Semi Automatic, по той же причине что и в п.1.

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

В программе используется диагностический DFB для отлова ошибок обмена. Для записи Объектов словаря используется универсальная коммуникационная функция WRITE_VAR. Все комментарии даны в программе.  Если будет что-то не понятно – пишите.

 

Описание переменных и функциональных блоков:

 
Листинг подпрограммы с вызовом функции WRITE_VAR:

Листинг секции с основной программой.

 
 

Программа испытана на стенде. Как проверял:

- перегружал ПЛК;

- перегружал частотник;

- перегружал Advantys;

Изменяя %MW30 (например = 3) одновременно включались выходы на частотнике и Advantys.

Как и ожидалось (читайте "Короткие "философские" заметки на ходу"), Объекты 1600.2 и 1600.1 не записываются. Это видно с диагностического буфера:

512 – это 16#02 (Operation Report, 02 - Incorrect response) 16#00 (Communication Report). По хорошему, надо было бы конечно дополнительно исследовать эту проблему до конца. но для этой постановки задачи это не принципиально.

 

Подводя итоги, можно сказать следующее: решение поставленной в начале задачи существует. Но это пока касается Premium и девайсов с поддержкой динамически-настраиваемых PDO (свободно настраиваемые COB-ID и PDO-Mapping). Постараюсь проверить то же самое на М340. Но это будет другая тема.

 

 7.04.2011

 

Вот недавно взял плюзать М340 с CanOpen, всё сложилось

Видео YouTube

 

16.05.2013

С наилучшими пожеланиями

Александр Пупена.

Оставить комментарии Вы можете здесь http://pupena-san.blogspot.com

Comments