Просмотр полной версии : ModBus Slave
Накопилось несколько вопросов, которые опишу в одной теме, так часть из них отпадут в процессе ответов.
1. При тестирование реализации Modbus RTU (Slave) на ПЛК-100 использовались функции 3 и 4. Оказалось что при обращении по данным функция по одним и тем же адресам происходит считывание данных с одних и тех же ячеек, что не соответствует Modbus протоколу. Обращение идет к входным регистрам (3ХХХХ по функции 4) и внутренним регистрам (4ХХХХ по функции 3) которые должны располагаться в разных ячейках памяти.
2. Максимально возможное количество регистров используемых в Modbus (Slave) равно 2000. С чем это связано? Это ограничение жесткое? Как можно разместить большее количество регистров по одному и тому же адресу. А также возможна ли реализация Modbus (Slave) со сдвигом регистров на определенное количество.
3. Как можно получить доступ к энергонезависимой памяти для хранения переменных (примерно 10000 регистров). Retain переменные соот. не подходят так как ограничены 4кБ, что не достаточно.
4. При использовании EasyWorkPLC и изменении адреса устройства в программе отображается корректно и адрес устройства после записи в ПЛК изменяется, но при этом изменений в конфигураторе ПЛК (в программе) не происходит.
5. И еще хотелось бы задать вопрос по коммуникационному контроллеру ПЛК 304/308. Как скоро контроллер поступит в продажу? Какая среда программирования будет реализованна в данном контроллере? С чем связаны трудности в реализации данного проекта? По параметрам очень симпатичен и подходит под наши реализации. Поэтому хотелось бы ориентироваться на какие-то сроки.
1. В ПЛК и модулях расширения не вводилось разделение на входные и внутренние регистры. Ибо этого и не нужно.
Возможно, это не совсем совпадает с описанием протокола, зато значительно упрощает жизнь и, главное, не ничему не мешает. Так ведь?
2. Речь все-таки идет о контроллере для небольших задач (несколько сотен сигналов). Именно под них и разрабатывался ПЛК. Системы управления заводами - на такое мы не замахивались. Поэтому нет ничего удивительного, что возможности ПЛК ограничены.
3.С помощью библиотеки syslibfile
1. Основная цель разделения это хранение данных предназначенных только для просмотра в одной области памяти и для чтения и просмотра в другой области памяти. Каким образом на данный момент реализовать защиту данных от записи?
2. Да мы на управление заводом тоже не замахиваемся. Занимаемся автоматизацией оборудования для нефтянки, в конкретной ситуации автоматизация замерной установки. У нас есть уже готовые алгоритмы и архитектура программы, которая уже реализована на нескольких контроллерах, сейчас идет перенос на ПЛК-100.
Филоненко Владислав
22.05.2009, 12:49
1. В стандарте нет жесткого требования на разделение областей и это происходит только по желанию производителя.
2. Объем памяти не безграничен, к сожалению.
Сдвиг на текущий момент нельзя, но если будут желающие - реализуем.
4. Естественно, EasyWorkPLC работает с ПЛК (конкретным экземпляром), а не со средой разработки.
1. В ПЛК и модулях расширения не вводилось разделение на входные и внутренние регистры. Ибо этого и не нужно.
Возможно, это не совсем совпадает с описанием протокола, зато значительно упрощает жизнь и, главное, не ничему не мешает. Так ведь?
Тем не менее существуют реализации с разделением. Соответственно есть устройства, использующие InputRegs и HoldingRegs в обмене, причем при совмещении по вашей схеме возможен конфликт наложения разных по функциям данных в одно пространство. Если встает задача сохранить преемственность карт адресов Modbus устройства, то Ваша реализация накладывает непреодолимое ограничение - используемые адреса пространств InputRegs и HoldingRegs не должны пересекаться. Раздельная реализация не имела бы таких недостатков.
Предлагаю следующую схему:
1) В Modbus Slave явно указывается
- возможность отображения в coils (нет\с адреса XXXX);
- возможность отображения в inputs (нет\с адреса XXXX);
- возможность отображения в holding regs(нет\с адреса XXXX);
- возможность отображения в input regs (нет\с адреса XXXX);
- энергонезависимость(некоторые данные не нуждаются в этом);
2) В Modbus Slave можно вставлять Modbus Slave с своими настройками, что позволит одни и те же данные публиковать в других адресах и пространствах без дублирования самих данных;
3) При добавлении подэлементов можно указывать префикс повторения, чтобы делать массивы, доступ из ST можно реализовать через указатель на первый подэлемент;
реализация позволит создавать любую произвольную карту адресов в пределах разрешенного диапазона стандарта Modbus с минимальными затратами памяти, реализовать где нужно защиту от записи и энергонезависимость.
Филоненко Владислав
22.05.2009, 14:49
Энергонезависимость и так реализована.
Задачи имитации других приборов по сети ModBus не ставилась в принципе. Вы хотите заменить ПЛК другого производителя?
А что вам мешает сейчас иметь доступ по указателю и трактовать набор регистров как массив?
Энергонезависимость и так реализована.
Речь идет о том, чтобы её отключать там, где она не нужна.
Задачи имитации других приборов по сети ModBus не ставилась в принципе. Вы хотите заменить ПЛК другого производителя?
При разработке типовых станций управления(СУ) важно сохранять преемственность ранее разработанных карт Modbus, иначе потребителю придется писать\заказывать на стороне драйвера поддержки, что затратно по срокам и средствам, не говоря уже об вынужденном участии потребителя в процессе тестирования драйверов. Часто именно этот аспект влияет на заказ оборудования с той или иной СУ - берут тот комплект, для которого уже есть драйвер, просто чтобы не было проблем. Так что если не хотите, чтобы мы переводили уже имеющиеся СУ на ОВЕН - игнорируйте наши пожелания. Мы выпускаем около 400 СУ в год, в основном в них стоят SCADAPack32 и RTU188MX.
А что вам мешает сейчас иметь доступ по указателю и трактовать набор регистров как массив?
Ничего не мешает, просто достает вколачивать тысячи подэлементов, которые не будут иметь имен и явных обращений из ST... Ведь вся работа с ними будет через указатели (одно из последствий выравнивания полей, не дающее возможность создавать компактные структуры, что важно для радиоканалов - там короткие пакеты, малые скорости обмена и т.п.).
И кстати... было странно видеть в Modbus Slave другую идеологию, нежели в Master. Если бы каждый подэлемент мог настраиваться на начальный адрес, то многих вопросов бы не было. Я понимаю сложности реализации Slave с разрывами в пространстве регистров, т.к. не раз реализовывал такое на других контроллерах, и в таких случаях применял идею группы регистров с заданным стартовым адресом и длиной, а подэлементы характеризовались только смещением внутри группы, тогда они могут находится в группе где угодно, а не подряд и без разрывов. Все регистры группы, не используемые подэлементами, при этом фактически по Modbus работают, к ним просто нет доступа через имена.
Ещё один вопрос: имеет ли смысл вставка button в Modbus Slave? и какой, если это возможно? При попытке вставить проект потом не работает... Надеялся, что это даст возможность запускать\останавливать работу экземпляра Modbus Slave, но видимо ошибся.
Филоненко Владислав
24.05.2009, 11:14
Идеология - каждый модуль в конфигурации CoDeSys - 80 байт в программе, канал - 60, параметр от 40 до 80. Вот и считайте. Можно было бы дать полную свободу. Но память ПЛК не резиновая, если Вам необходима действительно серьезная система для мастера или слейва - то делать её через конфигурацию нельзя, надо делать в самом коде программы.
Мастера и slave в конфигурации - для простых проектов до 100 переменных. Никто и не предполагал, что кто-либо будет тратить часы и дни для именования переменных в гигантских конфигурациях.
Когда мне приходят проекты с 500 опрашиваемыми переменными в каждом мастере - я в шоке, сколько дней человек это настраивал и отлаживал. И как проверял правильность?
Гораздо проще тогда самому написать код мастера или slave и получить полный контроль, столь любимые именованные массивы и пр.
Благо и библиотека мастера есть, а код для slave вообще примитивен.
Slave уже написали.. к нему энергонезависимость ещё прикрутить надо. К тому же не хотелось терять возможность выхода на Modbus\TCP. Сейчас изучаем возможности вашего Modbus Slave, может мы зря велосипед изобретаем. Но, похоже, не зря - ваш трехколесный...
Филоненко Владислав
25.05.2009, 08:04
если переменных до 16 кБайт - используйте retain и все. Если надо больше O_O, то файловую систему.
Четырёхколесный. Для начинающих.
Сергей71
26.05.2009, 09:17
Про настройку MasterSlave Radix
И кстати... было странно видеть в Modbus Slave другую идеологию, нежели в Master. Если бы каждый подэлемент мог настраиваться на начальный адрес, то многих вопросов бы не было. Я понимаю сложности реализации Slave с разрывами в пространстве регистров, т.к. не раз реализовывал такое на других контроллерах, и в таких случаях применял идею группы регистров с заданным стартовым адресом и длиной, а подэлементы характеризовались только смещением внутри группы, тогда они могут находится в группе где угодно, а не подряд и без разрывов. Все регистры группы, не используемые подэлементами, при этом фактически по Modbus работают, к ним просто нет доступа через имена.
23.05.2009 07:27
Написал правильно.
Мои рассуждения: 500 переменных в проекте - это данные для настройки и конфигурации системы которые по модбасу можно прочитать, изменить к тому-же они сохраняются (не надо дважды объявлять в Modbus + Ratain).
Не удобство только в одном, при разных типах, адреса нужно считать самому, а надо прописывать самому, как в Mastere.
PS у самого больше 200 переменных. Взял за правило до определенного адреса все Word, а дальше Dword и считать стало легче.
да... неплохо было бы видеть адреса переменных при просмотре содержимого Modbus Slave
плохо что нет разделения на хотябы input'ы и hold'ы. Необходимость сопряжения ПЛК с имеющимися устройствами думаю возникает у многих. придется писать слейв самому.время-время...
плохо что нет разделения на хотябы input'ы и hold'ы. Необходимость сопряжения ПЛК с имеющимися устройствами думаю возникает у многих. придется писать слейв самому.время-время...
Чего за страхи, импуты и холды работают с определенными функциями, какую зададите в конфигураторе по такой мастер и будет. Если же Вы плк хотите сделать слейвом, то какая Вам разница, какой тип памяти запрашивает другое устройство
мастер да, но мне надо плк сделать слейвом и подогнать конфигурацию под определенные запросы другого устройства. А оно читает и холды и инпуты. Из вышенаписанного в этой теме я понял, что в ПЛК при модбас слейве нет разделения на холды и инпуты и какой бы функцией ни происходил запрос, ответ будет один и тот же.
Вопрос: в аналоге холд Х и инпут Х (Х один и тотже адрес) - это разные вещи?
мастер да, но мне надо плк сделать слейвом и подогнать конфигурацию под определенные запросы другого устройства. А оно читает и холды и инпуты. Из вышенаписанного в этой теме я понял, что в ПЛК при модбас слейве нет разделения на холды и инпуты и какой бы функцией ни происходил запрос, ответ будет один и тот же.
теперь понял, ну это тоже как бы просто, делите общую область в плк на регистры только для чтения и за ними уже с другими адресами холды, а мастер соответствующими функциями, только по разным адресам обращается к Вашему слейву.
Как бы встречаются слейвы, у которых строго "зашиты" определенные данные по определенным адресам, но чтоб слейвы под мастера "затачивать" это уже перебор, так что ни чего страшного не произойдет, если в овеновском плк Вы создаете слейв с общей памятью для различных типов памяти, на разделяемых устройствах будет тратится столько же памяти под общее количество регистров, разница только в нумерации адресов
теперь понял, ну это тоже как бы просто, делите общую область в плк на регистры только для чтения и за ними уже с другими адресами холды, а мастер соответствующими функциями, только по разным адресам обращается к Вашему слейву.
Как бы встречаются слейвы, у которых строго "зашиты" определенные данные по определенным адресам, но чтоб слейвы под мастера "затачивать" это уже перебор, так что ни чего страшного не произойдет, если в овеновском плк Вы создаете слейв с общей памятью для различных типов памяти, на разделяемых устройствах будет тратится столько же памяти под общее количество регистров, разница только в нумерации адресов
хороший вариант, спасибо, буду его держать в уме) Однако в данном моем случае он не подойдет, т.е. устройство-мастер уже есть и изменить в нем что-то невозможно. Поэтому нужно полностью подстроиться под него)
теперь понял, ну это тоже как бы просто, делите общую область в плк на регистры только для чтения и за ними уже с другими адресами холды, а мастер соответствующими функциями, только по разным адресам обращается к Вашему слейву.
Как бы встречаются слейвы, у которых строго "зашиты" определенные данные по определенным адресам, но чтоб слейвы под мастера "затачивать" это уже перебор, так что ни чего страшного не произойдет, если в овеновском плк Вы создаете слейв с общей памятью для различных типов памяти, на разделяемых устройствах будет тратится столько же памяти под общее количество регистров, разница только в нумерации адресов
Тем более, что
К каким данным (перемненым) можно доступиться с помощью MODBUS?
MBAP определяет вобщем 4-ре зоны (области) данных (переменных):
- Discrete Inputs (начиная с 10001), или область дискретных входов (входных битов)
- Coils (начиная с 00001), или область дискретных выходов (выходных битов)
- Input Registers (начиная с 30001), или область входных регистров (аналоговых входов)
- Holding Registers (начиная с 40001), или область выходных регистров (аналоговых выходов)
Таким образом, согласно MODBUS можно прочитать значение входных регистров и битов, прочитать или записать значение выходных регистров и битов. Следует отметить, что эти зоны памяти были доступны в ранних контроллерах MODICON, для которых и был разработан протокол. В этих контроллерах непривязаные к физическим выходам выходные перемнные (Coils и Holding Registers) можно было использовать как внутренние.
НО: в разных реализациях MODBUS, эти зоны могут интерпритироваться по разному, это не запрещается стандартами MODBUS.ORG
ПО-ЭТОМУ: для каждого конкретного устройства в документации определено отображение областей переменных MODBUS на его область данных.
Иными словами стандарт не определяет, к каким именно данным в конкретном устройстве вы будете доступаться, обращаясь к одной из зон памяти, это будут определять правила отображения, придуманные ... разработчиком устройства.
Это цитата из https://sites.google.com/site/fieldbusbook/seti/modbus/modbuseducation
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot