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

[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. Управляемость, плавность управления, реакция на нештатные ситуации....
... опрос большого числа приборов по последовательному каналу я не сделаю быстрым никак, но сохранить управляемость системы могу....

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

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

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

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

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