✎ dev:hardware:omron:protocol [ПромАвтоматика]

Эта страница только для чтения. Вы можете посмотреть исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
У омрона есть две вариации протокола: С (да, так называется протокол) и FINS. Первый нигде не используется и имеет кучу ограничений, был обычно ориентирован на работу по COM порту, потом сделали универсальный FINS и он стал использоваться везде, его и будем рассматривать.

Подробно все расписано в русском мануале w342_cs_cj_cp_nsj_communications_commands_reference_manual_ru.pdf

Для изучения так же лучше установить программу Omron Multiway (OMETH v10.17 или выше) и лежит она только на французской версии сайта омрона.

Обмен осуществляется по протоколу UDP на сетевой адрес контроллера (192.168.2.250) на настроенный порт (обычно 9600, и это не скорость). Так же контроллер умеет отвечать на пинг.

Заголовочная часть запроса очень сложная и для нас практически не меняется, т.к. непонятные поля нужны для сложной связи когда пакет проходит через контроллер как через маршрутизатор уходит в другую сеть, может даже не ethernet, там связывается с другим контроллером и тот уже передает ее устройству назначения. кстати, устройствами назначения могут быть не только ПЛК, а что угодно. Протокол FINS не привязан к средам передачи и устройствам, поэтому на нем возможны сложные передачи данных, когда два компа общаются между собой через контроллеры соединенные второй линией профибаса в соседних цехах, причем сами разговаривать с контроллером на ethernet/usb или RS. Естественно, протокол сам ничего не делает, надо заранее все прописать в настройках, сформировать сети, пронумеровать всю последовательность передач, на это собственно и нужно столько полей. Мы ставим, что ничего не надо никуда транслировать, мы общаемся напрямую, и забываем про все поля. Итого сам заголовок выглядит так:

<code>80 00 03 00 00 00 00 09 00 №№  </code>
каждая цифра это один байт в HEX 

**80** - говорит, что мы хотим ответ на наш запрос, а не молча выполнить его.

**№№** - это порядковый номер запроса. Начинаем с 00 и пошли увеличивать. Нужно для правильного разбора, что бы ответ от старого запроса не принять за текущий.

Так же возможна последовательность: <code>80 00 03 00 FA 00 00 09 00 №№</code>

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

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

Считывание:
<code>01 01 KK AA AA AA NN NN</code>

Сначала код команды считывания области памяти **01 01** 

Потом **KK** - это код области памяти и тип данных. Тут надо почитать таблицу 5-2-2 мануала и определить, что поскольку мы работаем только с областью CIO и размениваться на биты не желаем, а хотим затягивать сразу словами, то у нас этот байт всегда равен B0.

Далее **AA-AA-AA** адрес начала области чтения, причем первые **AA-AA** это байты, а последний **AA** это биты. Помним, что мы настроили модули ввода на область CIO 3300, но тут 3300 это десятичная система, а в hex это у нас 0C E4, а биты нам нужны все с нулевого поэтому на конце 00 (экспериментально подобрал). Итого адрес OC E4 00.

**NN-NN** сколько слов читать.

Итого:
Запрос
<code>
80 00 03 00 00 00 00 09 00 ZZ    01 01 B0 0C E4 00 00 01
</code>
**ZZ** - меняем на хоть что
Ответ, приходит через ~5 мс:
<code>C0 00 02 00 09 00 00 00 00 ZZ    01 01 00 00 0F 0C
</code>

Что значит ответ, можно почитать в разделе 3-3-3 мануала:
С0 это заголовок. мы посылали 80, т.е. 1000 0000 bin , он ответил нам 1100 0000 bin, взведенный битик говорит, что это ответ, а не запрос.

**00 02** - всегда так

далее непереводимая комбинация, которая означает все те маршрутизирующие поля, которые мы не трогаем, только и источник (первые 3 байта) поменян местами с приемником (следующие 3 байта).

**ZZ** это наш счетчик

Далее идет дубликат команды команды **01 01**

Потом код завершения **00 00** - выполнилась, нет ошибок (коды см 5-1-3 мануала)

Ну и само слово из памяти, которое мы запрашивали: 0F 0C.



Чтение по отдельным регистрам

<code>01 04 KK AA AA AA [ KK AA AA AA ]</code>

Сначала код команды считывания отдельных регистров **01 04** 

Потом **KK** - это код области памяти и тип данных. Тут надо почитать таблицу 5-3 мануала и определить, что поскольку мы работаем только с областью CIO и размениваться на биты не желаем, а хотим затягивать сразу словами, то у нас этот байт равен B0.

Далее **AA-AA-AA** адрес слова которое будем читать, причем первые **AA-AA** это байты, а последний **AA** это биты. Помним, что мы настроили модули ввода на область CIO 3300, но тут 3300 это десятичная система, а в hex это у нас 0C E4, а биты нам нужны все с нулевого поэтому на конце 00 (экспериментально подобрал). Итого адрес OC E4 00.

Далее, можно указать еще адреса регистров, которые надо прочитать. Они дополнительно дописываются, так же по 4 байта "KK AA AA AA".



Итого:
Запрос
<code>
80 00 03 00 00 00 00 09 00 ZZ   01 04   B0 0C E4 00  B0 0C E5 00
</code>

**ZZ** - меняем на хоть что
Ответ, приходит через ~5 мс:
<code>C0 00 02 00 09 00 00 00 00 ZZ  01 04  00 00   B0 00 28   B0 00 00
</code>

Начальная часть аналогична команде чтения.

Далее идет дубликат команды команды **01 04**

Потом код завершения **00 00** - выполнилась, нет ошибок (коды см 5-1-3 мануала)

Далее идет список: код области памяти (байт) - значение (слово). 
Мы запрашивали два слова из области B0.  Ответ  B0 00 28   B0 00 00 - означает что это CIO с значением 0028h и CIO с значением 0000h.





Запись: <code>01 02 KK AA AA AA NN NN FF FF ....</code>

Код команды **01 02**

**KK**, **AA-AA-AA** и даже **NN-NN** аналогично команде чтения. мы помним, что выводы модулей мы поместили в ячейки CIO 3200. Поэтому адрес записи у нас 0С 80 00.

Далее **FF** - данные которые нужно записать. Естественно, количество байт должно быть равно числу слов умножить на 2.

Пример запроса, зажигает светодиоды на ICP DAS:
<code>80 00 03 00 00 00 00 09 00 ZZ   01 02 B0 0C 80 00 00 01 00 FF</code>
(потушить можно заменив байт в конце на 00)

Ответ:
<code>C0 00 02 00 09 00 00 00 00 ZZ   01 02 00 00</code>
структура ответа полностью аналогична чтению



Ну и напоследок.
В мануале W409-RU2-01+CS(J)1W-PRM+OperManual.pdf есть разделы 4-1 и 4-2, там описывается области данных модулей ввода/вывода, и там есть таблица 4-1-1, которая говорит какой модуль в какую область копируется. Наш модуль попал в номер 2, это CIO 1550-1574.
Нам интересны слова, которые находятся по смещению +7 и +9 т.к. там результат связи. 
В CIO1557 приводится результат опроса суммарно по шине, обычно там 00 11 hex. В этом числе младший бит = 1 означает, что все устройства на шине профибас ответили (см 4-6-2 этого мануала).


В CIO1559 и далее находится битовая карта всех устройств на шине профибас. 1 значит отвечает, 0 - нет.
Например: значение 02 20 hex  это 0000 0010  0010 0000 - значит устройство с адресом 5 и 9 ответили в цикле опроса. Естественно в профибасе может быть больше 16 устройств так что последующие слова это продолжение битовой карты.

Ну и в CIO1558 время цикла опроса всей шины профибас. в BCD формате с дискретностью 0.1 мс.
Пример: 0762 hex это 76.2 мс

Ну и на последок команда чтения. Запрос 3х слов из области CIO 1557  (т.е. 06 15 в hex)
<code>80 00 03 00 00 00 00 09 00 ZZ     01 01 B0 06 15 00 00 03</code>
Ответы:
все опрашивается:
<code>C0 00 02 00 09 00 00 00 00 ZZ     01 01 00 00 00 11 07 01 02 20</code>
тут 0701 это время

отключили 5 модуль:
<code>C0 00 02 00 09 00 00 00 00 ZZ     01 01 00 00 00 10 07 20 02 00</code>

отключили 9 модуль:
<code>C0 00 02 00 09 00 00 00 00 ZZ     01 01 00 00 00 10 07 42 00 20</code>

отключили и 5 и 9 модули:
<code>C0 00 02 00 09 00 00 00 00 ZZ     01 01 00 00 00 10 07 58 00 00</code>