Это старая версия документа.


У омрона есть две вариации протокола: С (да, так называется протокол) и 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. Естественно, протокол сам ничего не делает, надо заранее все прописать в настройках, сформировать сети, пронумеровать всю последовательность передач, на это собственно и нужно столько полей. Мы ставим, что ничего не надо никуда транслировать, мы общаемся напрямую, и забываем про все поля. Итого сам заголовок выглядит так:

80 00 03 00 00 00 00 09 00 №№  

каждая цифра это один байт в HEX

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

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

Так же возможна последовательность:

80 00 03 00 FA 00 00 09 00 №№

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

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

Считывание:

01 01 KK AA AA AA NN NN

Сначала код команды считывания области памяти 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 сколько слов читать.

Итого: Запрос

80 00 03 00 00 00 00 09 00 ZZ    01 01 B0 0C E4 00 00 01

ZZ - меняем на хоть что Ответ, приходит через ~5 мс:

C0 00 02 00 09 00 00 00 00 ZZ    01 01 00 00 0F 0C

Что значит ответ, можно почитать в разделе 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.

Запись:

01 02 KK AA AA AA NN NN FF FF ....

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

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

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

Пример запроса, зажигает светодиоды на ICP DAS:

80 00 03 00 00 00 00 09 00 ZZ   01 02 B0 0C 80 00 00 01 00 FF

(потушить можно заменив байт в конце на 00)

Ответ:

C0 00 02 00 09 00 00 00 00 ZZ   01 02 00 00

структура ответа полностью аналогична чтению

Ну и напоследок. В мануале 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)

80 00 03 00 00 00 00 09 00 ZZ     01 01 B0 06 15 00 00 03

Ответы: все опрашивается:

C0 00 02 00 09 00 00 00 00 ZZ     01 01 00 00 00 11 07 01 02 20

тут 0701 это время

отключили 5 модуль:

C0 00 02 00 09 00 00 00 00 ZZ     01 01 00 00 00 10 07 20 02 00

отключили 9 модуль:

C0 00 02 00 09 00 00 00 00 ZZ     01 01 00 00 00 10 07 42 00 20

отключили и 5 и 9 модули:

C0 00 02 00 09 00 00 00 00 ZZ     01 01 00 00 00 10 07 58 00 00
dev/hardware/omron/protocol.1575013912.txt.gz · Последние изменения: 2019/11/29 10:51 — vitaly
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0