Почему бы Овену не сделать переменные 64 или 128 байт в модуле slave?
Хорошо ли в Овеновском модуле modbus slave заполнять балласт с начального адреса 4-байтными noname-переменными (начальная имеет имя, а остальные без него) вместо 2-байтных ?
или могут быть неучтенные нюансы? пока кроме пересчета количества других подвохов не вижу.
кто как поступает?
C 4bytes - хорошо. Подвохов кроме L и M - нет.
Логика такая (примерно :))
Если пользователь вполне в состоянии разбирать данные в 128 байтах - для него сделаны библиотеки SysLibCom, UNM, ModBus...
Конфигурация для специалистов, не имеющих глубоких знаний в программировании. Поставил 2 байта - записал или опросил. Все.
какие подвохи ожидаются в L и M ?Цитата:
Сообщение от Валенок
Андрей, это ответ по существу вопроса?Цитата:
Сообщение от Николаев Андрей
Придерживаюсь рекомендаций о том, что ПЛК -100,150 рассчитаны на обмен до 100-150 битных датчиков.
Перегружать контроллер нет намерения.
Реально требуется опросить около 90 битных датчиков, но из-за структурирования данных (причины описал здесь http://www.owen.ru/forum/showpost.ph...8&postcount=15) объем обмена вырос до 400 байт.
Именовать в конфигурации ресурсов каждую переменную смысла нет, так излишне трудоёмко, поэтому технологически проще записать в область ввода-вывода дамп образа структуры данных.
Следовательно, в этой области нужны переменные в качестве балласта. Балласт легче заполнить переменными большой длины, не так ли?
Ваше мнение ?
Ну так в РЭ вроде в самом начале описано про ограничения.Цитата:
Сообщение от Загнетов
Перегрузить последовательный порт - нереально. Просто опросы будут реже.:)
И что такое битный датчик ?
битный, дискретный, булевый, контакт на 2 состоянияЦитата:
Сообщение от Валенок
в текущем проекте всего 5 float, остальные дискретныеЦитата:
Сообщение от capzap
что насчет 64 или 128-байтовой переменной?
To Загнетов:
Давайте еще раз разберемся.
Вам необходимо опрашивать 100-150 битных датчиков? При нормальном формировании области памяти опрашиваемого устройства\устройств это занимает от 4 до 5 регистров :) Мы в модулях ОБЯЗАТЕЛЬНО сделали маски входов и маски выходов, где одной посылкой значение 32 входов считывается....
Или Вам необходимо формировать в ПЛК карту памяти, причем опрашивающее устройство не умеет читать произвольные регистры, а ему нужно выравнивать, добавляя заплатки?
Просто до конца не понял.
А вот официальный ответ: пока что добавлять в конфигурацию модули 64 или 128 байт не планировали. Принципиально это возможно. Но задача такая становилась 1-2 раза. При более близком рассмотрении люди переходили на построение обмена через SysLibCom.
И еще раз. Если Вы умеете формировать дамп памяти и работать с ним - рекомендую пользоваться библиотеками. В них Вы можете формировать какие угодно дампы по размеру. Плюс совершенно не используется память, ограниченная типом лицензии L или М. Согласитесь, это здорово.
Конфигурация создается для людей, которые ничего не хотят знать про дампы и указатели.
Скажу крамольную мысль - не смотря на все годы, проведенные с CoDeSys я не умею пользоваться указателями, и всем начинающим на курсах ЗАПРЕЩАЛ с ними работать (рекомендовал не работать хотя бы первые 6-9 месяцев). Ибо это путь к нестабильной работе контроллера и сложному поиску ошибок. И пользуются такими инструментами в основном спецы, перешедшие с ПО верхнего уровня на ПЛК.
Открыт к обсуждению.
В штатном мастере вроде есть string in/out module. И вроде бы они могут менять размер запросов.
в этой цитате модуль = программный модуль в конфигурации ввода-вывода ПЛК или slave-устройство ввода-вывода ?Цитата:
Сообщение от Николаев Андрей
Объект технически не сложный, но ответственность велика и я решил формализовать обращения к элементам структур, об этом далее.
в посте http://www.owen.ru/forum/showpost.ph...8&postcount=15 Валенок описал интересный формальный способ, использовать на манер препроцессорных директив символьные метки для обращения к элементам структур. При таком подходе получается компактно, но
возможны скрытые ошибки, о которых я написал по этой ссылке.
Если структурировать все данные явно, то можно возложить проверки такого рода на компилятор. Объем обмена значительно увеличится (увеличение около 10 раз), но для Ethernet это не критично.
Именовать переменные в области ввода вывода и создавать ошибки нет желания, поэтому там будет noname-балласт.
Заказчик попросил еще и ручную симуляцию статусов устройств с панели и это еще немного увеличило область обмена.
Данные структурируются таким способом: Агрегат.Механизм_или_датчик.Статусы_и_команды
Чтобы не иметь проблем с выравниванием (вопрос о нём в конце поста), минимальный элемент в структуре взят 16 битовым.
В результате одна задвижка, для работы с которой было бы достаточно 6 бит (закрыта, открыта, закрыть, открыть, симулировать статус открытия, закрытия) в при обмене в сегменте сети ПЛК-панель (Ethernet) превратилась в 48 бит :D
При обмене в сегменте ПЛК-slave (Овен-модули ввода и вывода, RS-485 mbus RTU) это будут всего 3 бита открыть/закрыть, закрыта, открыта.
Конечно умеет, ПЛК Овен ситывает данные с модулей ввода вывода Овен.Цитата:
Сообщение от Николаев Андрей
Но ради удобства решил формировать в ПЛК карту памяти в виде структуры, складывать в нее состояния устройств, команды ПЛК, команды панели, уставки и др. В зависимости от режима работы некоторыми переменными работать при помощи масок. Так легче.
Очень похоже на ситуацию, когда "пассажир и его портфель" едут на грузовике, но это не затратно.
выход - формировать балласт вручную из 4-байтных. (capzap справедливо "прищучил" меня - в "owen_plc_config..." модули называются каналами)Цитата:
Сообщение от Николаев Андрей
до SysLibCom еще не дошел, я в начале пути.Цитата:
Сообщение от Николаев Андрей
на форуме пишут про проблемы с этой библиотекой, а проблемы заказчику не нужны.
такое умение есть у "писателя" на С и asm.Цитата:
Сообщение от Николаев Андрей
В этот раз наверное проще скопировать дамп памяти в область обмена и пользоваться модулем mb TCP slave. Памяти не жалко.Цитата:
Сообщение от Николаев Андрей
Напишите что-нибудь на C и умение придет к Вам.Цитата:
Сообщение от Николаев Андрей
Косвенная адресация всегда опаснее, чем прямая, так как компилятор не может формально проверить ее. Очень даже правильно советуете. Можно по ошибке с указателями уйти в чужую область памяти и "натворить дел". Именно из-за этого я не стал применять способ описанный Валенком. Возможные ошибки не очевидны, и трудно выявляемы.
Кстати, можно ли из-за неправильного обращения по указателю нарушить оперативную память кода ПЛК Овен или она безопасно отделена?
Спасибо, может быть заменить в проекте все ПЛК 100 на 110-ые из-за съемных колодок и выигрыша производительности (или в 110 тот же ARM9?).Цитата:
Сообщение от Николаев Андрей
От этих контроллеров потребуется в основном хороший быстрый сетевой обмен. Логическая программа не сложная.
Вопросы:
1. Есть мнение (capzap) , что переписывая пословно по указателям около 400 байт в область обмена, возможно не вписаться в длительностью цикла ПЛК. Опасение реальное?
2. Может ли компилятор, редактор связей или динамический диспетчер памяти разместить элементы структуры не подряд вплотную друг за другом, а кусками в разных местах?
3. Тот же вопрос для массива 16 битных, есть ли гарантия на отсутствие "щелей"?
4. В структуре осуществляется выравнивание по адресам, подобное области ввода-вывода?
Охох...
В кратце.
0. Модули - я имел в виду как раз модули МХ.
1. С библиотекой SysLibCom проблем у заказчика не может быть. Я подозреваю писали про сложности для программиста. К тому же есть библиотека UNM. Есть библиотека ModBus.
2. Мне по работе уже не нужно так плотно работать с программированием. Да и не сторонник я работы с сложными механизмами при программировании.
3. ПЛК110 аналогичен ПЛК100, за исключением входов\выходов.
4. При большом количестве обмена программа может не укладываться в отведенное время. По этому можно увеличить время цикла :)
Цитата:
Сообщение от capzap
про неклассический вариант "разыменование адреса структуры" я вроде уже писал.Цитата:
Сообщение от capzap
вы с Валенком на форуме дельные мысли пишите, и это интересно.Цитата:
Сообщение от capzap
Ну во-первых при большом кол-ве разных наборов битов можно делать перечисления и префиксы имен. Для каждого набора - разные префиксы связанные с владельцемЦитата:
формальный способ, использовать ..символьные метки для обращения к элементам структур.
И не надо чужие имена использовать в других местах даже если у одного и того же числа - несколько имен.
Ответ простой - не делайте их. Возможно 220 подать на DiЦитата:
но возможны скрытые ошибки..
На форум неоднократно приходят люди с предложениями - а давайте все будем носить каску дома - ведь мне один раз наголову упала люстра :
-вопросы синтаксиса - это в Codesys а не сюда
-если вилкой можно выколоть глаз, это не значит что нельзя ей пользоваться.
Не умеете выявлять и исправлять ошибки с указателями - просто не используйте их. Кто заставляет :confused: ? Полно других инструментов.Цитата:
Можно по ошибке с указателями уйти в чужую область памяти и "натворить дел". Именно из-за этого я не стал применять способ
Неа-а. Проблемы при использовании этой библиотеки. А бодяга с 73 в соседних ветках - это проблема не библиотеки.Цитата:
до SysLibCom еще не дошел,..на форуме пишут про проблемы с этой библиотекой
Нет конечно :) А зачем так сложно - "пословно по указателям" ?Цитата:
Есть мнение что переписывая пословно по указателям около 400 байт в область обмена, возможно не вписаться в длительностью цикла ПЛК. Опасение реальное?
Любой перенос это время. Но даже если будите по 60К переносить туда-сюда - ватчдога не будет (если только не заставить), но могут быть другие проблемы
В очередной раз - все друг за другом но :Цитата:
Может ли компилятор, редактор связей или динамический диспетчер памяти разместить элементы структуры не подряд вплотную друг за другом, а кусками в разных местах?
Выравнивание рулит и всегда одинаково
Явное выделение, например RETAIN, это конечно другая область
Работа с кучей нигдене обязана выделять подряд и в плотную
Массив чего угодно - всегда друг за другом без щелей. Это признак набора данных организованого как "массив". Везде.Цитата:
3. Тот же вопрос для массива 16 битных, есть ли гарантия на отсутствие "щелей"?
Выравнивание везде одноЦитата:
4. В структуре осуществляется выравнивание по адресам, подобное области ввода-вывода?
Внутри структуры нет щелей ?
следовательно, чтобы избежать выравнивания внутри структуры, нужно сделать все её компоненты 4-байтовыми?Цитата:
Сообщение от Валенок
Суть от того, что объявили перечисляемым типом не меняется. Проверка все равно возлагается на нас, а не на компилятор.Цитата:
Сообщение от Валенок
Цитата:
Сообщение от capzap
1. если в ПЛК100 структура набрана одинаковыми 16-бит или 32-бит элементами, выравнивания быть не должно
2. можно ли вместо видео непонятного качества выложить несекретную часть файла- проекта?
Цитата:
Сообщение от capzap
wind player прокручивает за долю секунды, а irfanview не имеет кнопки пауза :-(
Там ничего принципиального не было. Единственное, что не сразу рассмотрел, это был режим отладки :-)
Все равно спасибо за помощь.
Вы переживаете и тратите время, время - деньги, заплатите другому и он не будет парится над этим и проверка не будет возлагатся на Вас.Цитата:
Проверка все равно возлагается на нас, а не на компилятор.
Необязательно. Не нужно - а можно. Зачем избегать неизбежного, надо просто использовать это.Цитата:
следовательно, чтобы избежать выравнивания внутри структуры, нужно сделать все её компоненты 4-байтовыми?
Windows Media по случаю завис и удалось увидеть картинку :-)Цитата:
Сообщение от capzap
PS: удобная программа CoDeSys, позволяет запускать одновременно несколько копий, экономит мое время. EasyBuilder так не может или не желает.
спасибо, не надо.Цитата:
Сообщение от capzap
и у меня работает. лучше изучение основных принципов, чем сиюминутное "как именно сделать", хотя четкой границы нет и одно перетекает в другое.
пока удалось наступить почти на все грабли, оттого что некачественно изучил документацию, вот и возникают "детские" вопросы типа "индексного регистра в панели или канала в slave".
поэтому в выходные заново перечитаю и осмыслю документацию на кодесис и панель и большинство вопросов отпадут.
1) для Валенок: я посмотрел, выравнивание не всегда происходит по квартам. Если объявить структуру STRUCT1 из 16 битных, то смещение очередного компонента равно размеру предыдущего, то есть выравнивания и следовательно "щелей" внутри такой структуры нет.
2) если эта структура типа STRUCT1 является элементом другой структуры типа STRUCT3 (STA : STRUCT3), то в зависимости от размеров элементов, в STA могут появляться щели. Щели не инициализируются, поэтому до перезагрузки контроллера в них лежит оставшийся "мусор" (при перезаписи дампа структуры по указателю в область обмена "мусор" виден). Вреда для исполняемой программы от мусора нет, но при отладке менее удобно, мусор остается от тех же маркеров-заполнителей ( CLEAR_ARR) после изменения размера структуры.
на экранах - область обмена modbus (скриншот панели), начиная с 0 адреса, увеличение адр. сверху вниз по столбцам
________программа
Сформулирую по другому.
1.Порядок не меняется - к счастью нет никаких оптимизаций.
2.Элементы структуры выравниваются обычным (для КДС) порядком,т.е. есть разница :
dword, word, byte, byte
byte, byte, dword, word (Вот они щели. Причем две)
dword, byte, word, byte (И тут. Но другие)
3.Размер структуры всегда кратен 4.
да, во всем согласенЦитата:
Сообщение от Валенок
а внутри структуры однотипные (фактически именованный масив) не выравниваются, щели внутри структуры только между разнотипными.
хорошо бы автоматизировать составление таблиц длин и смещенийЦитата:
Сообщение от capzap
для последующей работы с панелью, можно анализировать при помощи заполнения маркерами или полиномами, а то при большом количестве переменных вручную ненадежно, да и изменение структуры может вести к переделке таблицы.
И в продолжение вчерашней темы о производительности - плк:
при копировании дампа структуры (более 300 байт) в память обмена ПЛК-100L, в цикл контроллера я добавил "на пробу" еще 100 таких перезаписываний. Справляется, обслуживает логику программы и еще два сегмента Modbus.