Чтение/запись нескольких регистров 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 раз.
В России такие вещи недопустимы (если Вы не из Газпрома). Все хотят подешевле, универсальнее, гибче. Что мы и попытались сделать.

[Прохожий]

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

Ну почему же? В разделах 4.2 Data Encoding и 4.3 MODBUS Data model документа MODBUS Application Protocol Specification V1.1b как раз и идет речь о представлении данных именно внутри устройства.

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

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

Зачем же так? Можно сделать так же как у Вас есть в настоящий момент. Регистровый модуль только не со строковым массивом, а с массивом из 16 битных переменных. Длина массива может быть определена, исходя из удобства пользования. К примеру, модули с 4, 8 и 16 регистрами за одну транзакцию. Для большинства применений, ИМХО, их будет вполне достаточно.

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

Вы меня немного не поняли, извините меня за косноязычие. Команды 0х70 и 0х71 необходимо убрать из регистровых модулей. А в строковых модулях им самое место. Убирать их "вообще" - не надо.

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

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

Для этого существуют команды 20 (0x14) Read File Record и 21 (0x15) Write File Record, позволяющие группировать данные произвольным образом, правда только регистрами по 16 бит. Для плавающих чисел это несущественно. Можно даже передавать структуры данных, соответствующие "внутренностям" того или иного прибора.

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

Наша беда в том, что мы (и я в том числе) в погоне за неким пресловутым "универсализмом" выбрасываем из виду одну немаловажную деталь - конечную эксплуатацию. Поэтому, все наши изделия больше похожи на незаконченные радиолюбительские поделки, а не на конкретные девайсы, как это сделано у немцев. Это плохо.
А идея с файлами - описателями устройств, поставляемыми вместе с устройствами (PROFIBUS) не так уж и плоха.

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

Согласен. В настоящий момент для России все это верно. Однако, время идет...
И в данном случае потребитель платит эти деньги за оборудование для того, чтобы не брать на работу достаточно дорогостоящего пром. программиста (для нашего региона не менее 1 к$ в месяц), а обойтись одним технологом, который и так имеет место быть.
В случае гибкости, универсализма и дешивизны сделать это будет практически невозможно.
И кнечные потребители все больше склоняются к тому, что проще заплатить за "железки", чем потом маятся с капризным и амбициозным существом, коим является по сути пром. программист .
И еще. А кто, собственно, мешает Вашей организации сделать что-то похожее на Wago. И даже лучше.
Представьте - голова на основе Modbus на TCP/IP и куча модулей различного назначения, вплоть до полузаказных. В сочетании с чисто сетевым ПЛК с CoDeSys могло бы получиться достаточно красиво и дешево.

[Generator]

...И еще. А кто, собственно, мешает Вашей организации сделать что-то похожее на Wago. И даже лучше.
Представьте - голова на основе Modbus на TCP/IP и куча модулей различного назначения, вплоть до полузаказных. В сочетании с чисто сетевым ПЛК с CoDeSys могло бы получиться достаточно красиво и дешево.

да, да, полностью согласен, именно расширения модулями на внутренней шине ПЛК от ОВЕН очень не хватает.
В России свежая реализация такой идеи есть у Fastwell с их контроллерами узла сети Fastwell-IO, вот, только там свои недостатки .

[Прохожий]

да, да, полностью согласен, именно расширения модулями на внутренней шине ПЛК от ОВЕН очень не хватает.
В России свежая реализация такой идеи есть у Fastwell с их контроллерами узла сети Fastwell-IO, вот, только там свои недостатки .

Уважаемый, Generator. Вы, случаем, не в курсе почем это добро у Fastwell? И какие основные недостатки, по Вашему мнению, у этой серии ПЛК?
Если честно, то я имел ввиду несколько иной подход. А именно:
1. Голова у распределенного модуля без "мозгов". Ее задача - обеспечение транспорта данных к субмодулям. ModBus поверх RS485 или CAN, как у Fastwel - это крайне медленно. Поэтому потребуется либо увеличение скорости RS485 как минимум до 5 Мбод, либо ModBus поверх TCP/IP.
2. Всеми удаленными узлами управляет нечто, похожее на ПЛК100 с CoDeSys, но без каких бы то ни было входов и выходов.
3. В удаленный узел могут быть добавлены разные вкусности типа поддержки простейшего HTTP или FTP сервера (лучше HTTP), если это не сильно удорожит "голову".
В этом случае голый сетевой контроллер стоил бы не очень дорого, удаленная голова тоже. Ну а стоимость субмодулей в обоих случаях одинакова.
Гибкость системы в целом была бы несколько выше, чем в варианте Fastwell при той же стоимости. Можно было бы к одному сетевому контроллеру цеплять несколько "голов", находящихся в разных местах.

[Generator]

Уважаемый, Generator. Вы, случаем, не в курсе почем это добро у Fastwell? И какие основные недостатки, по Вашему мнению, у этой серии ПЛК?

Прайсик на фаствел где-то завалялся, сори , хотя можно будет и поискать...
1. Вот-вот, именно "мозги" встроенные в контроллер узла сети можно и отнести к одному из недостатков, действительно хотелось бы иметь пусть и более "тупой" но более дешевый сетевой узел.
2. Насколько понимаю у фаствела в настоящее время есть проблемы с контроллером CPM703 Modbus TCP (единственном их контроллере с нормальной скоростью на полевой шине) - на офф.сайте фаствел информация о нем полностью отсутствует, хотя о его существовании было объявлено.
3. Платная версия софта, пусть и на базе CoDeSys.
4. Отсутствие нормальной техподдержки - загляните на их форум
5. Совершенно недостаточный объем тех.документации (по крайней мере выложенной для свободного доступа).
6. Ну и последнее: несмотря на конструктив от Wago, модули фаствел с ним несовместимы