YuriBel заметил у Вас на скрине разные значения PV_time. Вы откуда берете эти значения?
YuriBel заметил у Вас на скрине разные значения PV_time. Вы откуда берете эти значения?
Я использую блоки МВ110-2А, и из них забираю это время. соответственно , для каждого канала это время своё. Насколько я понял. Овеновская библиотека под это "заточена", это позволяет точнее вычислять интегральную составляющую.
Используете регистры "Циклическое время измерения входа"?Сообщение от YuriBel
У меня тоже стоит МВ110 только 8а. Мне кажется если не читать регистры групповым запросом, то особой точности от этого не получишь, ввиду задержек при опросе. Я в каждом цикле программы увеличиваю счетчик на время цикла и подаю на вход, потому что есть два датчика температуры с rs 485.
Если переменные INDEX и NEXT не сбрасываются при обнуление и перезаливки программы, значит они пишутся в определенную область памяти?
Да, я использую данные этих регистров. Блоки медленные, и если вы читаете их чаще, чем в каналах обновляются данные, не учитывая время, в которое они измерены, то вносите дополнительную погрешность в интеграл. Я читаю из блока необходимые данные одним запросом (строкой), поэтому полагаю, что опрос у меня идет чаще, чем измеряются данные в каналах. Но это все нюансы, никак не связанные с тем, что у вас из нескольких регуляторов работает только один. Почему так получается- не знаю. Но там, где несколько регуляторов работают, у них разные переменные Index и Next. Так что даже и не знаю. что посоветовать. Возможно, имеет смысл перейти на регулятор из Util.lib.
У меня была такая же проблема с ФБ в своем проекте. Год назад делал станок на ПЛК110 -М2. Общался с техподдержкой, но результата не было. Да и некогда было, станок уже надо было сдавать в работу. Вот выдержки из письма:
"
1. Вначале самопроизвольно изменялась переменная внутри функционального блока
(этот ФБ имеет 18 экземпляров).
Решил, что возможно, это я где-то ошибся. Переписал ФБ без этой внутренней переменной.
Ошибка пропала.
2. Потом в переключателе CASE возникли переходы из состояния CLOSE в
состояние BEGIN, хотя по программе это возможно только из состояния M_CUT.
Эти состояния используются в подпрограммах left_mould_cycle, right_mould_cycle
по переменным l_mould_mode, r_mould_mode. Эту ошибку я вообще никак
не смог отловить и объяснить.
На скриншоте видно, что экземпляр ФБ screv_lower_ctrl вызывается с параметром
IN := FALSE, и в то же время его выход screv_lower_ctrl.Q = TRUE (а по логике
ФБ должен быть FALSE). И в отладчике видно, что ФБ вызван с IN = TRUE?!!
"
Поскольку был цейтнот, тупо переписал программу, выкинув все ФБ (!).
Но это точно ошибка где-то в распределении памяти ПЛК, поскольку ФБ влияют друг на друга.
Теперь боюсь брать ПЛК110-М2 в свои проекты.
Это не "ля-ля с картинками", а отладчик, в котором видно, что в основной программе вызывается экземпляр ФБ с IN := false, а внутри экземпляра этого ФБ вход IN имеет значение true в это же самое время!
Такое возможно только если меняли таргеты, большой кусок кода ещё что-то тогда нужно сделать "Очистить всё" и перекомплировать проект и всё станет в норму. Если это делали, то 100% ошибка в коде которую вы не можете найти. Может где-то в другом куске программы присваиваете этому фб на вход IN:=TRUE. Сами же пишете что первый раз переписали ФБ и стало норм. Не совсем понятное для меня использование Case и таймеров внутри условий(что тоже нужно делать аккуратно).
Согласен с Валенком тоже используем большое количество ФБ с указателями и без. И никогда не было проблем с распределением памяти только собственные ошибки.
Пунктом "Очистить все" действительно, я не пользуюсь (даже не знаю, что он делает). Всегда делаю "Компилировать все".
Все изменения команды на вход делаются выше по коду. Потом один раз вызывается этот ФБ.
Мне тоже непонятно ваше высказывание. Пришла команда отработать цилиндру - включить таймер, надо считать время работы цилиндра.
А CASE и IF вообще братья-близнецы. CASE только намного лучше читается.
Непонятная мне необходимость в указателях! А зачем они вам?
Это точно. Ошибку не нашел.
Последний раз редактировалось Евгений Пашигоров; 31.03.2021 в 10:39.
Чтобы можно было оперировать не целиком данными, а указателями на них, но это достаточно сложное для понимания колдунство. Утрированный пример таков: есть два человека в отеле, которые хотят поговорить (обменяться данными), и можно их друг с другом свести лицом к лицу т.е. доставить целиком человека из одного номера в другой, материально переместить, и есть телефонистка, которая может просто соединить телефонное гнездо первого человека с телефонным гнездом второго человека, и произойдёт передача данных от одного человека к другому. Указатели используются для достижения полиморфизма, когда вам, грубо говоря, не важен сам человек, а важен человек в том номере, с которым соединит телефонистка, а будет там мужчина, женщина или ребёнок не так принципиально, утрировано как-то так.
Частный случай использования указателей, как принципиального способа структурирования данных - это массивы.
И тогда ваша запись вида:
превращается в:Код:PROGRAM temperature_ctrl VAR pwm1chan, pwm2chan, pwm3chan, pwm4chan, pwm5chan, pwm6chan, pwm7chan, pwm8chan: PWM_B; END_VAR
А конструкция вида:Код:pwmchan: array[1..8] of PWM_B;
(Превращается в:Код:*формируем код устройства*) ... panel_error1 := BOOL_TO_INT(cmd_l_mould_forw OR cmd_l_mould_back OR cmd_l_mould_open OR cmd_l_mould_close) * 1 + (*левая форма*) BOOL_TO_INT(cmd_r_mould_forw OR cmd_r_mould_back OR cmd_r_mould_open OR cmd_r_mould_close) * 2 + (*правая форма*) BOOL_TO_INT(cmd_screw_rising OR cmd_screw_lower) * 4 +... (*шнек*) ...
т.е. не целиком числовые значения перемещать, переммножать и суммировать в переменные, а работать напрямую с битами.Код:panel_error1.0:=cmd_l_mould_forw OR cmd_l_mould_back OR cmd_l_mould_open OR cmd_l_mould_close; panel_error1.1:=cmd_r_mould_forw OR cmd_r_mould_back OR cmd_r_mould_open OR cmd_r_mould_close; ...
Последний раз редактировалось Parovoz; 01.04.2021 в 06:50.
Ваши права
Ответить с цитированием