ModBus Slave

[Klik]

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

[Kirill]

1. В ПЛК и модулях расширения не вводилось разделение на входные и внутренние регистры. Ибо этого и не нужно.
Возможно, это не совсем совпадает с описанием протокола, зато значительно упрощает жизнь и, главное, не ничему не мешает. Так ведь?

2. Речь все-таки идет о контроллере для небольших задач (несколько сотен сигналов). Именно под них и разрабатывался ПЛК. Системы управления заводами - на такое мы не замахивались. Поэтому нет ничего удивительного, что возможности ПЛК ограничены.

3.С помощью библиотеки syslibfile

[Klik]

1. Основная цель разделения это хранение данных предназначенных только для просмотра в одной области памяти и для чтения и просмотра в другой области памяти. Каким образом на данный момент реализовать защиту данных от записи?
2. Да мы на управление заводом тоже не замахиваемся. Занимаемся автоматизацией оборудования для нефтянки, в конкретной ситуации автоматизация замерной установки. У нас есть уже готовые алгоритмы и архитектура программы, которая уже реализована на нескольких контроллерах, сейчас идет перенос на ПЛК-100.

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

1. В стандарте нет жесткого требования на разделение областей и это происходит только по желанию производителя.
2. Объем памяти не безграничен, к сожалению.
Сдвиг на текущий момент нельзя, но если будут желающие - реализуем.
4. Естественно, EasyWorkPLC работает с ПЛК (конкретным экземпляром), а не со средой разработки.

[Radix]

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 с минимальными затратами памяти, реализовать где нужно защиту от записи и энергонезависимость.

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

Энергонезависимость и так реализована.
Задачи имитации других приборов по сети ModBus не ставилась в принципе. Вы хотите заменить ПЛК другого производителя?

А что вам мешает сейчас иметь доступ по указателю и трактовать набор регистров как массив?

[Radix]

Энергонезависимость и так реализована.

Речь идет о том, чтобы её отключать там, где она не нужна.

Задачи имитации других приборов по сети ModBus не ставилась в принципе. Вы хотите заменить ПЛК другого производителя?

При разработке типовых станций управления(СУ) важно сохранять преемственность ранее разработанных карт Modbus, иначе потребителю придется писать\заказывать на стороне драйвера поддержки, что затратно по срокам и средствам, не говоря уже об вынужденном участии потребителя в процессе тестирования драйверов. Часто именно этот аспект влияет на заказ оборудования с той или иной СУ - берут тот комплект, для которого уже есть драйвер, просто чтобы не было проблем. Так что если не хотите, чтобы мы переводили уже имеющиеся СУ на ОВЕН - игнорируйте наши пожелания. Мы выпускаем около 400 СУ в год, в основном в них стоят SCADAPack32 и RTU188MX.

А что вам мешает сейчас иметь доступ по указателю и трактовать набор регистров как массив?

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

[Radix]

И кстати... было странно видеть в Modbus Slave другую идеологию, нежели в Master. Если бы каждый подэлемент мог настраиваться на начальный адрес, то многих вопросов бы не было. Я понимаю сложности реализации Slave с разрывами в пространстве регистров, т.к. не раз реализовывал такое на других контроллерах, и в таких случаях применял идею группы регистров с заданным стартовым адресом и длиной, а подэлементы характеризовались только смещением внутри группы, тогда они могут находится в группе где угодно, а не подряд и без разрывов. Все регистры группы, не используемые подэлементами, при этом фактически по Modbus работают, к ним просто нет доступа через имена.

[Radix]

Ещё один вопрос: имеет ли смысл вставка button в Modbus Slave? и какой, если это возможно? При попытке вставить проект потом не работает... Надеялся, что это даст возможность запускать\останавливать работу экземпляра Modbus Slave, но видимо ошибся.

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

Идеология - каждый модуль в конфигурации CoDeSys - 80 байт в программе, канал - 60, параметр от 40 до 80. Вот и считайте. Можно было бы дать полную свободу. Но память ПЛК не резиновая, если Вам необходима действительно серьезная система для мастера или слейва - то делать её через конфигурацию нельзя, надо делать в самом коде программы.
Мастера и slave в конфигурации - для простых проектов до 100 переменных. Никто и не предполагал, что кто-либо будет тратить часы и дни для именования переменных в гигантских конфигурациях.
Когда мне приходят проекты с 500 опрашиваемыми переменными в каждом мастере - я в шоке, сколько дней человек это настраивал и отлаживал. И как проверял правильность?
Гораздо проще тогда самому написать код мастера или slave и получить полный контроль, столь любимые именованные массивы и пр.
Благо и библиотека мастера есть, а код для slave вообще примитивен.