Связь времени опроса порта и периодом цикла PLC

[Herzog]

PLC-100 работает в многоканальной системе, сводя выходные сигналы всех каналов через мультиплексор на один АЦП споследовательным выходом MCP3201.
Обслуживание АЦП идет согласно описанию на него: в программе PLC большой case, где в каждом состоянии выcтавляю сигнал чип-селект, начинаю дергать тактовый сигнал и на каждый такт читаю с ножки порта однобитовое значение, которые складываются в двоичное число.
Все стандартно.

В чем проблема?
Программа опроса работает как задача в цикле с периодом 2мс. Через каждые 2 мс меняются состояния входных сигналов и, начиная с четвертого тактового импульса, читаются значения выхода АЦП.
Все строго по pdf-у на АЦП. Осциллом вижу правильную картинку на ножках plc.
Есть еще две задачи, но они работают не циклично по системным событиям пропадания/появления питания для записи/чтения переменных их ОЗУ в Retain.

Но! при цикле 2 мс значения порта читаются с ошибкой, хаотичной во времени. Если входной сигнал АЦП для отладки я принудительно выставляю так, чтобы на его выходе шли только единицы (вижу это осциллом), в PLC я читаю не единицы, а случайную последовательность нулей и единиц.
Т.е значение ножки порта читается неправильно. Или - не успевает читаться.
Фильтрацию отключил.
При увеличении цикла до 10...15 мс ошибочные нули почти все пропадают - идет, как и должна быть, серия только единиц. Но мне такой медленный цикл опроса не подходит с учетом затрат времени на многоканальность.

Получается, что опрос ножек порта идет не в каждом цикле - если цикл короткий. Со своим периодом. Похоже, что процесс опроса ножек порта и цикл не связаны?

1. Как это может быть?
2. Что делать?

С уважением,
Herzog

[Алексей Дмитриев]

Реального цикла вместе со вводом/выводом меньше 10 мс вы не получите ни на одном ПЛК, не парьтесь! Опрос порта и цикл выполнения, связаны, так как идут последовательно и циклически - сначала опрос порта ввода, запись значений в ОЗУ, затем выполнение программы! (или наоборот, что непринципиально). Порт программой читается не напрямую - это общеизвестный факт - читайте мануалы!

[Herzog]

Проблему решил сам. Но мой опыт может оказаться полезным и другим.
Итак...


Реального цикла вместе со вводом/выводом меньше 10 мс вы не получите ни на одном ПЛК, не парьтесь!Без проблем получаю 2мс.

Опрос порта и цикл выполнения, связаны, так как идут последовательно и циклически - сначала опрос порта ввода, запись значений в ОЗУ, затем выполнение программы! (или наоборот, что непринципиально)Как оказалось - именно это и принципиально.

Вот кусок исправленного и безошибочного кода, выдранного из процедуры последовательного ввода битов АЦП:


case gTask of
...
cADC1 :
(* ----------- pins out: --------------- *)
CLK := ON; (* clock up *)

gTask := cADC11;

cADC11 :
(* ----------- pin in: --------------- *)
IF (i > 2) AND ( i < 11 ) THEN
AdcVal := AdcVal * 2;
IF Current = 0 THEN (* inversed *)
AdcVal := AdcVal + 1; (* count serial *)
END_IF
END_IF

(* ----------- pins out: --------------- *)
CLK := OFF; (* clock off *)

(* ----------- check end of clocking --------------- *)
i := i + 1;
IF i > 11 THEN
gTask := cTaskRecord3;
ELSE
gTask := cADC1;
END_IF

cTaskRecord3 :
...

Здесь gTask - переменная состояния в case.
В состоянии cADC1 формируется передний фронт такта АЦП.
В состоянии cADC11 в начале цикла читается текущий бит АЦП (Current), по результата которого формируется значение AdcVal. В конце этого цикла меняется фронт такта на спадающий, на что микросхема АЦП реагирует выдачей очередного бита.

Моя ошибка, из-за которой и возникла эта тема была в том, что я раньше полагал работу так:
1. поднял фронт тактирующего сигнала и прочитал значение,
2. в следующем цикле сбросил сигнал такта и АЦП выдал следующее значение.
3. возврат к п1
Но в этом случае, поскольку чтение входных сигналов происходит в начале цикла, а выдача сигналов в конце, между спадом тактирующего сигнала и изменением бита практически нет задержки - окончание предыдущего цикла (спад такта) и начало следующего цикла (чтение бита АЦП) разделяет несколько микросекунд.
АЦП не успевал формировать сигнал и я читал с ошибками.

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

P.S. Обращаюсь к Модераторам.
Если возможно, хотелось бы, чтобы эта тема была в каком-то разделе, где помогла бы другим не вляпаться в такую же трудно отслеживаемую неприятность.

С уважением,
Herzog

[Вова]

Принципиальной важно оказалось то, что чтение портов в начале цикла, а запись в порт - в конце!
Не помню точно где, или в документации на ПЛК, или на CoDeSys, но это явно указано. У меня тоже программа написана на st с помощью case, так вот, самые важные датчики обрабатываются в конце каждого цикла, чтобы на выходах установились правильные значения.
ЗЫ SPI на ПЛК - круто! :)

[Herzog]

SPI на ПЛК - круто! :)Не круто, а нормально. Только медленно очень получается на ПЛК-100.
Мне ведь сорок каналов опрашивать - за четыре секунды время опроса уходит...

P.S.
Железяка должна быть такой: ты нажал кнопку - и она работаетЭто про электродетонатор?

С уважением,
Herzog

[Вова]

Не круто, а нормально. Только медленно очень получается на ПЛК-100.
Мне ведь сорок каналов опрашивать - за четыре секунды время опроса уходит...

Я без сарказма.

P.S. Это про электродетонатор?
Это моя подпись, конкретно к вашему посту не относится. Имеется в виду, что любая электроника должна просто работать, когда это нужно, безо всяких глюков.

[Herzog]

Я без сарказма.И я без сарказма.
Применить стандартный протокол в стандартных условиях - в этом нет крутизны.

Это моя подпись, конкретно к вашему посту не относится.Я понял - юмор у меня такой.

Имеется в виду, что любая электроника должна просто работать, когда это нужно, безо всяких глюков.Так в жизни не бывает.
Закон Мэрфи... Если схема сразу заработала правильно, значит Вы просто не заметили ошибку.

С уважением,
Herzog

[Вова]

Если схема сразу заработала правильно, значит Вы просто не заметили ошибку.
Ни одна уважающая себя программа не начинает работать сразу :D
И ещё, с баша
"Написал программу, откомпилировал, запустилась, всё работает, как надо, никаких глюков...
Не поверил, 2 часа ошибку в коде искал!"

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