Перепрошивка на версию 2.10.9 для работы с быстрыми выходами

Добрый день, уважаемые форумчане.

На объекте необходимо работать с быстрыми выходами. Закупленный и смонтированный контроллер ПЛК110-32 (старой модификации) имеет прошивку 2.14.0. На форуме нашел информацию о том, что для корректной работы с быстрыми выходами необходима прошивка 2.10.9 (уже пытались работать на 2.14.0 - не работает). Отсюда вопросы.
1. В архиве прошивок на сайте нашел только программу прошивки, при использовании которой необходимо снимать верхнюю крышку и переставлять перемычку. Нет ли возможности перепрошиться с помощью команды UpdateCore, т.е. так чтобы не нужно было снимать верхнюю крышку?
2. Программа из архива прошивок, при запуске сообщает, что необходимо отсоединить все провода от контроллера. Это сообщается, чтобы пользователю было легче снимать крышку или при перепрошивке недопустимо, чтобы на дискретные входы приходили сигналы?
3. Имеем только кабель КС2. Можно ли с помощью него осуществить прошивку? Или обязательно нужен кабель КС1?

Цитата:

---

Сообщение от Спорягин Кирилл

На объекте необходимо работать с быстрыми выходами.

---

Если не секрет, что за объект, требующий работы с быстрыми выходами ?

Объект, где нужно управлять шаговыми двигателями.

Вопросы актуальны!

Цитата:

---

Сообщение от Спорягин Кирилл

Объект, где нужно управлять шаговыми двигателями.

Вопросы актуальны!

---

А какие конкретно драйвера ШД и ШД используете ?

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

Попробуйте перепрошиться по этому бинарному файлу. Крышку снимать не нужно. Кабель в этом случае только КС1

Цитата:

---

Сообщение от Спорягин Кирилл

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

---

Самое интересное впереди, когда начнете управлять ШД. У меня ШД удалось закрутить на частоте не выше 1700 Гц и еще пришлось дробить шаг на 2.

Цитата:

---

Сообщение от Евгений Дударев

Попробуйте перепрошиться по этому бинарному файлу. Крышку снимать не нужно. Кабель в этом случае только КС1

---

Евгений, добрый вечер.
Попытка прошиться бинарным файлом через Ethernet привела к неудаче. Симптомы были похожие на указанные в этой теме. А именно, после перепрошивки не устанавливалась связь, светодиоды "Работа" и "Питание" горели. Светодиод "Работа" гас на момент нажатия кнопки сброс.
В итоге пришлось раздобыть кабель КС1 и с помощью программы перепрошивки (с сайта) все прекрасно перепрошилось на версию 2.10.9.

Теперь у меня появился другой вопрос.

В основной программе, я добавил следующий код:

Код:

---

var
        PRGTime  :        DWORD;
        SysTime1 :        SysTime64;
        SysTime2 :        SysTime64;
        dbCurTime:        CurTime;
        dbStat  :        STATISTICS_INT;
end_var


dbCurTime(SystemTime:= SysTime1);

PRG_Timer();

dbCurTime(SystemTime:= SysTime2);
PRGTime := SysTime2.ulLow - SysTime1.ulLow;
dbStat(IN := DWORD_TO_INT(PRGTime));

---

С помощью данного кода я измеряю минимальное, максимальное и среднее время в микросекундах выполнения программы PRG_Timer.
В этой программе собственно и содержится тот код, который я собираюсь выполнять по высокочастотному таймеру.
Измерения показали следующие значения:
Минимальное время - 160 мкс;
Максимальное время - 520 мкс;
Среднее время - 212 мкс.

Вопросы:
1. Почему период выполнения так разница, хотя программа выполняется "пустая", т.е. все время ходит по одним и тем же логическим ветвям?
2. Какой период можно задать при таких значениях времени выполнения для высокочастотного таймера?
3. Я задавал период вызова по таймеру - 400 мкс. И программа в ПЛК работала (еще не проверял на объекте, но сам контроллер в стоп не уходил). Что происходит, если программа еще не успела выполнится, а уже по времени необходимо вызывать ее снова? Она просто не выполняет те операторы, которые не были выполнены к моменту нового вызова?

Конкретизирую свой вопрос. Думаю, что точный ответ могут дать только системные программисты ОВЕНа. Надеюсь они заглянут!

Что происходит на прошивке 2.10.9, если программа вызываемая по прерыванию высокочастотного таймера еще не успела выполнится, а уже по времени необходимо вызывать ее снова?
ОС просто не выполняет те операторы, которые не были выполнены к моменту нового вызова или она ведет себя по другому?

Вопрос актуален и встал еще более остро! Техподдержка ОВЕНа ответьте!

Сегодня на объекте попробовал изменять время вызова высокочастотного таймера в широком диапазоне.
Результаты удивили.
При времени вызова 20, 40, 60 - процесс затыкался, контроллер перезагружался.
При времени вызова 80 работал. Из этого вопрос.
Как он работал со временем вызова 80 мкс, если по измерениям, проведенным мною (по методу изложенному в посте 9), минимальное время выполнения моего кода 160 мкс?

В основном цикле программу, вызываемую по прерыванию высокочастотного таймера, вызывать бессмысленно, и уж тем более измерять время ее выполнения, вызывая в основном цикле.
Если хотите посмотреть действительное время исполнения программы по прерыванию, то считывайте системное время непосредственно внутри самой программы, вызываемой по прерыванию.
Если время исполнения алгоритма внутри программы по прерыванию превысит 20мкс, должен сработать сторожевой таймер.

Цитата:

---

Сообщение от Спорягин Кирилл

Что происходит, если программа еще не успела выполнится, а уже по времени необходимо вызывать ее снова? Она просто не выполняет те операторы, которые не были выполнены к моменту нового вызова?

---

Т.к. сторожевой таймер будет срабатывать при превышении 20 мкс для программы, вызываемой по прерыванию, то ситуация, которую Вы описываете невозможна.

Цитата:

---

Сообщение от Гарчев Евгений

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

---

В основном цикле я ее вызываю только для того, чтобы измерить время. Почему-то когда ФБ CurTime я вызывал внутри самой программы, а программу вызвал по прерываниям высокочастотного таймера, то время выполнения было равно 0. Я предположил, что в высокочастотном таймере CurTime не работает.

А вот почему измерять время выполнения в основном цикле бессмысленно прошу пояснить подробнее.

Цитата:

---

Сообщение от Гарчев Евгений

Если хотите посмотреть действительное время исполнения программы по прерыванию, то считывайте системное время непосредственно внутри самой программы, вызываемой по прерыванию.

---

Как пояснил выше, почему-то это не работало. Возможно я где-то ошибся. Уточните, пожалуйста, ФБ CurTime должен работать в программе вызываемой по высокочастотному таймеру.

Цитата:

---

Сообщение от Гарчев Евгений

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

---

Не понимаю, почему Вы взяли величину 20 мкс? Время вызова такое, какое объявляется в функции SetIRQ. Можно ли говорить о том, что если при 20, 40 и 60 мкс, моя программа не работает, а при 80 работает, то значит время выполнения моего кода меньше 80, но больше 60? И если это так, то поясните, все же почему измерения в основной программе дают другие значения.

Возможно, на старых ПЛК110 есть проблемы с расчетом системного времени в программе, вызываемой по прерыванию вчт, на новых ПЛК110 [М02] этот функционал работает корректно, но в любом случае программа по прерыванию не может выполняться дольше 20 мкс (иначе сработает сторожевой таймер) - это касается и старых и новых ПЛК110. При этом не важно с какой периодичностью вызывать программу по прерыванию (через SetIRQ), сторожевой таймер сработает при превышении 20 мкс, при любой периодичности вызова.

Цитата:

---

Сообщение от Гарчев Евгений

но в любом случае программа по прерыванию не может выполняться дольше 20 мкс (иначе сработает сторожевой таймер) - это касается и старых и новых ПЛК110. При этом не важно с какой периодичностью вызывать программу по прерыванию (через SetIRQ), сторожевой таймер сработает при превышении 20 мкс, при любой периодичности вызова.

---

Если Вы правы, то это серьезно расходится с моими представлениями о том, как работает ВЧТ.
Но тогда не понятно, почему при вызове раз в 20, 40 и 60 мкс программа затыкается, а при вызове 80 мкс и более работает?

И все же хотел бы получить ответ на вопрос, почему измерения моего куска кода дают минимальную оценку времени выполнения в 160 мкс, а исходя из Вашего ответа, получается, что код мой выполняется менее 20 мкс. Куда уходят 140 мкс при выполнении в основной программе?

П.С. Могу выложить проект, если это необходимо.

Цитата:

---

Сообщение от Спорягин Кирилл

Если Вы правы, то это серьезно расходится с моими представлениями о том, как работает ВЧТ.
Но тогда не понятно, почему при вызове раз в 20, 40 и 60 мкс программа затыкается, а при вызове 80 мкс и более работает?

---

На сколько я помню, как раз на прошивке 2.14.0 прерывания не работали и контроллер перезагружался при периоде вызова ниже 80 мкс. На 2.10.9 можно вызывать программу по прерыванию с периодом менее 80 мкс, но наиболее ровные фронты выходных сигналов получались при периоде вызова программы не менее 80 мкс.

Цитата:

---

Сообщение от Спорягин Кирилл

Куда уходят 140 мкс при выполнении в основной программе?

---

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

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

Кстати, для написания тела быстрого таймера рекомендую использовать IL, код значительно быстрее аналога на ST

Цитата:

---

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

Не совсем понятна конечная цель ваших экспериментов...

---

Изначально, цель экспериментов была в том, чтобы оценив время выполнения кода, понять с какой частотой можно вызывать ВЧТ. После комментария Евгения Гарчева, все только запуталось. Я все же думаю, что он не прав и программа в ВЧТ может выполняться больше 20 мкс, но не может выполняться дольше чем, частота вызова ВЧТ. Т.е. если я вызываю его с частотой 80 мкс, то время выполнения кода, исполняемого по ВЧТ, должно быть меньше чем 80 мкс.

Цитата:

---

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

программа в ПЛК не захватывает процессор в монопольный режим, там крутиться множество всякой фоновой мишуры

---

В целом это мне было понятно. Именно так я трактовал результаты эксперимента (см. пост 9). А именно, когда на время выполнения не попало (или попало мало) фоновой мишуры, мы имеем минимальное время выполнения, т.е. 160 мкс. Если же попало много фоновой мишуры, то имеем время выполнения до 500 мкс. В этом разразе заявление Евгения кажется еще более неправдоподобным, потому как получается, что мой код занимает менее 20 мкс. Что же тогда фоновая мишура от 140 до 480 мкс?

Цитата:

---

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

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

---

Модуль статистики дает оценку всей программы, я же выполняю в ВЧТ только часть.

--------------------------

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

Попробовал исполнить свой код (прикрепляю) на ПЛК110 М02.
Результаты следующие. Вызов функции CurTime в ВЧТ работает.
Время выполнения программы в ВЧТ получилось примерно 5-6 мкс. Иногда время получается отрицательное (см. Вложение 25186)!

Если в М02 код исполняется 5-6 мкс, то по моим оценкам, код в ПЛК110 старой модификации будет выполняться 75-90 мкс (в 15 раз медленнее). Явно дольше чем 20 мкс.

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

В качестве эксперимента для определения реакции ПЛК на время цикла программы прерывания сделайте в программе прерывания цикл for, в качестве верхнего порога цикла for сделайте переменную, изменяя ее значение из вне (из основного цикла, например), тем самым изменяя время цикла прерывания. Посмотрите реакцию ПЛК на разное время цикла прерывания при разной периодичности вызова прерывания.
Результаты такого эксперимента, мне кажется, должны внести ясность в работу прерываний.

Цитата:

---

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

это не время отрицательное, это неаккуратное отношение к типам переменных )))

---

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

Цитата:

---

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

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

---

Вообще, я код изначально писал, так чтобы как можно меньше его было в программе ВЧТ. Я анализировал свой код на предмет сокращения. Много сократить не удастся мне кажется. Но вопрос в другом. Если понимать сколько сократил, т.е. сколько времени выиграл, тогда это имеет смысл делать. Но пока не понятно, как измерить это время в старой модификации ПЛК110.

Цитата:

---

Сообщение от Гарчев Евгений

В качестве эксперимента для определения реакции ПЛК на время цикла программы прерывания сделайте в программе прерывания цикл for, в качестве верхнего порога цикла for сделайте переменную, изменяя ее значение из вне (из основного цикла, например), тем самым изменяя время цикла прерывания. Посмотрите реакцию ПЛК на разное время цикла прерывания при разной периодичности вызова прерывания.
Результаты такого эксперимента, мне кажется, должны внести ясность в работу прерываний.

---

Спасибо за совет. Да, реакцию ПЛК можно изучить. Попробую. Но как все же измерить время работы программы в ВЧТ в старой модификации?

Пока суд да дело, установка уже успешно работает.
Время вызова ВЧТ - 200мкс, т.е. частота импульсов 2,5 кГц.

Но все же на будущее хотелось бы получить ответы.

Спасибо Вольду за наводку по поводу деления шага. Когда время хода на загрузке и выгрузке разнилось, сразу полезли в драйвер шаговика, поделили шаг (прибавили мощи), что привело к отсутствию "проскальзываний" на выгрузке и время на загрузке и выгрузке стало равным.