Чтение/запись нескольких регистров ModBus RTU

[Прохожий]

По порядку. В указаном Вами документе есть рекомендации по параметрам линий связи, к-е используются при обмене данными между мастером и слейвами ModBus. В частности и требование поляризации.
Но почему Вы решили, что 1) это требование как-то отностися к ModBus (Оно относится к 485) и 2) Мы его не выполняем.

В указанных мной документах содержатся не рекомендации, а требования, что несколько меняет дело.
По п. 1. Если внимательно прочесть [1], то там четко указано, что если Вы применяете RS 485 в качестве 1-го уровня Modbus, то он обязан соответствовать дополнительным требованиям, изложенным там же. В частности - это поляризация и индикация и не только это.
По п. 2. Если Вы выполняете эти требования, то это должно быть оговорено в соответствующем месте в документации. Это опять же следует из [1].

А я разве говорил о ModBus? Я говорил о том, как программист обращается к переменным в модулях ModBus master и ModBus slave. Это особенность среды разработки и компилятора CoDeSys. Или Вы хотите, чтобы для работы с ModBus были специальные "сертифицированные" переменные и команды специально для ModBus?

1-й уровень сделан полностью, т.к. иначе вы бы не смогли работать с устройствами ModBus. У Вас не работает связь по 485?
7-й уровень также реализован полностью, можно посылать и принимать неск. регистров за раз. Где не работает?

RS485 работает вполне пристойно, спору нет. Но для полного удовлетворения требованиям, изложенным в [1] этого недостаточно.
По поводу регистров. Регистр в понимании [2] - это неделимая сущность длиною 16 бит и никак иначе. У Вас же выходит, что пользователю надо оперировать 8 битными промежуточными переменными, что противоречит требованиям [2].
Да, прочесть/записать группу регистров можно, но через дополнительную сущность - строку из 8 битных элементов. Так быть не должно. Стандарт должен выполняться непосредственно.
По моему скромному мнению, стандарты для того и писаны, чтобы разработчик их соблюдал неукоснительно, а не только тогда, когда ему это удобно. Форма исполнения стандарта должна соблюдаться до запятой.

С удовольствием Вас выслушаю и постараюсь помочь! Сотрудничество приветствуется.

1. На мой взгляд, в Register Input Module и в Register Output Module в раздел под вкладкой Module Parameters необходимо добавить число читаемых/записываемых регистров, аналогично тому, как это сделано в соответствующих строковых модулях.
2. При этом, из выпадающего списка возможных команд необходимо убрать команды 0х70 и 0х71 соответственно, дабы не нарушать идеологию.
3. Каждому из регистровых модулей, в этом случае, надо сопоставить массив из 16 битных переменных целого типа длиной в читаемое/записываемое число регистров.
4. Из строковых модулей необходимо убрать команды 0х03, 0х04, 0x06, 0х10, оставив их только для регистровых модулей.
5. Все остальное может остаться "как есть", поскольку просто расширяет возможности протокола.
В этом случае формальных претензий по реализации 7-го уровня Modbus не останется.
Лучше, конечно, выделить Modbus в отдельный тип протокола, отличный от остальных (локальных типа Owen или DCON) и вообще инкапсулировать настройку конфигурации этой шины, как это сделано во многих ПЛК по отношению к PROFIBUS или DeviceNet. Понятно, что это почти неосуществимо.

И если позволите, несколько слов о впечатлениях от ПЛК100/150/154. Мне приходится иметь дело с клоном CodeSys от Beckhoff под названием TwinCat. Это дело работает на промышленной PC того же бренда и управляет достаточно сложным агрегатом.
Так вот, он больше похож на PLC в плане программирования и отслеживания различных процессов, чем ПЛК100/150/154, который больше напоминает компьютер со всеми его недостатками.
За счет тщательного соблюдения стандартов, немцам удалось полностью скрыть все сложности управления разношерстной удаленкой - начиная от WagoSystems и заканчивая энкодерами малоизвестных производителей. Это в свою очередь, позволяет обслуживать сие оборудование с помощью простого линейного персонала (наладчики КИПиА), понятия не имеющего о строковых переменных и указателях и привыкшего мыслить исключительно в терминах LAD.
В конечном счете, программист Вашего ПЛК - это промежуточное звено. Последняяя инстанция - наладчик КИПиА и технолог на производстве. И от них будет зависеть успех или неуспех Ваших ПЛК.