Скорость плк

[smk1635]

Да и еще, в инструкции написано, что задавать минимальное время цикла надо с таким расчетом что бы оставалось ~20% свободного времени, а как понять хватит ли 20% для сетевого обмена?

Правильно, ни как. Только методом тыка.
Той зимой монтировали оборудование. Все отладили. Все прекрасно работало. Летом, в цехе температура зашкалила за +45 градусов, пошли периодические отваливания по обмену. Пока не увеличил время с 30 мс до 50 проблема не решилась. И как тут просчитаешь?

[Olegis]

Явыставил время цикла в 0, вызов программы раз в 100мс и стал счастлив)

Сделал как sink3d на большом проекте, визуализация Codesys HMI стала летать! До этого еле ползала, переходы между экранами ждал по 3 секунды. Может это конечно будет в ушерб обмену по сети, но я его проверить толком не могу сейчас, надо время. У меня время цикла без оптимизации получалось 51мс. Никому нельзя доверять!? (в смысле мануалу на ПЛК).

[BETEP]

А мне доверять можно?

Фиксировать время цикла стоит только в том случае, если ваша прога этого требует, задачи разные бывают.

[Евгений_Томск]

Поддерживаю мнение коллег о том, что значение времени цикла на ПЛК в существующих условиях надо ставить в "условный" 0, а оптимизацию программы каждый выполнит уже самостоятельно контролируя реальное время цикла через модуль статистики или через встроенные часы.

Не совсем понятна позиция Андрея в стремлении закрыть обсуждение.

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

По-существу,обобщая мнения, наверно можно предложить коллегам из компании Овен:

1. Заменить в конфигурации ПЛК значение "0" на "AUTO" .Так будет всем понятнее,что речь не о мифическом нулевом времени цикла,а об автонастраивающемся режиме.

2.По умолчанию в ПЛК установить режим "AUTO". Т.к. из имеющейся изначально 1мс проект выходит очень быстро.Как правило 3...5мс или 10...15 мс ,если есть кучка MODBUS регистров именно в ПЛК конфигурации. Считаю эти цифры вполне нормальными.

Информация и обмен ею важны и нужны.Посмотрел рост оборотов компании "Mail.ru" в этом году : около 40процентов при сумме около 7млрд.Основной прирост из принадлежащих им соцсетей "однок...и" и частично" в к...", а не от рекламы.
Представляю какие обороты у "Goog.."

Поэтому считаю что лучше открывать , чем закрывать.И готовиться к работе с гигатоннами информации Мы все "в одной лодке"... современной и автоматизированной.И догонять есть кого...

[drvlas]

Не совсем понятна позиция Андрея в стремлении закрыть обсуждение

Ну, здесь уже некая реакция на мои едкие высказывания. Готов извиниться, если это задевает представителей компании ОВЕН. Как-то мне казалось (и кажется), что с юмором легче и интереснее обсуждать даже сУрйозные вопросы

Рад, что коллеги поддержали. Не очень надеюсь, что ОВЕН бросится исправлять Руководства и дефолтное значение МинВЦ - у них там тоже хватает работы и на старые ПЛК уже внимание не то (хотя и очень жаль, что так получается).
Но как-то дать разработчикам понять, что по умолчанию следует поставить МинВЦ = 0, и лишь при специальной потребности играться с ненулевым - поможет даннная тема. Внимательный найдет.

[Титаренко Михаил]

Я бы так описал логику работы:
Если задано минимальное время цикла: 1. Выполняется программа пользователя. 2. Оставшееся время идёт на сетевой обмен. Если все посылки ушли - это замечательно. Если ушли не все посылки, то выполняем пункт "1", а при случае (в конце следующего цикла) доотправим оставшиеся. Подводный камень - буфер между основным процессором и процессором переферии имеет ограниченный объём. Увеличив в 10 раз время цикла - имеем падение в 10 раз скорости передачи. Т.е. если раньше мы упирались в потерю данных из-за того, что часто передавали от центрального процессора к переферийному процессору, то теперь упрёмся в то что переферийный процессор не успевает отсылать данные.
Т.е. - берега узкие, куда ни кинь - всюду клин.

Я вижу только одно применение минимального время цикла, которое уже упоминали в этой ветке: Не давать процессору бесполезно греть воздух (заставить простаивать большую часть времени). Не рационально? Зато не требует ни анализа исходников, ни редактирования программы.

[Андрей007]

Подскажите, а как вы смотрите реальное время цикла программы?

[petera]

Подскажите, а как вы смотрите реальное время цикла программы?

VAR
	delta: TIME;
	prevScanTime: TIME;
END_VAR

(*Время цикла*)
delta := TIME() - prevScanTime;
prevScanTime := TIME();

[sink3d]

Время прогона программы больше 50мс, пусть будет 60мс. Меня устраивает время реакции системы 240мс.Какой тогда выход из ситуации?
У меня есть несколько вариантов:

1. Поставить время минимального цикла 50мс.Разбить программу с помощью case, скажем по 48мс(2мс на сетевой обмен опрос входов/выходов и.т.д.),
2. Поставить время минимального цикла 2мс(на сетевой обмен опрос входов/выходов и.т.д.), основную программу вызывать раз в 120мс(через конфигуратор задач),
3. Использовать более быстрый плк.

2й вариант меня смущает, но работает.Причем флаг перегрузки CPU не горит. Кто сталкивался, хотелось бы комментариев.

[capzap]

Кто сталкивался, хотелось бы комментариев.

Мое мнение, Вам вредно читать эту тему