Александр Андреевич Симонов
Инженер по продуктам «ПЛК, модули и OwenCloud»
Не работаю в ОВЕН с 01.07.22
По всем вопросам обращайтесь на почту: support@owen.ru
На ПЛК 160 счетчик сбрасывался сам при чтении переменной привязанной в конфигураторе, а теперь на ПЛК 160 [M02] пришлось сделать костыль с разностью значений между циклами. И при переполнении счетчика требуется еще контролировать чтобы кракозябра не получилась.На сколько я помню сброс не предусмотрен.
Предполагается, что в коде проекта вы заводите свою переменную, и сбрасываете туда дельту показаний счетчика, между циклами ПЛК.
.............
Последний раз редактировалось Валенок; 25.10.2021 в 22:19.
Просто должно работать и так с аппаратным сбросом счетчика. Или не должно? Почему тогда это не появилось в описании переноса прошивки с ПЛК 160 на ПЛК 160 [M02]?
Добрый день.
Это как раз не костыль.
Это правильная работа со счетчиком.
Вы просто пишете такой код:
ВашСчетчик := ВашСчетчик + (ПоказанияСчетчикаВЭтомЦикле - ПоказанияСчетчикаВПрошломЦикле);
При необходимости увеличения диапазона счетчика (до 4 294 967 295) можно сделать его типом DWORD и тогда код будет таким:
ВашСчетчик := ВашСчетчик + WORD_TO_DWORD(ПоказанияСчетчикаВЭтомЦикле - ПоказанияСчетчикаВПрошломЦикле);
Кракозябрам взяться не от куда. Допустим счетчик переполнился и мы имеет такие значения для расчета дельты:
ПоказанияСчетчикаВПрошломЦикле (Тип WORD) — 65500
ПоказанияСчетчикаВЭтомЦикле (Тип WORD) — 100
Посчитаем дельту, учитывая что оба значения типа WORD:
100 - 65500 = 100 + (0 - 65500 - 35) + 35 = 100 + (0 - 65535) + 35 = 100 + 1 + 35 = 136
т.е. 36 импульсов вызвали переполнение счетчика, и еще 100 сверху.
Пруф:
2021-09-23_10-40-30.png
В этом смысле контролировать ничего не нужно. Разве что следить ,чтобы не было аномально больших скачков, вызванных какой-нибудь помехой, например.
Александр Андреевич Симонов
Инженер по продуктам «ПЛК, модули и OwenCloud»
Не работаю в ОВЕН с 01.07.22
По всем вопросам обращайтесь на почту: support@owen.ru
Спасибо большое!
Кракозябры пропали. В исходном проекте показания счетчика WORD сразу использовались для расчета с переменными REAL плюс домножение на масштабный коэффициент. Вынес расчет дельты между циклами в отдельную строчку где все промежуточные переменные перевел на WORD. А в оконном фильтре где завожу результат добавил WORD_TO_REAL и все стало красиво.
Просто странно - на старом ПЛК 160 счетчик сам сбрасывался. "Не было ни единого разрыва!"(с) ))))
Ничего странного. В старом ПЛК использовался программный счётчик с максимальной частотой 3-10кГц. А в новом отдельный сопроцессор жесткого реального времени с частотой обработки сигналов до 500кГц. В первом случаем сброс успевал осуществляться за те 100 мкс, а сейчас за 1 мкс не успеет - вот и не сбрасывается
Тролль-наседка, добрый, нежный и ласковый
Немного изменили логику работы счетчика, видимо.
Не помню уже как раньше было Давно уже не работал с ПЛК в старом исполнении
P.S. В актуальной версии руководства по программированию работа описана именно так, как обсуждали выше.
Александр Андреевич Симонов
Инженер по продуктам «ПЛК, модули и OwenCloud»
Не работаю в ОВЕН с 01.07.22
По всем вопросам обращайтесь на почту: support@owen.ru
Вот - это то что я хотел понять! Спасибо большое!
У нас большой проект для серийного изделия давно написанный на аутсорсе под старый ПЛК 160. Теперь его самостоятельно портируем на ПЛК [M02], все сделали согласно "Инструкции по переносу". В итоге не заработали только счетчики. И библиотека SysComLib. ComService работает без проблем.
ОФФТОП:
SysComOpen не открывает порт RS-232. Открываем порт ComServiсe-ом. Но почему-то SysComWrite и SysComRead работают нормально по Port_Handle получаемым библиотекой ComService. Мы бы заменили полностью, но у нас особый протокол - не ModBus для порта RS-232. Структура формируется побайтно. Существует ли альтернатива SysLibCom?
ComServiсe это надстройка над SysComLib для открытия/закрытия порта, можете открыть эту библиотеку и так же портировать, то что считаете необходимым из неё, либо пользоваться совместно и SysComLib и ComService
Альтернативой является UNM.lib
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран