Просмотр полной версии : По организации ввода-вывода
Вопрос к опытным и самым опытным пользователям ПЛК 8=)
Я привык так, что все известные мне PLC делают цикл ввода, за тем цикл логических операций по сложной и разветвленной структуре программных блоков, потом делают цикл вывода. Исключения составляют те "тэги", которые могут безусловно и моментально устанавливать только отдельный вывод не ожидая окончания всего логического цикла, в которых встречаются специальные команды. Но это всё лирика. Работая в CoDeSys и понимая что мои выводы будут висеть где-то в сети на всяких там МВА и МВВ, я невольно потерял эту стройную систему мышления : чтение - действия - запись. И дело в том, что операции выполняются намного быстрее, чем может быть получен результат на выводах, а тем более удаленных. Могут быть случаи, когда какой-либо бит был установлен и снят раньше времени цикла записи, и по всей вероятности на выходе мы ничего не получим. Хотелось бы уяснить для себя, как всё это решается в ПЛК, потому что мне неудобно работать с данными ввода типа %IW. Такие данные я преобразую в BOOL, и далее везде в программе применяю этот тип, как говориться, налету без заморочек. В таком случае, от задержки по чтению в основном можно абстрагироваться, а вот при записи с обратным преобразованием в %QW, а то в %QD, уже так просто отделаться нельзя, надо учитывать время и цикличность вывода, понимать как это происходит и не хулиганить.
Конечно можно организовать свой собственный вывод на Modbus с контролем по факту записи, но почему-то очень этого не хочется делать.
Николаев Андрей
21.08.2011, 13:35
А можно теперь вопрос то сформулировать??? ;)
А можно теперь вопрос то сформулировать??? ;)
Вопрос прямо классический, как работает?
Но вероятно, чтобы избежать философкого ответа, надо конкретизироваться 8=)
Как данные %QW из программного блока после операции := попадают на выход того же МДВВ? Когда они там могут появиться? Что с ними произойдет, есть они ещё не ушли, а уже модифицировались? И можно ли об этом как-то узнать?
Николаев Андрей
21.08.2011, 15:46
Принцип работы контроллера классический, как Вы и описывали:
Опрашиваем область памяти входов (%I), выполняем программу, записываем данные в область памяти выходов (%Q).
А уже из области выходов контроллер, в свободное от основной задачи время, отсылает данные по сети. То есть при цикле 1мс данные в память записываются раз в 1 мс. При этом передача данных на устройства В\В идет последовательно, по своему алгоритму.
В принципе, как верно было сказано - Вы можете взять с диска библиотеку ModBus и сами определять какие данные в какой момент времени посылать, работая на прямую с портом.
:) очень обидно, когда на форуме пишут такие слова
Я привык так, что все известные мне PLC. Извините о каких контроллерах Вы говорите и чем Овен со своей линейкой так уж отличается от других. По аналогии, когда немцы говорят что с популярной серией ET-200M проблем не будет, за связь с
МВА и МВВ можно тоже не беспокоиться, если "руки не кривые" и нет иллюзий, что при последовательном соединении на скорости 9600 можно обогнать пакеты ТСР
Попытаюсь расшифровать вопрос...
На классических ПЛК, конфигурируя сетку хоть профибас коть девайсНет, чётко заешь время цикла обмена и как он происходит, есть и скоростные сетки привязанные к моменту обновления I/O, цикл связи почти сравним шиной I/O контроллера.
Когда связь через 485 описываешь сам, тоже знаешь возможное время реакции выхода после его изменения в программе, и имеешь возможность внеочередной записи в сетевой модуль.
С кодесисом в этом вопросе глушняк, по временной вилке между изменением бита в программе и изменением физического выхода модуля можно просто гадать.
тут и прямые руки не помогут.
А если совсем просто, получив сигнал с неизвестно какой задержкой с датчика конечного положения штуки которая шибко быстро двигается, контроллер отдаёт команду на остановку, успет ли эта штука получить команду на остановку до того как проломит стену?
А если совсем просто, получив сигнал с неизвестно какой задержкой с датчика конечного положения штуки которая шибко быстро двигается, контроллер отдаёт команду на остановку, успет ли эта штука получить команду на остановку до того как проломит стену?А это ктото обещал?
Для несинхронной шины и т.д. и т.п.
А это ктото обещал?
Вот и я про это, как узнать гарантированное время реакции сетевого выхода после его изменения в программе? и есть ли возможность внеочередной передачи туда куда нужно.
С кодесисом в этом вопросе глушняк, по временной вилке между изменением бита в программе и изменением физического выхода модуля можно просто гадатьВот тут бы я просто узнал, а когда собственно была произведена передача в сеть или хотя бы просто что произведена, то есть вот флажок и он есть упавший на данный момент.
как узнать гарантированное время реакции сетевого выхода после его изменения в программе?Никак. Это в принципе не определено в RS-485+MODBUS (подобных протоколах).
и есть ли возможность внеочередной передачи туда куда нужно.Есть, если сами напишете "систему ввода-вывода" на указанной библиотеке.
:) очень обидно, когда на форуме пишут такие слова Ну давайте откровенно говорить так, всё что работает на коде из систем типа CoDeSys немного идёт вперед и имеет шансы вырасти в нечто совсем иное, чем классический PLC. Боюсь что завтра мы может не только отойти от "классических" принципов, но и будем самостоятельно делить ядро контроллера на несколько целевых виртуальных PLC с различными свойствами, быстродействием и изолированными интерфейсами, а потом для каждого использовать различные среды программирования. Тут обижаться не на что. Для меня даже в руках ПЛК очень непривычная вещь. Вот когда стали применять азиатский корпус, а-ля Omron, держать его стало как-то комфортнее 8=). На CoDeSys же я встречал вообще системы под линухом со своим реальным монитором и уникальным интерфейсом, то есть там логика PLC используется как предмет для разговора о работе, а весь ввод-вывод организуется как придумал мастер Фриц. Я бы не удивился если бы вдруг обнаружилась система считающая нужным обратится ненадолго к внешнему миру чтобы изменить только один выход и опять уйти в себя, пока опять не появится необходимость чего-то поменять снаружи.
в свободное от основной задачи время, отсылает данные по сети. Как говориться, оставь надежду всяк сюда входящий 8=) Запомним.
То есть при цикле 1мс данные в память записываются раз в 1 мс. А если во Framing time стоит 0-Disable poll ?
При этом передача данных на устройства В\В идет последовательно, по своему алгоритму.Знание алгоритма что либо прибавит к гарантированой записи данных?
Вы можете взять с диска библиотеку Но вот реально не хочу ибо прибавиться работы еще на два-три дня. 8=)
Есть, если сами напишете "систему ввода-вывода" на указанной библиотеке.Ну вот в аналоговых вводах есть же время измерения. А тут, я так понял, для неверующих в вывод ограничились ШИМ. Если надо что-то изменять быстро, изменяй это с определенной частотой. Впринципе верно. Ну вот представляете на 1000 тонн включить здесь, а там ещё не выключилось? И всё так начинает падать вниз, и потом так бах включается всё-таки и скрежет и стоны и потом заклин и уже ничем не поднять не выбить. Я конечно утрирую ситуацию, не всё так драматично, но инстинктивно хочется иметь несколько рубежей обороны.
..в свободное от основной задачи время, отсылает данные по сети. ..
Категорически не согласен. Инициация запросов - между циклами. Сам обмен - на прерываниях.
То есть при цикле 1мс данные в память записываются раз в 1 мс.
Вы об обмене ? Это что за скорость-то ?
Вот и я про это, как узнать гарантированное время реакции сетевого выхода после его изменения в программе? и есть ли возможность внеочередной передачи туда куда нужно.
Как сказали Николаев А. и ASo - modbus.lib позволяет все это.
Если я использую своего мастера - я в состоянии посчитать гарантированное время.
На счет внеочередности - сначала мутил приоритеты. После, сидя в очереди в поликлинике, понял - внеочередность - зло. И больше не имею проблем с обменом.
..Я бы не удивился если бы вдруг обнаружилась система считающая нужным обратится ненадолго к внешнему миру чтобы изменить только один выход и опять уйти в себя, пока опять не появится необходимость чего-то поменять снаружи.
А в чем проблема ? Все в ваших руках. Надо постоянно строчить - строчите. Надо обращатся по мере необходимости - вперед. Как напишите - так и будет. Это можно и на штатных средствах сделать.
Алексей Геннадьевич
23.01.2014, 14:06
Как привязать обмен по RS485 к времени исполнения программы?
Т.Е. задаём в менеджере задач выполнение программы циклично-цикл 20-50мс (быстрее всё равно не нужно, и времени на обмен достаточно остаётся, более 80-90% процессорного времени)
задача после прогона инициализирует обмен по каналу RS485 по протоколу modbus rtu.
Обьём ввода-вывода задаём таким, чтобы при импульсной непереодичной помехе успеть сделать второй обмен.
Powered by vBulletin® Version 4.2.3 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot