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

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 - меняем на хоть что
Ответ:
C0 00 02 00 09 00 00 00 00 ZZ    01 01 00 00 0F 0C

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

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

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

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

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

Потом код завершения 00 00 - выполнилась, нет ошибок

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




Запись: 01 02