Fast Counter - баг в овеновской документации или в моей голове?

Пытался разобраться с тем как работать с быстрыми счетчиками...
В овеновском рук-ве писано:
Модуль «Высокочастотный Счетчик» (Fast Counter) является модулем, заме-щающим модуль быстрых дискретных входов.
Счетчик считает количество импульсов, пришедших на быстрый дискретный вход за один цикл ПЛК. По завершению каждого цикла ПЛК значение в счетчике об-нуляется. Подсчет импульсов осуществляется по переднему (возрастающему) фронту импульса. Таким образом, для использования и обработки значения данного канала, необходимо считывать его каждый раз в начале цикла пользовательской программы. Например, ввести в программу дополнительную переменную, и в начале цикла передавать в эту переменную значение переменной, привязанной к счетчику.

Если счетчик обнуляется в конце цикла, то как же присваивать дополнительной переменной значение обнуленного счетчика в начале нового цикла ПЛК? Может все таки значение счетчика нужно считывать в конце цикла?

И чем занимается счетчик во время выполнения процессором сервисных функций после завершения цикла ПЛК? Ведь в это время также могут приходить импульсы.

Здравствуйте Владимир
В документации написано всё правильно да действительно так оно и работает!
Просто в программе необходимо к итоговой сумме счетчика (объявленного в программе) прибавлять значение из ПЛК-конфигурации В КАЖДОМ ЦИКЛЕ!!!

Например:
dwCounterImpuls1:=dwCounterImpuls1+iwdCounter1;

где dwCounterImpuls - это переменная объявленная в программе и есть итоговое значение счетчика импульсов.
iwdCounter1 - это переменная объявленная в ПЛК-конфигурации (Ваш быстрый дискретный вход).

Если есть возможность поиграйтесь на реальном железе. Так гораздо быстрее получится разобраться.

А в то время когда цикл окончен и к примеру выполняются сервисные функции или минимальное время цикла велико и контроллер просто стоит.В счетчике накапливаются данные для считывания в новом цикле.

Цитата:

---

Сообщение от Gans

Просто в программе необходимо к итоговой сумме счетчика (объявленного в программе) прибавлять значение из ПЛК-конфигурации В КАЖДОМ ЦИКЛЕ!!!

---

Да, это понятно, что нужно суммировать значение выхода счетчика в каждом цикле. Просто в док-ции пишется, что это нужно делать в начале цикла. (То есть в начале программы). А я считаю, что в конце программы. Так как за время выполнения программы счетчик может насчитать импульсы, которые обнулятся в конце цикла и будут не учтены.

Цитата:

---

Сообщение от vladimir_prg

Да, это понятно, что нужно суммировать значение выхода счетчика в каждом цикле. Просто в док-ции пишется, что это нужно делать в начале цикла. (То есть в начале программы). А я считаю, что в конце программы. Так как за время выполнения программы счетчик может насчитать импульсы, которые обнулятся в конце цикла и будут не учтены.

---

В документации наверно не совсем корректно написано. Данные счетчика из ПЛК-конфигурации перед началом цикла передаются в программу и обнуляются, а если в ходе выполнения цикла придут несколько импульсов Вы их получите в начале следующего цикла :-) В ходе цикла данные из ПЛК-конфигурации НЕ СЧИТЫВАЮТСЯ!!!

Выглядит это примерно так:
1. Данные собираются ПЛК-конфигурацией.
2. Передаются в программу.
3. Начинает выполнятся один цикл программы.
4. По окончанию цикла программы все расчетные значения передаются в ПЛК-конфигурацию.
6. Далее возвращаемся в пункт №1.

P. S. Начинается новый цикл программы даже если ПЛК-конфигурация не успела собрать ВСЕ ДАННЫЕ! Опрос датчиков температуры можно сделать и раз в пять секунд, а программа в ПЛК должна работать по чаще :-)

Цитата:

---

Сообщение от capzap

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

---

Во-первых, я обсуждаю официальную документацию, которая является эталоном описания алгоритма работы контроллера. Так как по идее исходит от того кто ЗНАЕТ, как работает контроллер, а не ДОГАДЫВАЕТСЯ.

Во-вторых, lara197a указал, про накопление значений после того как цикл закончен во время простоя и выполнение сервисных функций, (выполнение сервисных функций не входит в цикл контроллера).

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

Не совсем хорошо если ваши расчеты будут врать на несколько импульсов, только из-за того, что в документации не совсем точно описан алгоритм работы контроллера.

Про что это все? Псевдоаппаратный счетчик у овна считает всегда и никуда не сбрасывается! Мало того - его сбросить невозможно даже если это нужно! Читайте его где хотите и когда хотите. Частота входных импульсов должна быть не выше 10 кГц, хотя это толком и не работает, реально меньше 5 кГц.

Подскажите, пожалуйста, - у меня счетчик (Fast Counter) тоже не сбрасывается после обращения к переменной из Конфигурации. Ни в начале ни в конце цикла - просто копит до переполнения. Кто-нибудь решил эту проблему?

............

Цитата:

---

Сообщение от Иван Иванович С

Подскажите, пожалуйста, - у меня счетчик (Fast Counter) тоже не сбрасывается после обращения к переменной из Конфигурации. Ни в начале ни в конце цикла - просто копит до переполнения. Кто-нибудь решил эту проблему?

---

На сколько я помню сброс не предусмотрен.
Предполагается, что в коде проекта вы заводите свою переменную, и сбрасываете туда дельту показаний счетчика, между циклами ПЛК.

Цитата:

---

На сколько я помню сброс не предусмотрен.
Предполагается, что в коде проекта вы заводите свою переменную, и сбрасываете туда дельту показаний счетчика, между циклами ПЛК.

---

На ПЛК 160 счетчик сбрасывался сам при чтении переменной привязанной в конфигураторе, а теперь на ПЛК 160 [M02] пришлось сделать костыль с разностью значений между циклами. И при переполнении счетчика требуется еще контролировать чтобы кракозябра не получилась.

.............

Просто должно работать и так с аппаратным сбросом счетчика. Или не должно? Почему тогда это не появилось в описании переноса прошивки с ПЛК 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 сверху.

Пруф:
Вложение 57137

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

Спасибо большое!
Кракозябры пропали. В исходном проекте показания счетчика WORD сразу использовались для расчета с переменными REAL плюс домножение на масштабный коэффициент. Вынес расчет дельты между циклами в отдельную строчку где все промежуточные переменные перевел на WORD. А в оконном фильтре где завожу результат добавил WORD_TO_REAL и все стало красиво.

Просто странно - на старом ПЛК 160 счетчик сам сбрасывался. "Не было ни единого разрыва!"(с) ))))

Цитата:

---

Сообщение от Иван Иванович С

Спасибо большое!
Кракозябры пропали. В исходном проекте показания счетчика WORD сразу использовались для расчета с переменными REAL плюс домножение на масштабный коэффициент. Вынес расчет дельты между циклами в отдельную строчку где все промежуточные переменные перевел на WORD. А в оконном фильтре где завожу результат добавил WORD_TO_REAL и все стало красиво.

Просто странно - на старом ПЛК 160 счетчик сам сбрасывался. "Не было ни единого разрыва!"(с) ))))

---

Ничего странного. В старом ПЛК использовался программный счётчик с максимальной частотой 3-10кГц. А в новом отдельный сопроцессор жесткого реального времени с частотой обработки сигналов до 500кГц. В первом случаем сброс успевал осуществляться за те 100 мкс, а сейчас за 1 мкс не успеет - вот и не сбрасывается

Цитата:

---

Сообщение от Иван Иванович С

Просто странно - на старом ПЛК 160 счетчик сам сбрасывался. "Не было ни единого разрыва!"(с) ))))

---

Немного изменили логику работы счетчика, видимо.
Не помню уже как раньше было :confused: Давно уже не работал с ПЛК в старом исполнении :)

P.S. В актуальной версии руководства по программированию работа описана именно так, как обсуждали выше.

Цитата:

---

Сообщение от Филоненко Владислав

Ничего странного. В старом ПЛК использовался программный счётчик с максимальной частотой 3-10кГц. А в новом отдельный сопроцессор жесткого реального времени с частотой обработки сигналов до 500кГц. В первом случаем сброс успевал осуществляться за те 100 мкс, а сейчас за 1 мкс не успеет - вот и не сбрасывается

---

Вот - это то что я хотел понять! Спасибо большое!

У нас большой проект для серийного изделия давно написанный на аутсорсе под старый ПЛК 160. Теперь его самостоятельно портируем на ПЛК [M02], все сделали согласно "Инструкции по переносу". В итоге не заработали только счетчики. И библиотека SysComLib. ComService работает без проблем.

ОФФТОП:
SysComOpen не открывает порт RS-232. Открываем порт ComServiсe-ом. Но почему-то SysComWrite и SysComRead работают нормально по Port_Handle получаемым библиотекой ComService. Мы бы заменили полностью, но у нас особый протокол - не ModBus для порта RS-232. Структура формируется побайтно. Существует ли альтернатива SysLibCom?

Цитата:

---

Сообщение от Иван Иванович С

Вот - это то что я хотел понять! Спасибо большое!

У нас большой проект для серийного изделия давно написанный на аутсорсе под старый ПЛК 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