Прерывания и пляшущая скорость, Обработка импульсов в парерываниях Опции

[Franc]

Помогите, пожалуйста, молодому бойцу!
Описание задачи.
Имеется установка: двигатель, редуктор, эл. тормоз. На входном и выходном валах редуктора установлены датчики
момента. Датчики так же выдают на один оборот вала по одному импульсу, что позволяет вычислить скорость вращения валов.
Для управления установкой и выполнения расчетов используется ПЛК FX3U. Интерфейс пользователя организован
в MX4SCADA. С помощью СКАДА данные измерений и расчетов записываются в БД Access.
Программирование ПЛК выполняется с помощью GX Developer FX 8.78G.
Вычисление скорости вращения валов сделано с помощью прерываний по входам X000 и X001, куда приходят
импульсы с датчиков. Вот фрагменты программы с прерываниями.
 12.PNG ( 10.11 килобайт ) Кол-во скачиваний: 78

 13.PNG ( 11.62 килобайт ) Кол-во скачиваний: 65

При мониторинге программы значения скорости периодически испытывают скачки, принимают нереальные значения.
Может быть неправильно организованы прерывания, или еще что не так?
Еще замечено, что если из программы выбросить все постороннее (около десятка подпрограмм),
т.е. оставить прерывания и команды управления двигателем (так сказать, облегчить программу),
то расчетные значения скорости получаются вполне стабильными (колебания в десятых-сотых долях).
В этом случае время скана около 12 мс (до урезания программы около 50 мс).

[Sergei Troizky]

Сразу напрашивается мысль о потере прерываний, если суммарная частота на всех высокочастотных входах выше предельной (которая может зависеть от набора выполняемых высокочастотных операций).
Выброшенные фрагменты содержат высокочастотные счетчики либо высокочастотные операции?
Также, в коде первого прерывания не видно IRET. Оно содержит что-либо еще?

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

Ну, а скан в 50мс я бы считал катастрофой, хотя к вопросу это не имеет отношения.

Сообщение отредактировал Sergei Troizky - 4.11.2010 - 08:28

[Franc]

Частота вращения вала привода не превышает 1500 об/мин. Вряд ли это проблема для контроллера.
IRET не попала в скриншот.
Насчет "что-то ... изменяет значение в регистрах измерения скорости" тоже думал, анализировал,
перебирал инструкции и близлежащие адреса - ничего криминального не обнаружилось.
Может тормозят эти хваленые прерывания?
Кстати, длина импульса датчика наводит на размышления. Где-то читал, что для прерываний импульс должен быть
не менее 200 мкс.
Так же, может быть, пойти от обратного? Нагружать урезанную программу тестовыми подпрограммами
и смотреть как влияет время скана на качество обработки прерываний?

[inntele]

На входном и выходном валах редуктора установлены датчики момента. Датчики так же выдают на один оборот вала по одному импульсу, что позволяет вычислить скорость вращения валов... Частота вращения вала привода не превышает 1500 об/мин... Для прерываний импульс должен быть не менее 200 мкс.

При такой частоте импульсов (25Гц) прерывания излишни, в том случае, если длительность импульса больше длительности скана программы. Чтобы не гадать на кофейной гуще по поводу длительности импульса, померьте его с помощью осциллографа.

Что касается длительности скана в 50мс, то абсолютно согласен с Сергеем - для программ на контроллере FX3U это просто "абзац", и говорит о том, что программа изначально написана очень плохо. На самом деле должен смущать даже 10мс скан, поскольку это тоже многовато. По уму, в теле прерываний не должно производиться никаких вычислений.

Сообщение отредактировал inntele - 4.11.2010 - 14:39

[Franc]

Спасибо за отклики. В ближайшие дни доберусь до установки с осцилографом.
Попрубую убрать вычисление скорости из прерываний.
Насчет времени скана - чем тут поможешь программе? В урезанной версии она содержит команды пуск/стоп привод,
конфигурирования аналоговых модулей ввода/вывода, пересылки аналоговых выходов и два прерывания.
Ни отнять ни добавить, а имеем 12 мс.
Наладка еще в процессе, поэтому через дней несколько может еще что прояснится.

[Franc]

Забыл добавить, что в программе пришлось реализовать алгоритм наподобие "интерпретатора". Дело в том,
что параметры испытания редуктора (скорость, момент, время испытания) хранятся в табличке БД Access (нечто вроде
программы). Программа в связке со СКАДой вычитывает построчно эти параметры из базы, и редуктор, соответственно,
испытывается при разных режимах. Имеются так же подпрограммы обработки сигналов с кучи датчиков температуры (и еще всяка разна).
Вся эта кухня, возможно и дает такое время.
Хотя, стоит признать, что оптимизировать все это может и можно (и нужно), да опыта пока маловато.

[inntele]

Забыл добавить, что в программе пришлось реализовать алгоритм наподобие "интерпретатора". Дело в том,
что параметры испытания редуктора (скорость, момент, время испытания) хранятся в табличке БД Access (нечто вроде
программы). Программа в связке со СКАДой вычитывает построчно эти параметры из базы, и редуктор, соответственно,
испытывается при разных режимах. Имеются так же подпрограммы обработки сигналов с кучи датчиков температуры (и еще всяка разна).
Вся эта кухня, возможно и дает такое время.
Хотя, стоит признать, что оптимизировать все это может и можно (и нужно), да опыта пока маловато.

Все равно скан не должен занимать столько времени. В свое время пришлось столкнуться с задачей на FX3U, где одновременно с серьезными алгоритмами обработки данных и двумя драйверами последовательного интерфейса со свободно-программируемым протоколом за один скан необходимо было перезаписывать 36Кслов. В момент такой перезаписи скан достигал 10мс., в остальное время около 4-х. Но там было без вариантов. Вообще достичь стабильности времени сканирования одна из главнейших задач при создании программы.
Что касается опыта, то сами понимаете - это наживное. При хорошем базовом образовании важно только начать разбираться в проблеме, а решение последует.

[Franc]

Кое-что выяснилось. В программе было два алгоритма вычисления скорости - по прерываниям и еще в отдельной подпрограмме (почему так, пока не будем выяснять). В зависимости от скорости принималось значение, вычисленное в одном из алгоритмов. Ошибка, скорее всего в том, что условием выбора алгоритма была скорость, вычисленная в одном из самих же алгоритмов, от чего и возникали такие коллизии. Оставил только по прерываниям, и значения стабилизировались, по крайней мере в течении 60 с выбросов небыло. Хотя, в общем-то, вопрос с контроля я пока не снял.
По поводу частоты 25 Гц. Измеренная длина импульса при частоте 400 об/мин составила 10 мс. Наверное, здесь путаются понятия частоты и длины импульса. При частоте 25 Гц длина импульса может быть и 10 мс, 20 мс, и т.д., пока не приблизится к длине периода колебаний (я так думаю).
При требовании длины в 200 мкс этого вполне достаточно.
Со временем скана не знаю что сказать (почему такой разброс для, в общем-то, не "тяжелых" программ). Может у контроллера есть какие-нибудь настройки (в смысле что-нибудь включить или отключить)?

[inntele]

По поводу частоты 25 Гц. Измеренная длина импульса при частоте 400 об/мин составила 10 мс. Наверное, здесь путаются понятия частоты и длины импульса. При частоте 25 Гц длина импульса может быть и 10 мс, 20 мс, и т.д., пока не приблизится к длине периода колебаний (я так думаю).
При требовании длины в 200 мкс этого вполне достаточно.
Со временем скана не знаю что сказать (почему такой разброс для, в общем-то, не "тяжелых" программ). Может у контроллера есть какие-нибудь настройки (в смысле что-нибудь включить или отключить)?

Во-первых, я не помню, чтобы вы говорили о частотном регулировании привода, ну да и бог с ним. Если 1500об/мин при частоте 50Гц, и выше 50 Гц частота не поднимается, тогда это и есть наихудший вариант. Понятия частоты и длины импульса не путаются. Частота сигнала определяется частотой вращения привода, длительность импульса - временем срабатывания датчика при проходе реперной точки и тоже зависит от частоты вращения привода. Зависимость между ними обратная, а вот скважность импульса (соотношение длительности 0 и 1) - величина постоянная. Если при частоте вращения привода 400об/мин длительность импульса 10 мс, то при 1500об/мин длительность импульса будет 10*400/1500=2,67мс. Стало быть без прерываний не обойтись. А вот само вычисление чисел с плавающей запятой правильно вынести из тела прерывания в тело программы.

Сообщение отредактировал inntele - 4.11.2010 - 19:32

[Franc]

Согласен. Будем посмотреть.

[Franc]

Может и не стоит дальше копать, но почему такое большое время скана (50 мс) в сравнении с приведенными вами (предположив что кривизна программы в пределах допуска). Может процессоры разные. У меня FX3U 64MT/DSS.

[inntele]

Может и не стоит дальше копать, но почему такое большое время скана (50 мс) в сравнении с приведенными вами (предположив что кривизна программы в пределах допуска). Может процессоры разные. У меня FX3U 64MT/DSS.

Нет, от базового блока, или как вы его назвали "процессора", сие не зависит. 100% за то, что это неоптимально написанная программа.

[Sergei Troizky]

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

Да, так часто делают: на низких оборотах измеряют период и пересчитывают в обороты, а начиная с некоторой скорости- впрямую измеряют частоту.
Условием выбора алгоритма и должна быть скорость, вычисленная в одном из самих же алгоритмов, что же еще?
Оба измерителя должны считать всегда, иначе и могут возникать нереальные значения в момент переключения между измерителями.
Скачки в момент переключения неизбежны, но могут быть минимизированы правильным выбором порога переключения.

Касательно скана: Вы уверены, что не путаете единицы измерений?
50 в D8010 означает 5мс.

Сообщение отредактировал Sergei Troizky - 6.11.2010 - 22:32

[Sergei Troizky]

Вообще достичь стабильности времени сканирования одна из главнейших задач при создании программы.

Сказать по правде, не понимаю, чем это важно. Тем более, почему это должно быть "одной из главнейших задач".
Все действия, критичные к периодичности сканирования, должны производиться в прерываниях (по таймеру, либо по входам).

Сообщение отредактировал Sergei Troizky - 6.11.2010 - 19:55

[inntele]

Вообще достичь стабильности времени сканирования одна из главнейших задач при создании программы.

Сказать по правде, не понимаю, чем это важно. Тем более, почему это должно быть "одной из главнейших задач".
Все действия, критичные к периодичности сканирования, должны производиться в прерываниях (по таймеру, либо по входам).

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