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

[Филоненко Владислав]

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

RS485 работает вполне пристойно, спору нет. Но для полного удовлетворения требованиям, изложенным в [1] этого недостаточно.

Да, документации это не отражено.

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

Так вот, в стандарте не описано и даже нет никакого упоминания о том, как реализуется этот протокол в устройстве. Вся суть стандартных протоколов в том, что стандартизуется внешняя часть, т.е. обмен МЕЖДУ приборами, а не внутренняя реализация, к-я остаётся на совести производителя и может быть ЛЮБОЙ.

1. На мой взгляд, в Register Input Module и в Register Output Module в раздел под вкладкой Module Parameters необходимо добавить число читаемых/записываемых регистров, аналогично тому, как это сделано в соответствующих строковых модулях.

Это невозможно технически, т.к. среда разработки CoDeSys не позволяет добавлять и удалять каналы ввода/вывода, а позволяет лишь добавлять/удалять модули. Т.е. В если сделать как Вы предлагаете, то необходимо создать модули 1 регистр, 2 регистра, 3 регистра и т.д. до 127 регистров. Что лишь усложнит и сделает более запутанной работу с протоколом.

2. При этом, из выпадающего списка возможных команд необходимо убрать команды 0х70 и 0х71 соответственно, дабы не нарушать идеологию.

Почему же? Протокол ModBus позволяет реализовывать свои собственные команды в специально зарезервированной номерной емкости, что мы и сделали по заказу одного из клиентов.

3. Каждому из регистровых модулей, в этом случае, надо сопоставить массив из 16 битных переменных целого типа длиной в читаемое/записываемое число регистров.

Т.е. даже если мне надо опросить 1 регистр, я вынужден вставлять модуль регистра с 127 регистрами? Или см. п.1 Массивы каналов в CoDeSys невозможны

4. Из строковых модулей необходимо убрать команды 0х03, 0х04, 0x06, 0х10, оставив их только для регистровых модулей.

мы делаем устройство, к-е будет работать с реальными приборами, а не точно соотв. стандарту, т.к. в реальной жизни производители делают все что им пожелается и приходится подстраиваться, иначе такое "соответствующее стандарту" устройство никому не нужно!

К примеру, ответьте мне на такой вопрос, как передать число с плавающей точкой по стандарту ModBus?

Лучше, конечно, выделить Modbus в отдельный тип протокола, отличный от остальных (локальных типа Owen или DCON) и вообще инкапсулировать настройку конфигурации этой шины, как это сделано во многих ПЛК по отношению к PROFIBUS или DeviceNet. Понятно, что это почти неосуществимо.

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

Вот только при попытке подключить к WAGO не их устройство Вы огребете огромные проблемы с его подключением. И все из-за того, что такие "красявости" как в Beckhoff и WAGO возможны только при использовании оборудования, полностью соответствующего стандарту, а зачастую только ограниченного круга моделей и производителей, о которых заложена на заводе информация в ПЛК. И за "стандартизацию" потребитель должен переплачивать в 3-10 раз.
В России такие вещи недопустимы (если Вы не из Газпрома). Все хотят подешевле, универсальнее, гибче. Что мы и попытались сделать.