Какое быстродействие у контроллеров ПЛК100,150,154,110,160

[Olegis]

Вопрос к разработчикам! Укажите, пожалуйста, какое быстродействие у контроллеров ПЛК 100,150,154,160 в виде, например, 1000 логических инструкций за 1 мс. В инструкции нашел только для ПЛК110 - 50 логических инструкций за 1 мс без учета сетевого обмена. Да и хотелось бы знать сколько байт занимает - одна логическая инструкция в этом расчетном быстродействии.

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

С CoDeSys подход к выполнению программы несколько отличается от стандартного подхода того же Mitsubishi.
1мс - минимальный гарантированный цикл ПЛК. За это время он успевает выполнить МИНИМУМ 50 логических операций.

Так как код заливается в контроллер скомпилированный - сколько байт занимает одна логическая операция сказать сложно.

[Olegis]

Получается у всех перечисленных контроллеров одинаковое быстродействие или разное?

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

В основе всех этих контроллеров лежит одно и то же ядро.

[Адрей]

С CoDeSys подход к выполнению программы несколько отличается от стандартного подхода того же Mitsubishi.
1мс - минимальный гарантированный цикл ПЛК. За это время он успевает выполнить МИНИМУМ 50 логических операций.

Так как код заливается в контроллер скомпилированный - сколько байт занимает одна логическая операция сказать сложно.

Было бы не плохо знать время каждый операции по быстродействию выполнения.

[Малышев Олег]

Частота процессора 180 МГц, архитектура - risc - т.е. практически все инструкции выполняются за 1 такт. Далее ограничение быстродействия SRAM - 60МГц. Одна логическая инструкция - 1-3 машинных инструкции (кодов). Считайте примерное быстродействие.

[Дмитрий Артюховский]

"Было бы не плохо знать время каждый операции по быстродействию выполнения."
... это совершенно не показатель для контроллеров овена :) языки программирования высокого уровня, поэтому добираться до инструкций бессмысленно. Кроме того, время цикла здорово зависит от количества модулей которые вы подцепляете в конфигурации... и оччччень зависит от установленной прошивки. Поэтому, труд считать такты - сизифов, слишком от многих скрытых производителем, параметров зависит время цикла.... пишите и смотрите время выполнения.... на самом деле при вдумчивой оптимизации и размазывании выполения по циклам влезает очень большой код.... у меня получались проекты, весящие после компиляции более мега (только код, не данные) с циклом в 1.5 мс

[Olegis]

у меня получались проекты, весящие после компиляции более мега (только код, не данные) с циклом в 1.5 мс
Дмитрий! Что-то у меня никак не получается даже при разбросе по циклам влезть в цикл даже в 15 мс. Код после компиляции занимает около 500 кБ. В сети 198 устройств, скорость 19.2кб. SCADA- встроенная HMI CoDeSys. Вот и думаю, что маловато будет, если выполняется 50 инструкций за 1мс.

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

Цикл ПЛК - это не только выполнение команды. Это и опрос входов, и запись выходов, и сервисные функции, и обмен по сети. Последний, как и было написано, отъедает весомый кусок работы ЦП.

[Дмитрий Артюховский]

при таком количестве приборов ждать быстрого отклика не приходиться...
- поэтому растягиваем обмен по различным циклам контроллера... для растягивания удобно использовать SCF диаграммы, очень наглядно при отладке.. скажем по десятку приборов в шаге;
- встроенная HMI довольно хорошо грузит контроллер, это надо учитывать и возможно, перейти на другой способ архивирования данных, стоит посмотреть, нет ли лишних переменных в отображении
- опросные группы приборов конфигурировать на опрос не по времени, а по старт/стопу, с выбором опрашиваемой группы из программы... это позволит создавать паузы между опросами... при перегрузке циклов инструкциями, они выходят за временные рамки, но все равно выполняются, отставание растет как снежный ком. Если предусмотреть разгрузочные циклы, как бы остановки, позволяющие процессору "догонять поезд" вычислений, то проблема становиться не критичной;
- возможно стоит также сделать свою процедуру для опроса приборов, не то чтобы овеновская не работает, а с целью более гибко управлять процессорным временем, кто знает как работает встроенный модуль modbas-a, какие там встроены запасные таймы и проверки.... алгоритм написанный на конкретную задачу всегда быстрее чем написанный на все случаи жизни....
Количество опрашиваемых приборов и скорость связи с ними, ниразу не должны влиять на цикл контроллера, меняется только время отклика (опрос всей матрицы + реакция на опрос)

[lara197a]

При наличии 198 приборов в сети, нужно или смириться с тем, что есть или выбирать др.контроллер.
К примеру при использовании S400, при скорости опроса 10мбит, и использовании коммуникационных контроллеров E200, которые обрабатывают и упаковывают все данные от подчиненных приборов,Вы получите примерно 10-15 мс.
Овен отличный контроллер, но для своих задач.
Из собственных экспериментов:
в цикл 1мс укладываются 150 операций битовых + 30 операций с плавающей точкой. При общем количестве операций больше 200 время >1мс. Тестил при отключенном от онлайн контроллере. При включенном онлайн- время цикла очень сильно плавает от1 до 15-20мс эпизодически.

[Andy]

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

[Дмитрий Артюховский]

198 ПРИБОРОВ И ВСЕГО 100 ПЕРЕМЕННЫХ?
... а про HMI, специальных измерений не делал, но при отключении ПК с визушкой за 25-30 переменных, цикл сокращается на 100 - 200 мкс. Смотрел переменную длительности цикла, сливаемую собственным протоколом по TCP...
... а причиной проблем является неверный алгоритм программы ПЛК, ну не должно количество опрашиваемых переменных влиять на длину цикла, опросы нужно разносить во времени, по циклам

[Andy]

??? У меня 7 МДВВ, 3 МВА и 3 МВУ.
Далее, 100-200 микросекунд несущественно, ИМХО.
С последним абзацем не понял, о чем речь. Ведь опросы переменных ведутся за пределами рабочего цикла ПЛК. Или речь о рантайме КДС, а не о программе?

[Serge_UA]

...ну не должно количество опрашиваемых переменных влиять на длину цикла, опросы нужно разносить во времени, по циклам
Абсолютно неверное утверждение с точки зрения системотехники. Однако в суровой реальности ПЛК Овен по другому не получится. :(

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

К тому же не факт, что вы получите выигрыш в производительности системы в целом, потому что длительность цепочки "получение входных данных" => "обработка данных" => "выдача управляющего воздействия" не изменится. Какая разница длительность этой цепочки равна циклу 100мс или 5-ти циклам по 20 мс? Исключение составляют объекты управления, элементы которых слабо взаимосвязаны между собой.

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

Надеюсь критика воспримется адекватно.

[Andy]

modbuslib я не использую, все переменные внешние прописаны в конфигурации. Может, в этом разночтения?

[Дмитрий Артюховский]

"К тому же не факт, что вы получите выигрыш в производительности системы в целом, потому что длительность цепочки "получение входных данных" => "обработка данных" => "выдача управляющего воздействия" не изменится. Какая разница длительность этой цепочки равна циклу 100мс или 5-ти циклам по 20 мс? Исключение составляют объекты управления, элементы которых слабо взаимосвязаны между собой."

ИМЕННО ФАКТ!!! я сделаю 100 циклов по 1 мс и смогу контроллировать систему 1000 раз в секунду, а не 10. Управляемость, плавность управления, реакция на нештатные ситуации....
... опрос большого числа приборов по последовательному каналу я не сделаю быстрым никак, но сохранить управляемость системы могу....

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

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

опрашивать можно как своим алгоритмом, так и встроенными средствами, используя не опрос по времени, а старт/стопы....

... глобальный цикл управления : "опрос всех приборов - обработка - реакция" быстрее не сделать, но так ли это нужно... и зачем торомозить алгоритм в ожидании медленного опроса последовательных приборов, когда группа данных необходимая для локальной задачи уже получена?

да, нужно внимательно следить за актуальностью данных, но это не сложная задача по сравнению с "мировой революцией"