Почему бы Овену не сделать переменные 64 или 128 байт в модуле slave?

[Загнетов]

Почему бы Овену не сделать переменные 64 или 128 байт в модуле slave?

Хорошо ли в Овеновском модуле modbus slave заполнять балласт с начального адреса 4-байтными noname-переменными (начальная имеет имя, а остальные без него) вместо 2-байтных ?

или могут быть неучтенные нюансы? пока кроме пересчета количества других подвохов не вижу.

кто как поступает?

[Валенок]

C 4bytes - хорошо. Подвохов кроме L и M - нет.

[Загнетов]

C 4bytes - хорошо. Подвохов кроме L и M - нет.

какие подвохи ожидаются в L и M ?

[Валенок]

какие подвохи ожидаются в L и M ?

Ну так в РЭ вроде в самом начале описано про ограничения.
Перегрузить последовательный порт - нереально. Просто опросы будут реже.
И что такое битный датчик ?

[Загнетов]

Ну так в РЭ вроде в самом начале описано про ограничения.
Перегрузить последовательный порт - нереально. Просто опросы будут реже.
И что такое битный датчик ?

битный, дискретный, булевый, контакт на 2 состояния

[Загнетов]

ключ, самое распространенное название, забыли написать

ЗЫ Вам говорилось о 100-150 сигналах, а не битах, а это могут быть и регистры и двойные слова типа флоат. У меня обмен по штатному слейву в плк делают в среднем 32 регистра и проблем не наблюдается, подсчитайте сколько это бит

в текущем проекте всего 5 float, остальные дискретные
что насчет 64 или 128-байтовой переменной?

[Николаев Андрей]

Логика такая (примерно )
Если пользователь вполне в состоянии разбирать данные в 128 байтах - для него сделаны библиотеки SysLibCom, UNM, ModBus...
Конфигурация для специалистов, не имеющих глубоких знаний в программировании. Поставил 2 байта - записал или опросил. Все.

[Загнетов]

Логика такая (примерно )
Если пользователь вполне в состоянии разбирать данные в 128 байтах - для него сделаны библиотеки SysLibCom, UNM, ModBus...
Конфигурация для специалистов, не имеющих глубоких знаний в программировании. Поставил 2 байта - записал или опросил. Все.

Андрей, это ответ по существу вопроса?

Придерживаюсь рекомендаций о том, что ПЛК -100,150 рассчитаны на обмен до 100-150 битных датчиков.
Перегружать контроллер нет намерения.
Реально требуется опросить около 90 битных датчиков, но из-за структурирования данных (причины описал здесь http://www.owen.ru/forum/showpost.ph...8&postcount=15) объем обмена вырос до 400 байт.
Именовать в конфигурации ресурсов каждую переменную смысла нет, так излишне трудоёмко, поэтому технологически проще записать в область ввода-вывода дамп образа структуры данных.
Следовательно, в этой области нужны переменные в качестве балласта. Балласт легче заполнить переменными большой длины, не так ли?

Ваше мнение ?

[Николаев Андрей]

To Загнетов:
Давайте еще раз разберемся.
Вам необходимо опрашивать 100-150 битных датчиков? При нормальном формировании области памяти опрашиваемого устройства\устройств это занимает от 4 до 5 регистров Мы в модулях ОБЯЗАТЕЛЬНО сделали маски входов и маски выходов, где одной посылкой значение 32 входов считывается....

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

Просто до конца не понял.

А вот официальный ответ: пока что добавлять в конфигурацию модули 64 или 128 байт не планировали. Принципиально это возможно. Но задача такая становилась 1-2 раза. При более близком рассмотрении люди переходили на построение обмена через SysLibCom.
И еще раз. Если Вы умеете формировать дамп памяти и работать с ним - рекомендую пользоваться библиотеками. В них Вы можете формировать какие угодно дампы по размеру. Плюс совершенно не используется память, ограниченная типом лицензии L или М. Согласитесь, это здорово.
Конфигурация создается для людей, которые ничего не хотят знать про дампы и указатели.
Скажу крамольную мысль - не смотря на все годы, проведенные с CoDeSys я не умею пользоваться указателями, и всем начинающим на курсах ЗАПРЕЩАЛ с ними работать (рекомендовал не работать хотя бы первые 6-9 месяцев). Ибо это путь к нестабильной работе контроллера и сложному поиску ошибок. И пользуются такими инструментами в основном спецы, перешедшие с ПО верхнего уровня на ПЛК.

Открыт к обсуждению.

[Загнетов]

To Загнетов:
Давайте еще раз разберемся.
Вам необходимо опрашивать 100-150 битных датчиков? При нормальном формировании области памяти опрашиваемого устройства\устройств это занимает от 4 до 5 регистров Мы в модулях ОБЯЗАТЕЛЬНО сделали маски входов и маски выходов, где одной посылкой значение 32 входов считывается....

в этой цитате модуль = программный модуль в конфигурации ввода-вывода ПЛК или slave-устройство ввода-вывода ?


Объект технически не сложный, но ответственность велика и я решил формализовать обращения к элементам структур, об этом далее.

в посте http://www.owen.ru/forum/showpost.ph...8&postcount=15 Валенок описал интересный формальный способ, использовать на манер препроцессорных директив символьные метки для обращения к элементам структур. При таком подходе получается компактно, но
возможны скрытые ошибки, о которых я написал по этой ссылке.

Если структурировать все данные явно, то можно возложить проверки такого рода на компилятор. Объем обмена значительно увеличится (увеличение около 10 раз), но для Ethernet это не критично.
Именовать переменные в области ввода вывода и создавать ошибки нет желания, поэтому там будет noname-балласт.

Заказчик попросил еще и ручную симуляцию статусов устройств с панели и это еще немного увеличило область обмена.
Данные структурируются таким способом: Агрегат.Механизм_или_датчик.Статусы_и_команды
Чтобы не иметь проблем с выравниванием (вопрос о нём в конце поста), минимальный элемент в структуре взят 16 битовым.

В результате одна задвижка, для работы с которой было бы достаточно 6 бит (закрыта, открыта, закрыть, открыть, симулировать статус открытия, закрытия) в при обмене в сегменте сети ПЛК-панель (Ethernet) превратилась в 48 бит

При обмене в сегменте ПЛК-slave (Овен-модули ввода и вывода, RS-485 mbus RTU) это будут всего 3 бита открыть/закрыть, закрыта, открыта.

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

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

А вот официальный ответ: пока что добавлять в конфигурацию модули 64 или 128 байт не планировали.

выход - формировать балласт вручную из 4-байтных. (capzap справедливо "прищучил" меня - в "owen_plc_config..." модули называются каналами)

Принципиально это возможно. Но задача такая становилась 1-2 раза. При более близком рассмотрении люди переходили на построение обмена через SysLibCom.

до SysLibCom еще не дошел, я в начале пути.
на форуме пишут про проблемы с этой библиотекой, а проблемы заказчику не нужны.

И еще раз. Если Вы умеете формировать дамп памяти и работать с ним - рекомендую пользоваться библиотеками.

такое умение есть у "писателя" на С и asm.

В них Вы можете формировать какие угодно дампы по размеру. Плюс совершенно не используется память, ограниченная типом лицензии L или М. Согласитесь, это здорово.
Конфигурация создается для людей, которые ничего не хотят знать про дампы и указатели.

В этот раз наверное проще скопировать дамп памяти в область обмена и пользоваться модулем mb TCP slave. Памяти не жалко.

Скажу крамольную мысль - не смотря на все годы, проведенные с CoDeSys я не умею пользоваться указателями, и всем начинающим на курсах ЗАПРЕЩАЛ с ними работать (рекомендовал не работать хотя бы первые 6-9 месяцев). Ибо это путь к нестабильной работе контроллера и сложному поиску ошибок. И пользуются такими инструментами в основном спецы, перешедшие с ПО верхнего уровня на ПЛК.

Напишите что-нибудь на C и умение придет к Вам.
Косвенная адресация всегда опаснее, чем прямая, так как компилятор не может формально проверить ее. Очень даже правильно советуете. Можно по ошибке с указателями уйти в чужую область памяти и "натворить дел". Именно из-за этого я не стал применять способ описанный Валенком. Возможные ошибки не очевидны, и трудно выявляемы.
Кстати, можно ли из-за неправильного обращения по указателю нарушить оперативную память кода ПЛК Овен или она безопасно отделена?

Открыт к обсуждению.

Спасибо, может быть заменить в проекте все ПЛК 100 на 110-ые из-за съемных колодок и выигрыша производительности (или в 110 тот же ARM9?).
От этих контроллеров потребуется в основном хороший быстрый сетевой обмен. Логическая программа не сложная.

Вопросы:

1. Есть мнение (capzap) , что переписывая пословно по указателям около 400 байт в область обмена, возможно не вписаться в длительностью цикла ПЛК. Опасение реальное?
2. Может ли компилятор, редактор связей или динамический диспетчер памяти разместить элементы структуры не подряд вплотную друг за другом, а кусками в разных местах?
3. Тот же вопрос для массива 16 битных, есть ли гарантия на отсутствие "щелей"?
4. В структуре осуществляется выравнивание по адресам, подобное области ввода-вывода?