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

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

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

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

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

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

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

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

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

Цитата:

---

Сообщение от Алексей Дмитриев

Реального цикла вместе со вводом/выводом меньше 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 на ПЛК - круто! :)

Цитата:

---

Сообщение от Вова

SPI на ПЛК - круто! :)

---

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

P.S.

Цитата:

---

Сообщение от Вова

Железяка должна быть такой: ты нажал кнопку - и она работает

---

Это про электродетонатор?

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

Цитата:

---

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

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

---

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

Цитата:

---

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

P.S. Это про электродетонатор?

---

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

Цитата:

---

Сообщение от Вова

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

---

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

Цитата:

---

Сообщение от Вова

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

---

Я понял - юмор у меня такой.

Цитата:

---

Сообщение от Вова

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

---

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

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

Цитата:

---

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

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

---

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

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