Не зря в модуле string есть параметр "число передаваемых байтов"! Вот сколько там байтов записано, столько и будет передано, хоть они там все нули... А string - потому, что канал нельзя объявить байтовым массивом. Единственное ограничение при передаче нуля - нельзя пользоваться функциями обработки строк, а надо брать указатель и побайтово читать/записывать в канал модуля StringСообщение от Milchuk
Спасибо, я догадался.
А меня интересует - в чем трудность реализации команд 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 - протокол передачи данных, а не шина. И у него не может быть никакой поляризации!
О какой поляризации вообще идет речь? В качестве физ. интерфейса передачи используется 485/232/TCP. Про какой интерфейс вы говорите?
P.S. А контроллер то видели?
P.P.S. Извините за вольный стиль, предыдущий пост настроил
Сразу оговорюсь, что критические замечания, высказываемые мной может быть не в очень корректной форме (заранее извиняюсь за это), направлены исключительно на исправление досадных недочетов в общем-то достаточно пристойном девайсе, а не на уязвление самолюбия его создателей.
В протоколе Modbus речи о плавающих числах и строках не идет. А вот о регистрах и об их передаче в нужном количестве идет. На каком основании Вы навязываете мне, как потребителю Вашего продукта, свою личную картину видения мира? Тем более, что она идет вразрез со стандартом, который Вы решили применить в своем устройстве.
Начнем с самого начала. Протокол Modbus, как впрочем и все остальные полевые протоколы, имеет несколько уровней (слоев) согласно соглашению OSI. Откроем документ MODBUS over serial line specification and implementation guide V1.02 [1] на стр. 4 и внимательно ознакомимся с разделом 1.1. Из него мы узнаем, что документ MODBUS Application Protocol Specification V1.1b [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.По поводу 2-й части:
ModBus - протокол передачи данных, а не шина. И у него не может быть никакой поляризации!
О какой поляризации вообще идет речь? В качестве физ. интерфейса передачи используется 485/232/TCP. Про какой интерфейс вы говорите?
В свете вышеизложенного Ваша фраза
выглядит крайне неубедительно. Потому как в разделе 4.2 документа [2] ясно сказано, что "MODBUS uses a ‘big-Endian’ representation for addresses and data items", а вовсе не какой-то там "универсальный тип байтовый массив (string)". Универсальность тут не при чем. Дело в том, что если Вы взялись следовать какому либо стандарту, то его надо выполнять полностью, а не частично. В противном случае необходимо сменить название протокола, как, например, это сделала фирма OMRON в своих приводах.Просто фирма 3S Software когда делала свою среду разработки, вот вся такая нехорошая
А предусмотрела универсальный тип байтовый массив (string), к-й можно использовать и с ModBus и с Овен и с DCON, и с "фирменным" протоколом от Васи Пупкина. (И зачем такая универсальность, вот раньше помню...включил рубильник - работает, выключил - не работает, красота...).
Но за универсальность надо немножко доплатить, а именно обратиться к этой структуре по указателю, что просто и не вызывает какого-либо серьезного умственного напряжения.
Не только видел, но и работал с ним. В настоящий момент выполняется уже второй проект на его основе. Поэтому относительно Modbus vs ПЛК "Овен" могу сказать следующее:
1-ый уровень Modbus - не выполнен (нет возможности поляризации на RS485 и соответствующей обязательной индикации в соответствии с [1]),
2-ой уровень выполнен в полном объеме,
7-ой уровень - выполнен частично (не реализованы в полном объеме команды чтения и записи множества регистров в соответствии с [2]).
Лично для меня (условно, поскольку я не один такой) протоколы Овен, DCON и имени Васи Пупкина интереса не представляют. В моих проектах они не используются, поскольку носят локальный характер и нестандартизованы в том смысле как это сделано с PROFIBUS, Modbus, DeviceNet, CanOpen и прочими FieldBus протоколами.
Ну и Вы тоже, извиняйте. Искренне желаю успехов на ниве ПЛК строения, поскольку у нас в стране Вы, пожалуй, единственные, кто это делает по-честному. Надеюсь на понимание в вопросах применения Modbus.
Если хотите, могу изложить свое видение этого вопроса применительно к Вашим ПЛК с вполне конкретными предложениями. На самом деле, привести все в норму не затратно и не сложно.
И меня тоже извините, не удержался.
Несомненно, характеристики металла для изготовления молотка будут приведены в ГОСТе на молоток, но это не значит что технология плавки есть неотъемлемая часть молотка.
По порядку. В указаном Вами документе есть рекомендации по параметрам линий связи, к-е используются при обмене данными между мастером и слейвами ModBus. В частности и требование поляризации.
Но почему Вы решили, что 1) это требование как-то отностися к ModBus (Оно относится к 485) и 2) Мы его не выполняем.
А я разве говорил о ModBus? Я говорил о том, как программист обращается к переменным в модулях ModBus master и ModBus slave. Это особенность среды разработки и компилятора CoDeSys. Или Вы хотите, чтобы для работы с ModBus были специальные "сертифицированные" переменные и команды специально для ModBus?
1-й уровень сделан полностью, т.к. иначе вы бы не смогли работать с устройствами ModBus. У Вас не работает связь по 485?
7-й уровень также реализован полностью, можно посылать и принимать неск. регистров за раз. Где не работает?
С удовольствием Вас выслушаю и постараюсь помочь! Сотрудничество приветствуется.
В указанных мной документах содержатся не рекомендации, а требования, что несколько меняет дело.
По п. 1. Если внимательно прочесть [1], то там четко указано, что если Вы применяете RS 485 в качестве 1-го уровня Modbus, то он обязан соответствовать дополнительным требованиям, изложенным там же. В частности - это поляризация и индикация и не только это.
По п. 2. Если Вы выполняете эти требования, то это должно быть оговорено в соответствующем месте в документации. Это опять же следует из [1].
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.
В конечном счете, программист Вашего ПЛК - это промежуточное звено. Последняяя инстанция - наладчик КИПиА и технолог на производстве. И от них будет зависеть успех или неуспех Ваших ПЛК.
Да, документации это не отражено.
Так вот, в стандарте не описано и даже нет никакого упоминания о том, как реализуется этот протокол в устройстве. Вся суть стандартных протоколов в том, что стандартизуется внешняя часть, т.е. обмен МЕЖДУ приборами, а не внутренняя реализация, к-я остаётся на совести производителя и может быть ЛЮБОЙ.
Это невозможно технически, т.к. среда разработки CoDeSys не позволяет добавлять и удалять каналы ввода/вывода, а позволяет лишь добавлять/удалять модули. Т.е. В если сделать как Вы предлагаете, то необходимо создать модули 1 регистр, 2 регистра, 3 регистра и т.д. до 127 регистров. Что лишь усложнит и сделает более запутанной работу с протоколом.
Почему же? Протокол ModBus позволяет реализовывать свои собственные команды в специально зарезервированной номерной емкости, что мы и сделали по заказу одного из клиентов.
Т.е. даже если мне надо опросить 1 регистр, я вынужден вставлять модуль регистра с 127 регистрами? Или см. п.1 Массивы каналов в CoDeSys невозможны
мы делаем устройство, к-е будет работать с реальными приборами, а не точно соотв. стандарту, т.к. в реальной жизни производители делают все что им пожелается и приходится подстраиваться, иначе такое "соответствующее стандарту" устройство никому не нужно!
К примеру, ответьте мне на такой вопрос, как передать число с плавающей точкой по стандарту ModBus?
Вот только при попытке подключить к WAGO не их устройство Вы огребете огромные проблемы с его подключением. И все из-за того, что такие "красявости" как в Beckhoff и WAGO возможны только при использовании оборудования, полностью соответствующего стандарту, а зачастую только ограниченного круга моделей и производителей, о которых заложена на заводе информация в ПЛК. И за "стандартизацию" потребитель должен переплачивать в 3-10 раз.
В России такие вещи недопустимы (если Вы не из Газпрома). Все хотят подешевле, универсальнее, гибче. Что мы и попытались сделать.
Ваши права
