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

[Milchuk]

Возможно ли в ПЛК посредством ModBus Master читать и писать сразу несколько регистров командами 0x03 и 0x10 либо другими? И как работает приём и передача посредством String modul? Нужно передавать только печатаемые символы? Всё это нужно для сокращения времени опроса по сети.

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

Можно, в 4-х байта и стрингах так и делается.
Стринг - вставляете модуль, задаете число передаваемых символов в параметре (по умолчанию 80), копируете побайтно в/из память канала стринга данные и все. Контрольная сумма подставляется автоматически.

[Milchuk]

Т.е. как я понимаю, организовать обмен с девайсами использующими команды 0x03 и 0x10 в полном объеме не удастся. (Например инвертора от OMRON)

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

это почему? Команды 0х03 и 0х10 поддержаны.

[Milchuk]

Получается, можно читать и писать несколько байт через стринг, но кроме нуля. Или я ошибаюсь?

[Василий Куц]

Если интересует запись любых символов и тд - можно создать байтовый регистр, сделать на него указатель, как к стрингу. Соответственно в байтовый регистр записываете в Hex код нужного символа, а через указатель получаете его уже в удобноваримом виде - как стринг...

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

Получается, можно читать и писать несколько байт через стринг, но кроме нуля. Или я ошибаюсь?
Не зря в модуле string есть параметр "число передаваемых байтов"! Вот сколько там байтов записано, столько и будет передано, хоть они там все нули... А string - потому, что канал нельзя объявить байтовым массивом. Единственное ограничение при передаче нуля - нельзя пользоваться функциями обработки строк, а надо брать указатель и побайтово читать/записывать в канал модуля String

[Milchuk]

Спасибо, я догадался.

[Прохожий]

Не зря в модуле string есть параметр "число передаваемых байтов"! Вот сколько там байтов записано, столько и будет передано, хоть они там все нули... А string - потому, что канал нельзя объявить байтовым массивом. Единственное ограничение при передаче нуля - нельзя пользоваться функциями обработки строк, а надо брать указатель и побайтово читать/записывать в канал модуля String
А меня интересует - в чем трудность реализации команд 0х03 и 0х10 для 16-ти разрядных слов? Откуда весь этот геморрой с указателями? Почему стандарт MODBUS/RTU поддерживается как-то через "зад"?
В стандарте ясно сказано, что минимальной информационной единицей является 16-разрядный регистр, а не какие-то там переменные типа string. То, что реализовано у Вас не может считаться полноценным протоколом MODBUS. На мой взгляд, все эти недочеты должны быть оговорены в документации, опять же сообразно со стандартом.
MODBUS - шина, предусматривающая поляризацию. У Вас ее нет. Почему?
Такая вольная трактовка стандартов может нанести определенный урон хорошему, в общем-то, девайсу (ПЛК 100/150/154) в нелегкой конкурентной борьбе.
Вопрос. Будет ли осуществляться "причесывание" этого недочета?

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

А меня интересует - в чем трудность реализации команд 0х03 и 0х10 для 16-ти разрядных слов? Откуда весь этот геморрой с указателями? Почему стандарт MODBUS/RTU поддерживается как-то через "зад"?
В стандарте ясно сказано, что минимальной информационной единицей является 16-разрядный регистр, а не какие-то там переменные типа string. То, что реализовано у Вас не может считаться полноценным протоколом MODBUS. На мой взгляд, все эти недочеты должны быть оговорены в документации, опять же сообразно со стандартом.
MODBUS - шина, предусматривающая поляризацию. У Вас ее нет. Почему?
Такая вольная трактовка стандартов может нанести определенный урон хорошему, в общем-то, девайсу (ПЛК 100/150/154) в нелегкой конкурентной борьбе.
Вопрос. Будет ли осуществляться "причесывание" этого недочета?

Никаких проблем с реализацией передачи регистра нет, он и представляется регистром. Или 2-я, если число с плавающей точкой.
Проблемы (да и проблемы ли это?) лишь с записью множества регистров 1 командой. И собственно к реализации протокола ModBus в контроллере они никакого отношения не имеют.
Просто фирма 3S Software когда делала свою среду разработки, вот вся такая нехорошая :) , не предусмотрела специального типа данных, называемого массив регистров ModBus. Редиска однозначно...
А предусмотрела универсальный тип байтовый массив (string), к-й можно использовать и с ModBus и с Овен и с DCON, и с "фирменным" протоколом от Васи Пупкина. (И зачем такая универсальность, вот раньше помню...включил рубильник - работает, выключил - не работает, красота...).
Но за универсальность надо немножко доплатить, а именно обратиться к этой структуре по указателю, что просто и не вызывает какого-либо серьезного умственного напряжения.

По поводу 2-й части:
ModBus - протокол передачи данных, а не шина. И у него не может быть никакой поляризации! :eek: :eek: :eek:
О какой поляризации вообще идет речь? В качестве физ. интерфейса передачи используется 485/232/TCP. Про какой интерфейс вы говорите?

P.S. А контроллер то видели?
P.P.S. Извините за вольный стиль, предыдущий пост настроил

[Прохожий]

Сразу оговорюсь, что критические замечания, высказываемые мной может быть не в очень корректной форме (заранее извиняюсь за это), направлены исключительно на исправление досадных недочетов в общем-то достаточно пристойном девайсе, а не на уязвление самолюбия его создателей.


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

В протоколе Modbus речи о плавающих числах и строках не идет. А вот о регистрах и об их передаче в нужном количестве идет. На каком основании Вы навязываете мне, как потребителю Вашего продукта, свою личную картину видения мира? Тем более, что она идет вразрез со стандартом, который Вы решили применить в своем устройстве.
Начнем с самого начала. Протокол Modbus, как впрочем и все остальные полевые протоколы, имеет несколько уровней (слоев) согласно соглашению OSI. Откроем документ MODBUS over serial line specification and implementation guide V1.02 (http://http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf) [1] на стр. 4 и внимательно ознакомимся с разделом 1.1. Из него мы узнаем, что документ MODBUS Application Protocol Specification V1.1b (http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf) [2] определяет только 7-ой уровень по соглашению OSI. А на самом деле Modbus - это совокупность 3-х уровней. В том числе и физического.
Поэтому Ваше высказывание


По поводу 2-й части:
ModBus - протокол передачи данных, а не шина. И у него не может быть никакой поляризации! :eek: :eek: :eek:
О какой поляризации вообще идет речь? В качестве физ. интерфейса передачи используется 485/232/TCP. Про какой интерфейс вы говорите?

отношу исключительно к тому, что у Вас просто не хватило времени ознакомиться с вышеобозначенными документами ввиду занятости основной работой. Потому как в документе [1] в разделе 3.4.6 речь идет именно о поляризации шины RS-485, если Вы применяете ее в своем устройстве. Правила использования RS-232 изложены в том же документе, в разделе 3.3.5. Особенности применения TCP/IP оговорены в документе MODBUS Messaging on TCP/IP Implementation Guide V1.0b (http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf).
В свете вышеизложенного Ваша фраза


Просто фирма 3S Software когда делала свою среду разработки, вот вся такая нехорошая :) , не предусмотрела специального типа данных, называемого массив регистров ModBus. Редиска однозначно...
А предусмотрела универсальный тип байтовый массив (string), к-й можно использовать и с ModBus и с Овен и с DCON, и с "фирменным" протоколом от Васи Пупкина. (И зачем такая универсальность, вот раньше помню...включил рубильник - работает, выключил - не работает, красота...).
Но за универсальность надо немножко доплатить, а именно обратиться к этой структуре по указателю, что просто и не вызывает какого-либо серьезного умственного напряжения.

выглядит крайне неубедительно. Потому как в разделе 4.2 документа [2] ясно сказано, что "MODBUS uses a ‘big-Endian’ representation for addresses and data items", а вовсе не какой-то там "универсальный тип байтовый массив (string)". Универсальность тут не при чем. Дело в том, что если Вы взялись следовать какому либо стандарту, то его надо выполнять полностью, а не частично. В противном случае необходимо сменить название протокола, как, например, это сделала фирма OMRON в своих приводах.


P.S. А контроллер то видели?

Не только видел, но и работал с ним. В настоящий момент выполняется уже второй проект на его основе. Поэтому относительно Modbus vs ПЛК "Овен" могу сказать следующее:
1-ый уровень Modbus - не выполнен (нет возможности поляризации на RS485 и соответствующей обязательной индикации в соответствии с [1]),
2-ой уровень выполнен в полном объеме,
7-ой уровень - выполнен частично (не реализованы в полном объеме команды чтения и записи множества регистров в соответствии с [2]).
Лично для меня (условно, поскольку я не один такой) протоколы Овен, DCON и имени Васи Пупкина интереса не представляют. В моих проектах они не используются, поскольку носят локальный характер и нестандартизованы в том смысле как это сделано с PROFIBUS, Modbus, DeviceNet, CanOpen и прочими FieldBus протоколами.


P.P.S. Извините за вольный стиль, предыдущий пост настроил

Ну и Вы тоже, извиняйте. Искренне желаю успехов на ниве ПЛК строения, поскольку у нас в стране Вы, пожалуй, единственные, кто это делает по-честному. Надеюсь на понимание в вопросах применения Modbus.
Если хотите, могу изложить свое видение этого вопроса применительно к Вашим ПЛК с вполне конкретными предложениями. На самом деле, привести все в норму не затратно и не сложно.

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

Сразу оговорюсь, что критические замечания, высказываемые мной может быть не в очень корректной форме (заранее извиняюсь за это), направлены исключительно на исправление досадных недочетов в общем-то достаточно пристойном девайсе, а не на уязвление самолюбия его создателей.

И меня тоже извините, не удержался.



В протоколе Modbus речи о плавающих числах и строках не идет. А вот о регистрах и об их передаче в нужном количестве идет. На каком основании Вы навязываете мне, как потребителю Вашего продукта, свою личную картину видения мира? Тем более, что она идет вразрез со стандартом, который Вы решили применить в своем устройстве.
Начнем с самого начала. Протокол Modbus, как впрочем и все остальные полевые протоколы, имеет несколько уровней (слоев) согласно соглашению OSI. Откроем документ MODBUS over serial line specification and implementation guide V1.02 (http://http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf) [1] на стр. 4 и внимательно ознакомимся с разделом 1.1. Из него мы узнаем, что документ MODBUS Application Protocol Specification V1.1b (http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf) [2] определяет только 7-ой уровень по соглашению OSI. А на самом деле Modbus - это совокупность 3-х уровней. В том числе и физического.
Поэтому Ваше высказывание
отношу исключительно к тому, что у Вас просто не хватило времени ознакомиться с вышеобозначенными документами ввиду занятости основной работой. Потому как в документе [1] в разделе 3.4.6 речь идет именно о поляризации шины RS-485, если Вы применяете ее в своем устройстве.
Правила использования RS-232 изложены в том же документе, в разделе 3.3.5. Особенности применения TCP/IP оговорены в документе MODBUS Messaging on TCP/IP Implementation Guide V1.0b (http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf).

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



Потому как в разделе 4.2 документа [2] ясно сказано, что "MODBUS uses a ‘big-Endian’ representation for addresses and data items", а вовсе не какой-то там "универсальный тип байтовый массив (string)". Универсальность тут не при чем. Дело в том, что если Вы взялись следовать какому либо стандарту, то его надо выполнять полностью, а не частично. В противном случае необходимо сменить название протокола, как, например, это сделала фирма OMRON в своих приводах.


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



Не только видел, но и работал с ним. В настоящий момент выполняется уже второй проект на его основе. Поэтому относительно Modbus vs ПЛК "Овен" могу сказать следующее:
1-ый уровень Modbus - не выполнен (нет возможности поляризации на RS485 и соответствующей обязательной индикации в соответствии с [1]),
2-ой уровень выполнен в полном объеме,
7-ой уровень - выполнен частично (не реализованы в полном объеме команды чтения и записи множества регистров в соответствии с [2]).
Лично для меня (условно, поскольку я не один такой) протоколы Овен, DCON и имени Васи Пупкина интереса не представляют. В моих проектах они не используются, поскольку носят локальный характер и нестандартизованы в том смысле как это сделано с PROFIBUS, Modbus, DeviceNet, CanOpen и прочими FieldBus протоколами.

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



Ну и Вы тоже, извиняйте. Искренне желаю успехов на ниве ПЛК строения, поскольку у нас в стране Вы, пожалуй, единственные, кто это делает по-честному. Надеюсь на понимание в вопросах применения Modbus.
Если хотите, могу изложить свое видение этого вопроса применительно к Вашим ПЛК с вполне конкретными предложениями. На самом деле, привести все в норму не затратно и не сложно.

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

[Прохожий]

По порядку. В указаном Вами документе есть рекомендации по параметрам линий связи, к-е используются при обмене данными между мастером и слейвами 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.
В конечном счете, программист Вашего ПЛК - это промежуточное звено. Последняяя инстанция - наладчик КИПиА и технолог на производстве. И от них будет зависеть успех или неуспех Ваших ПЛК.

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

В указанных мной документах содержатся не рекомендации, а требования, что несколько меняет дело.
По п. 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 при той же стоимости. Можно было бы к одному сетевому контроллеру цеплять несколько "голов", находящихся в разных местах.

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

Вы правы по поводу универсализма - концепция Вставил-Забыл очень удобна. И мы к ней идем. И для наших устройств мы её уже начали поддерживать и будем целенаправлено работать в этом направлении.
Как с программной, так и в аппаратной стороны.
Однако:
1. Стандарта описания ModBus устройств нет и не предвидится, нам делать свой стандарт?
2. Кто будет описывать приборы?
3. Про DCON я вообще ничего не буду говорить, кто работал - знает, что это за протокол!

Однако не надо преувеличивать сложность подключения какого-нибудь частотника по ModBus к ПЛК.
Прочитать инструкцию и все легко подключается. Многократно проверено на подопытных юзерах :)

[Прохожий]

Вы правы по поводу универсализма - концепция Вставил-Забыл очень удобна. И мы к ней идем. И для наших устройств мы её уже начали поддерживать и будем целенаправлено работать в этом направлении.
Как с программной, так и в аппаратной стороны.

Это хорошо. Хотелось бы узнать Ваше мнение по поводу оборудования, подобного WagoSystems. Протокол Modbus сверх TCP/IP. Возможно ли такое в принципе?



Однако:
1. Стандарта описания ModBus устройств нет и не предвидится, нам делать свой стандарт?

Ни в коем случае. Лучше тогда и не начинать.
Если Вы считаете, что приведенных мною документов недостаточно, то почему бы Вашей конторе не стать членом MODBUS-IDA (http://www.modbus.org/) и не доработать непонятные места при тесном взаимодействии с этой организацией. Это, на мой взгляд, наиболее цивилизованный метод. А в случае с MODBUS и не дорогой.


2. Кто будет описывать приборы?

В каком смысле описывать? Разъясните, если можно...


3. Про DCON я вообще ничего не буду говорить, кто работал - знает, что это за протокол!

Этот протокол не нужен. Он частный и носит локальный характер. Как, впрочем, и Owen, не обижайтесь, потому как это правда.


Однако не надо преувеличивать сложность подключения какого-нибудь частотника по ModBus к ПЛК.
Прочитать инструкцию и все легко подключается. Многократно проверено на подопытных юзерах :)

Понятно. Но после SIEMENS или OMRON Ваш способ общения по Modbus вызывает по крайней мере недоумение. Он как бы вне общепринятой концепции. Требует напряжения мозга, там, где это недопустимо.
Поймите правильно, вместо того, чтобы послать наладчика для диагностики той или иной неисправности, мне придется идти самому. А это нехорошо.
Что касается "прочитать инструкцию", то в нашем случае это не всегда возможно. У нас на производстве, этих инструкций - целая библиотека. Время, отводимое на восстановление оборудования, стремится к 0. В большинстве случаев персонал работает исходя из неких общих интуитивно понятных правил, которые определяются, увы, пока не Вами и даже не фирмой 3S, а сами знаете кем. Поэтому, лично мое мнение, что скурпулезное выполнение стандартов, которые Вы используете и есть один из элементов, приближающий Вашу контору к тем, кто заказывает музыку. Пока же надо, на мой взгляд, тщательно исполнить свою партитуру. Импровизации на этом этапе недопустимы.

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

Это хорошо. Хотелось бы узнать Ваше мнение по поводу оборудования, подобного WagoSystems. Протокол Modbus сверх TCP/IP. Возможно ли такое в принципе?

Modbus TCP у нас реализован. А вот такой линейки модулей нет, пока.


В каком смысле описывать? Разъясните, если можно...




Modbus TCP у нас реализован. А вот такой линейки модулей нет, пока.

Как в ProfiBus - файл описания устройства, к-й сообщает контроллеру/среде разработки всю необх информацию об устройстве

[Прохожий]

Modbus TCP у нас реализован. А вот такой линейки модулей нет, пока.

По моему скромному мнению, надо срочно делать.


Как в ProfiBus - файл описания устройства, к-й сообщает контроллеру/среде разработки всю необх информацию об устройстве
Дык, по жизни это делал производитель модулей. К примеру, если делаете Вы, то Вы и описываете, а если этим занимаюсь я, тогда это моя обязанность.
Не уверен полностью, но мо-моему, в MODBUS-IDA, что-то такое было.

[Generator]

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

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

По 6 пункту - WAGO ставило именно такое условие - аппаратная несовместимость. И конструктив, ИМХО, хороший, но очень дорогой.

[Nekit]

Fastwel оставил о себе неприятные впечатления. Несмотря на довольно таки обильную документацию (на русском языке), идущую на диске с софтом. Довольно путанное объяснение как сконфигурить Модбас на нужный порт (у меня был с 485 модель 702 вроде). В итоге я загнал контроллер в ошибку ;) которая описана в документации, но как из нее выйти непонятно. А жаль, идея хорошая.
Из подобного год назад анонсировалось вот это:
http://www.reallab.ru/PLCs.htm
но судьба девайса мне неизвестна.