ASo, спасибо, пойду изучать. На реальном железе смогу проверить только в среду, ибо работаю сутки-трое
ASo, спасибо, пойду изучать. На реальном железе смогу проверить только в среду, ибо работаю сутки-трое
Дмитрий, мой случай не требует экстремального быстродействия, так, что думаю, всё должно завестись. А так да, я понимаю, что "текстовые" языки эффективнее "графических". Но до сих пор для моих нужд и CFC хватало с избытком.
Никак не эффективнее.
Скажем так, Вам достаточно, что бы вычисления уложились в выбранный Вами цикл. А займут они 1% или 90% времени цикла - какая разница?
половина обсуждаемых на форуме проблем - это "вылет" кода за время цикла, иногда периодический, редкий и поэтому сложно диагностируемый... ну и уменьшение времени цикла - это повышение точности регулирования
Дмитрий, подробней можно. Вы имеете ввиду, что половина всех проблем с быстрыми входами/выходами - это "вылет" кода за время цикла. Или вообще всех проблем?Сообщение от Дмитрий Артюховский
Если второе, то приведите примеры. Когда что-то некорректно работает, а оказывается виновато время цикла.
Спасибо.
Вообще всех проблем - например, типовой совет при сбоях обмена по встроенным интерфейсам посмотреть и увеличить время цикла.
Кроме того, года 2 назад, на ПЛК100, после того как надоело удивляться всяким нежданчикам, стал инвертировать транзисторый вывод в каждом цикле и смотреть осциллографом, дык модуль статистики показывал 1200 - 1400 мкс, перегрузка не горела (цикл был 2мс), а осциллограф показывал длительность 2 - 2,5 мс.. после оптимизации кода до 1000 мкс - фронты пошли через 2 мс и все стало адекватно...
А какого рода были "нежданчики"?
Со счётчиком разобрался, всё работает, всем большое спасибо за помощь, особенно тов. ASo за предоставленный пример.
Ваши права
Ответить с цитированием