О быстрых входах

[Дмитрий_П]

Коллеги, помогите решить небольшую задачку. Дано: ПЛК110 с быстрыми входами и прямоугольные импульсы с частотой 1 килогерц. Импульсы необходимо считать. Вопрос: как это правильно делать? Решение с использованием прямого доступа ко входам понятно, оно хорошо разъяснёно в видео про подключение энкодера. Но коль скоро ПЛК допускает конфигурирование входов сразу как быстрых счётчиков, то возникает идея использовать именно этот режим. Но про него, как ни странно, информации ничтожно мало. Если у кого есть пример настройки входов в этом режиме, покажите, пожалуйста. Будет совсем здорово, если пример окажется на CFC.

[IVM]

Задача number two. ;)

[Дмитрий_П]

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

Передо мною поставлена задача автоматизировать некое оборудование. И у меня есть готовый, отлаженный проект, который прекрасно эту задачу решает... но только на частотах, доступных обычным входам и выходам. Остаётся только его "разогнать". С выходами этап пройден, меандр будет создаваться сторонним генератором, хоть я и хотел сделать красиво и генерировать импульсы в ПЛК. Предвосхищая вопросы, сразу скажу, что в данном случае мне не нужно ни управление частотой и скважностью, не нужны рампы разгона и торможения, всеми этими мелочами занимается драйвер движка. Мне был нужен стабильный килогерц. Я его таки добыл :) Осталось разобраться с обсчётом. Повторюсь: по управлению входами в режиме прямого доступа проблем нет, в видеоуроке про энкодер всё изложено и показано. Но хочется попробовать и второй способ, по которому информации просто нет.

[ASo]

Быстрый счётчик, который сбрасывается в каждом цикле -- это вообще гениальная находка!
Это стандартный подход к подобным счётчикам во многих ПЛК.
В каждом цикле и обрабатывайте суммированием в накопителе, вычислением среднего или ещё как. За переполнение отвечает программист.

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

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

[Дмитрий_П]

Дмитрий, конечно Вы правы. Хотя с другой стороны, зачем бы я вообще стал задавать здесь вопросы, если бы всё знал и понимал? :) Я не профи в программировании, но и не совсем новичок, в загашнике есть несколько реализованных проектов. Но вот с "быстрой" частью ПЛК я столкнулся впервые и с ними действительно, вопросов больше чем ответов. Да и отношение разработчиков к этой части функцонала... хм... право же странное. В 99% случаев быстрый вход это либо счётчик, либо энкодер либо частотомер. А выход это или ШИМ или генератор импульсов или дискретный выход с быстрой реакцией. Ну дайте вы пользователю готовые шаблоны, библиотеки, заготовки в этой части и бОльшая часть вопросов отпадёт сама. ПЛК -- это инструмент, а инструмент должен быть не только функциональным, но и удобным.
Впрочем, я снова офтоплю. За наводку по ПЛК 100 спасибо, пойду почитаю. Но опять-же, прошу коллег: если у кого есть простой пример организации быстрого счётчика на CFC поделитесь для ознакомления :) Полагаю, что у профи создание такого образца займёт пару минут -- не более :)

[ASo]

Да пожалуйста.

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

CFC - диаграмма, в которой удобно общий алгоритм устройства рисовать - каждый блок выполняется минимум цикл и засовывать такую конструкцию в обработку быстрого счетчика ... ну совсем не быстрым он будет, если вообще заработает ))) ... поэтому вряд ли кто сможет помочь...

на ST это будет выглядеть одной строчкой
COUNTER_SUM := COUNTER_SUM + COUNTER_HARD;
где COUNTER_HARD - аппаратный счетчик назначенный на вывод, после считывания переменная обнуляется автоматически

я быстрые куски делаю на IL, делал опыты - самое быстрое выполнение кода

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

Да пожалуйста.

все так, только операция не AND а ADD, наверно )))

упс. диаграммы SFC а не CFC )))

[ASo]

Да, естественно ADD. Очепатка.

[Дмитрий_П]

ASo, спасибо, пойду изучать. На реальном железе смогу проверить только в среду, ибо работаю сутки-трое :)

[Дмитрий_П]

Дмитрий, мой случай не требует экстремального быстродействия, так, что думаю, всё должно завестись. А так да, я понимаю, что "текстовые" языки эффективнее "графических". Но до сих пор для моих нужд и CFC хватало с избытком.

[ASo]

Никак не эффективнее.
Скажем так, Вам достаточно, что бы вычисления уложились в выбранный Вами цикл. А займут они 1% или 90% времени цикла - какая разница?

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

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

[Спорягин Кирилл]

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

Дмитрий, подробней можно. Вы имеете ввиду, что половина всех проблем с быстрыми входами/выходами - это "вылет" кода за время цикла. Или вообще всех проблем?
Если второе, то приведите примеры. Когда что-то некорректно работает, а оказывается виновато время цикла.
Спасибо.

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

Вообще всех проблем - например, типовой совет при сбоях обмена по встроенным интерфейсам посмотреть и увеличить время цикла.
Кроме того, года 2 назад, на ПЛК100, после того как надоело удивляться всяким нежданчикам, стал инвертировать транзисторый вывод в каждом цикле и смотреть осциллографом, дык модуль статистики показывал 1200 - 1400 мкс, перегрузка не горела (цикл был 2мс), а осциллограф показывал длительность 2 - 2,5 мс.. после оптимизации кода до 1000 мкс - фронты пошли через 2 мс и все стало адекватно...

[Спорягин Кирилл]

Вообще всех проблем - например, типовой совет при сбоях обмена по встроенным интерфейсам посмотреть и увеличить время цикла.
Кроме того, года 2 назад, на ПЛК100, после того как надоело удивляться всяким нежданчикам, стал инвертировать транзисторый вывод в каждом цикле и смотреть осциллографом, дык модуль статистики показывал 1200 - 1400 мкс, перегрузка не горела (цикл был 2мс), а осциллограф показывал длительность 2 - 2,5 мс.. после оптимизации кода до 1000 мкс - фронты пошли через 2 мс и все стало адекватно...

А какого рода были "нежданчики"?

[Дмитрий_П]

Со счётчиком разобрался, всё работает, всем большое спасибо за помощь, особенно тов. ASo за предоставленный пример.