В рабочей ветке блок таймера вообще не вызывается! С чего вдруг его выход должен меняться?

Надо добавить красную строчку:

PROGRAM proba
VAR
   Tmr_1: TP;
   i: INT;
   y: TIME;
END_VAR

IF Tmr_1.IN =FALSE THEN
     Tmr_1(IN:=TRUE, PT:=T#5s); (*Вызов таймера и запуск = OK*)
END_IF;

IF Tmr_1.Q THEN  (* Смотрим на выход, он естественно не меняется, поскольку вызова таймера в этой ветке нету !*)

     Tmr_1;    (* Вызов экз. функ. блока *)
     i:=i+1;
     y:=Tmr_1.ET;
END_IF;

IF Tmr_1.Q = FALSE THEN
     Tmr_1(IN:=FALSE);     (*Вызов таймера и останов = OK*)
END_IF;

Подробно о работе с временем, датами и таймерами МЭК http://www.prolog-plc.ru/docs/TimeExperience.pdf - см. тут.

Перед обращением к полю ЕТ надо вызвать функцию:

IF Tmr_1.Q THEN
     i:=i+1;

     Tmr_1(IN:=TRUE);
     y:=Tmr_1.ET;
END_IF;

P.S. Пока писал, оказывается, уже ответили

Причина ясна - сразу после включения таймер оказывается недоступен программному циклу, так-как условие IF Tmr_1.IN = FALSE ... после того как стало TRUE не пускает программу к таймеру - она его обходит ! Надо вынести таймер из тела условия, чтобы он всегда был на виду, не важно в каком он состоянии.

Минимально покушаясь на авторство, начальный кусок можно переделать так :

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

b: BOOL := FALSE;   (* Добавляем булеву переменную *)

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

IF NOT(b) THEN
     b := TRUE;
END_IF

Tmr_1(IN := b, PT := T#5s); (* Выносим таймер наружу *)
...
...
------------- И все затикает !

На этом можно было бы и закончить, но но здесь затронута тема более широкая чем отдельный случай. Таймер - это ФУНКЦИОНАЛЬНЫЙ БЛОК, то есть вещь специфичная для CoDeSys (и подобных систем). Это не функция в классическом понимании, привычная для обычных языков программирования. Функциональный блок (FB) должен вызываться В КАЖДОМ ЦИКЛЕ, чтобы внутри у него все правильно работало. Вообще говоря, FB используются в графическом редакторе CFC, и там они само-собой всегда вызываются программным циклом, не зависимо в каком состоянии эти FB находятся. FB , как кубики разбросанные на поле графического редактора, можно представить в виде фрагментов текста, следующих в порядке расположения FB. С такой точки зрения хорошо видно, что обработка проходит все места насквозь, не пропустив ни одного FB.
Я сделал эту выкладку потому, что если кто решил заняться CoDeSys, то с вопросами по FB еще много раз придется столкнуться(и я в том числе).

С уважением, SAN.

Для Mixer:

Мне кажется, здесь всё усложнено и запутано ("... это не фунция...", "должен вызываться, чтобы все правильно работало" и прочее). Напишите первой строкой программы вызов функции:

Tmr_1;

остальные обращения к ней можно убрать. Получится, что таймер вызывается каждый раз при вызове программного блока (если вам нужно, чтобы таймер всё время работал). Главная идея такая. Система следит только за обновлением системного таймера (суммирует импульсы от кварцевого генератора), выходные поля вашего таймера будут обновлены после явного вызова функции (в данном случае TP).

Доп. мысль:
в языке SFC в CoDeSys есть атрибуты шага, особенно интересно: минимальное время активности. Тут можно указывать константы, переменные и даже элементы массивов. Например: делаем переменные (типа TIME), задаем в них нужные длительности. Далее в атрибутах шагов SFC, где задается мин. время активности прописываем эти переменные (переходы могут быть разрешены всегда – TRUE). Получаем программу с этапами, нужных длительностей, вообще без всякого программирования.

Технично?

Здраствуйте.

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

Да, технично. Хотя источником времени здесь служит все тот же системный счетчик, в неявном виде. На том же системном счетчике стоят периоды задач и т.д. Таймеры "питаются" также напрямую от Сис.Сч. Вообще говоря, играть можно на всем что тикает. Например, в SP RTE в качестве источника тактов времени можно использовать собственно сам цикл выполнения задачи (если он достаточно короткий), и вообще не прибегать ни к каким таймерам, задержанным условиям SFC и т.п. При этом, правда, наблюдается небольшой Jitter (дрожание длительности - на сильных компах почти не заметен), но в каждом конкретном случае можно решить - пренебрегать этим или нет.
То была одна сторона дела - чисто техническая. С другой стороны - нужно воспользоваться результатами работы этих технических достижений. Пользовательские переменные и функции, которые естественно тактируются программным циклом, должны получать значения "устройств времени" должным образом. Иначе хитрозакрученные технические трюки могут оказаться "вещью в себе".

С уважением, SAN.

Отнюдь

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

Абсолютно верно!

Отсчитывать временные задержки на базе рабочего цикла возможно, но ИМХО делать это есть смысл для очень малых или некритичных к стабильности задержек. (Например, если используем коммутатор сигналов на 1 аналоговый входов и ему надо дать пару мс. после коммутации след. канала и т.п. ) Таймеры практичнее: интервал циклических задач можно менять как угодно, таймеры всегда будут работать правильно.

Ограниченно количеством функц. блоков, что впрочем настраивается. Кстати, иногда специально избегаю стандартных TONов, TOFов, особенно если они вложены в другой функц.блок. Ведь что может получиться: вставил в такой блок пару таймеров, затем в основной программе - сотню блоков (обработка сигналов например), и вот получилось таймеров уже две сотни.  Сравниваю в таких случаях системное время с заранее запомненной переменной типа TIME.

Ко-во не ограничено. Самый первый, используемый в проекте, экземпляр любого ФБ кушает память кода, все следующие только память данных (суммарный объем всех переменных + 4 байта).

Ну а количество функциональных блоков ведь ограничено...

Стандартные таймеры внутри делают абсолютно тоже самое (+ контроль переполнения). Ничего страшного в их большом числе нет.

Действительно на некоторых аппаратных платформах с сегментированной памятью число POU в проекте ограничено.

Надо будет как-нибудь испытать.

Да, видимо так оно и есть. Легко объявляется десяток тысяч таймеров, а каждый по 24 байта, и кол-во POU не увеличивается. Правда, пробовал в симуляторе.

А я всегда почему-то все инстанции причислял к POU. Надо будет кое-что пересмотреть. Век живи, век учись.

А вот лежит у меня книжка "Программируемые контроллеры. Стандартные языки и приемы...", Игорь Викторович Петров. Ваша?

... Бить будете?
 
Сейчас в журнальном варианте печатается еще одна Отладка прикладных ПЛК программ в CoDeSys http://www.prolog-plc.ru/tmpl.php?content=info3.htm - см. тут.

Уж коль скоро тема слегка отклонилась на CoDeSys, то хочется высказать пару слов. В общем CoDeSys, добротно сколоченная вещь, создает впечатление проработанной системы. Мелкие недоделки - не в счет, ведь она еще во всю разрабатывается. Как я заметил, самая сильная часть в CoDeSys - это эффективность исполняемого кода. Кстати, те же таймеры типа TON в версии 2.3.7.2 занимают всего 15 байт ! Старенький Пень-260 тянет 6-ти осную ЧПУ отдыхая - с загрузкой на 10%. Код компактный, быстрый, будто писан на чистом ASM-е. Аналогичные IEC вроде Simulink или новомодная iCon_L выглядят слабже. В редакторах iCon_L много "раскрасок" и "удобств", но не совсем понятно зачем они нужны, например оператору, если после разработки все убирается и в контроллере остается один исполняемый код, а ператор работает в лучшем случае через какую-нибудь HMI или вообще через пульт с четыоьмя лампочками ...
ОДНАКО, вместе с тем, есть в CoDeSys, как я думаю, один серьезный недостаток. Это - невозможность присваивать имена отдельным битам данных. Нельзя, как мы ни ходили кругами, скажем биту X25.2 присвоить псевдоним Lampochka_2, или Klapan_1. Файлы аппаратной онфигурации .CFG решают этот вопрос очень узким частным образом. Возможность присваивать псевдонимы произвольным элементам данных должна быть заложена в самом языке (оно так и есть в большинстве языков).
В переписке прозвучало слово "контроллер", это и побудило меня написать. Дело в том, что в "контроллерном деле" главенствующей единицей является БИТ, он же КОНТАКТ на разъеме. В академическом программировании больше рассматриваются БАЙТЫ, СЛОВА и т.д. Отсутствие именования битов, по моему, не оправдано никакой идеологией. Часто приходится слушать нарекания от промышленных заказчиков, пишущих "релейку" и "булевку" : " .. что за такое, почему нельзя назвать Пускатель22 ... ? ". И они ПРАВЫ ! Такая ундаментальная мелочь отпугивает добрую половину потебителей. А напрасно - ведь здоровская вещь CoDeSys.
Можно ли ожидать, что на эту тему будет что-то сделано или этотго вопроса вообще не рассматривается ?

С уважением, SAN.

Очень заинтересовало, о каком именовании битов отдельных битов идет речь, не могли бы пояснить…

PROGRAM PLC_PRG

VAR

            Pusk1 AT %MX0.1:BOOL;

            Pusk2 AT %MX0.2:BOOL;

            Pusk3 AT %MX0.3:BOOL;

END_VAR

Я понимаю именование битов происходит в вышеизложенном коде? Или вы хотите именовать биты в куче? Любопытно просто

Легко биты именуются, как Dismay показал. В ПЛК поддерживается конфигуратор контроллера, в нем по умолчанию задаются переменные (Out1, Out2 ...) сопоставленные битам входов/выходов.

Если битовый адрес не указан, то под переменную типа BOOL выделяется 1 байт. Это делается не сдуру. Штука в том, что многие микропроцессоры, не имеют специальных машинных команд для работы с битами, приходится использовать несколько машинных команд. Так Пень 200 будет работать с битами медленнее 8 бит Intel  8051 на 22 МГц. Поэтому немного жертвуем памятью и достигаем повышения быстродействия на порядок.

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

Трогать кучу пожалуй не стоит, удобнее да и надежнее работать со статическим локальным сегментом данных.

VAR

            Pusk1 AT %MX0.1:BOOL;

            Pusk2 AT %MX0.2:BOOL;

            Pusk3 AT %MX0.3:BOOL;

END_VAR

Да, именно так сейчас и действуем. Каждый раз, по нескольку раз приходится уточнять с заказчиком размер области данных , количество переменных, их имена (создавать заранее большой сегмент - не оправдывается). Подчас это проблематично, если заказчики далеко. Сами Они не очень-то хотят пользоваться такой систематикой (почему-то ?). Кроме того, постоянно что-то меняется, добавляется весьма в широких пределах, переименовывается. Часто требуется назначать новые имена уже именованным переменным, то-есть двойные и тройные псевдонимы и т.д. Количество частных случаев переходит в качественную необходимость перенести возможность написания пользовательских программ к самому месту её работы, местным программистам-электрикам.

Примерно это я и имел ввиду.

Кстати, в системе команд процессора Pentium имеются аппаратные инструкции работы с битами : BT, BTS, BTR, BTC, BSF, BSR и т.д. Но честно говоря, не знаю - использовали их в компиляторах CoDeSys ?

С уважением, SAN.

Пользователей SP RTE сейчас примерно 1 на 10000 пользователей обычных PLC с CoDeSys. Продукт этот очень интересный, но не дешевый и не массовый.

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

Похоже, что проблема в неком драйвере ввода/вывода SP RTE для которого не сделали конфигуратор переменных?

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

С уважением, SAN.

Насколько я понимаю речь идет вовсе не об именовании битов а о возможности создания алиасов для переменных, честно говоря, сомнительное удобство. Тем паче, что если есть необходимость всегда можно выполнить перепресвоение. Весьма путано излагаете если честно, то складывается впечатление, что 3S просто таки одна из составляющих оси зла всех недостатков проектирования и первичной постановки задачи.

В защиту обвиняемого могу сказать следующее:

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

Очень рекомендую к прочтению мозголомный труд мэтра ООП господина Гради Буча “Объектно-ориентированный анализ и проектирование”  второе издание

Да - Aliases, к которым многие так привыкли. Первоначально переменные объявляются в исходном проекте, который вручается заказчику, а там по месту назначаются желаемые имена, и всё складно ! Почему в этом нужно усматривть источник каких-то ошибок ?! Позвольте, при желании можно всё сломать. Например авторы языка C, я полагаю, никак не виноваты, что в программах написанных на нем совершено уже миллиарды ошибок !
Но поскольку CoDeSys не оснащена Aliases-ами, то при отсутствии самого предмета обсуждения, оное можно и завершить.

А вот причем здесь ООП, если это объекты верхнего уровня, тогда-как Aliases - средства низшего уровня ? Они сосуществуют никак не пересекаясь друг-с-другом ( тот-же перенавороченный C++ с .NET-ом).

Я не противник а сторонник CoDeSys, и даже расхваливаю её. Критические замечания - как раз говорят о заинтересованности в использовании этой системы ( не интересующий предмет не обсуждался бы ). А эффективность исполняемого кода CoDeSys - пока самая высокая из встречавшихся МЭК, даже если сравнивать со старыми "ручными" ассемблернми системами.

Что касается структуры интерфейса данных, то наверное будут попытки сформировать две основные концепции, в соответствии с "типом" заказчиков. Одни, которые радушно встретили среду "нового поколения", и охотно принимают предложенную систему обозначений и именований, позволяя удобно оформить проект в виде закрытого законченного (почти) продукта. Иные, приверженцы "старой школы", желают получить почти полностью открытый проект, собираются доделывать всё сами, но при этом не согласны с системой обозначений и вообще со всякой там ООП ...
Чтож, будем работать ...

При случае постараюсь ознакомиться с рекомендованным трактатом Гради Буча по ООП. Будучи не знакомым с таковым, осмелюсь предположить, что означенный фолеант наверное академического толка. Да есть академическое, последовательное знание, которое как караван - медленно но неотвратимо продвигается. Никто не может замедлить или ускорить его ход. Есть прикладные науки, как "собаки" лающие на тот "караван" (никому не в обиду). А как зачастую могучая, стройная теория бывает далека до своего прикладного воплощения.

С уважением, SAN.

В CoDeSys 2.3 можно использовать:

1) 'Конфигурационные  переменные'  (Variable_Configuration).
В программе, в разных модулях определяются переменные с '*' вместо адреса. Далее в проекте на вкладке Recourses - Variable_Configuration эти переменные расставляются по адресам. Получается централизованное управление назначением переменных.

2) Для прямоадресуемой памяти (M,I,O), на один адрес можно объявлять разные переменные, даже разных типов.

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

4) Можно делать псевдонимы типов данных. Например,  TYPE DAC16: UINT; END_TYPE

Штуки понятные и востребованные.
Если я отдал проект заказчику, он же начал лазить по программе и менять там нечто, то: 1) я снимаю с себя ответственность за проект;  2) он моментально может переименовать глобальным поиском переменные, чем плодить кучу имен, в которых потом можно запутаться.

Кроме того,  если говорить о больших проектах, тут надо использовать единую базу объектов проекта для одновременной многопользовательской работы (инжиниринговый ENI сервер в CoDeSys).

Вопрос не в том чтобы ругать или хвалить. Давайте вместе создадим конкретный пример иллюстрирующий чего не хватает, придумаем как именно ввести такую штуку (с помощью ввода нового ключевого слова?). Технически добавить это в CoDeSys не представляет никакой проблемы, нужно только общепонятно доказать что это благо, а не вред.

Ну это понятно - перечисенные средства являются разными способами использования того что есть. Одни постоянно используютя на практике, особенно разнотипный доступ к одной области памяти, другие реже, а какие и вовсе не применяются. В определенных случаях эти разные способы повышают удобство работы с переменными, но не создают новых средств языка (те же Aliases).

Отношения между разработчиками и заказчиками не так прсты как "продовец-покупатель". И вопрос здесь вовсе не в перекладывании ответственности. Сказать, что мы сделали свою часть работы а остальное мол "ваши проблемы" - такой красивый жест не к месту. Отдел потеряет заказчика, а те найдут подходящего разработчика, или вовсе приобретут готовую систему, что зачастую и делается. Сейчас уже вовсю надвигаются системы подобные CoDeSys, да еще и в комплекте с "железом". Есть к примеру FATEK - полный комплект контроллера с заказными модулями, среда разработки аналогичная CoDeSys - с графическими редакторами, потребителям нравится большой набор готовых функций, связь по Ethernet, Online отладка загрузка программ и все прочие дела. И вполне недорого ! Так-что сделав ставку на CoDeSys, пребывать в спокойствии - не придется.

Реальее и разумнее поступить по другому.  В конкретном случае, некий "Отдел" внедряет системы автоматизации, непосредственным запуском которых занимаются "Службы промэлектроники". Отдел разрабатывает аппаратную часть - контроллер, и к нему системное программное обеспечение, промэлектронщики пишут свою часть ПО, связанную с конкретным оборудованием. В части создания ПО - оба участника находятся в равных ролях. Условное разделение ПО на системную и прикладную части отражает естественный порядок вещей : есть постоянная часть - ядро, которое почти не меняется, и переменная часть, которую гораздо ближе знают программисты-заказчики. Не смотря на условное разделение, и те и другие являются СО-РАЗРАБОТЧИКАМИ общего проекта, и работают то в одной и той-же среде CoDeSys. Так что, улаживать вопросы - это в общих интересах.
А то, что следует выработать некую общую систему объектов, отработанный интерфейс - тут полностью все согласны. Тогда и меньше будет споров, и заказчики свободнее смогут обращаться с переменными, не опасаясь сделать что-то не так.

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

С уважением, SAN.

Дык 20 лет они надвигаются… Контроллеров с МЭК системами программирования море, внешне похожи, внутри очень разные…

Полно готовых контроллеров выпускается и с CoDeSys. Причем некоторые не просто предлагают отдельные модели, а мощнейшие интегрированные комплексы для решения задач в разных областях: ABB, Beckhoff, Wago, Moeller, Wieland  http://www.3s-software.com/index.shtml?ru_referenz - полный список изготовителей ... есть из чего выбрать.

Не совсем понял. Сами разрабатывают железо (ПЛК) с нуля и встраивают в него CoDeSys или компьютер оснащают платами и SP RTE ставят?
Сколько таких устройств уже сделано?

Даже нужно! Почти все новшества CoDeSys в последние лет 5 придуманы пользователями. Только через меня прошло под сотню всяких штук. Технически Aliases добавить несложно, но Вы правы самое сложное сделать это технично, чтобы другие пользователи поняли их необходимость. Сейчас уже все начинающие жалуются, что число возможностей в этой среде программирования больше чем они могут реально освоить. Пожалуйста, прорабатывайте свои предложения по доработке CoDeSys . Как раз 22/23 мая мы проводим http://www.codesys.ru - конференцию по этим проблемам в Смоленске с участием Манфреда Вернера (основатель и директор компании 3S, разработчик CoDeSys). Если хотите сделать доклад, то давайте заявку мне в личку до конца марта.

Хотелось бы увидет что-то вроде сводного списка фирм выпускающих контроллеры под CoDeSys, с краткими техническими данными - частота процессора, объем памяти, разрядность, и главное - уровень цен.

В данное время подходящим вариантом представляется монолитный чип  BECK - он и используется как основа для разработки контроллеров. В нем удобно собрано все вместе : стоит не дорого, имеет уже вшитое ПО, и продается с готовой лицензией. Есть у BECK-а технические и программные недостатки, так-что хотелось бы расширить свой кругозор по рынку чипов с ПО поддерживающем CoDeSys. Однако информация очень разрознена, изобилие пустой требухи - разобраться трудно.

А собственно как выглядит участие в Конференции ? Можно ли, к примеру послать подготовленный материал в адрес какого-либо учреждения, как этот материал должен быть оформлен и т.п.

С уважением, SAN.

Впрочем некий далеко не полный каталог CAA  http://www.automation-alliance.com/index.shtml?aa_products - есть тут . Беда в том, что изготовители редко его пополняют, хватает своей работы

http://www.prolog-plc.ru/3s/conf_06.htm - Так выглядело в прошлом году. Тогда основная тема была – технологии адаптации CoDeSys к железу и пакет SoftMotion. В этом году –  развитие языков МЭК и сетевых и сервисных функций CoDeSys, + http://www.3s-software.com/index.shtml?CoDeSysSafety_e - Safety .

Для участия в конф-и достаточно зарегистрироваться на сайте http://www.codesys.ru/ - www.codesys.ru с 12 марта. Для обсуждений будет время, если хотите выступить с сообщением, то свяжитесь с организаторами. Давайте в личку с этим, а то мы далеко ушли от заданной темы.

IPC чипы BECK штука достаточно популярная. На сегодняшний день используют более 60 компаний в России. Сейчас пытаемся собрать и дать на сайт информацию о применениях, но их потребители все как партизаны, никто не хочет тратить время, дабы описать свое приложение, может быть боятся конкуренции.

Наиболее массовые применения по прошлому году – это замена процессорных модулей в старых, но вполне живых контроллерах (типа Микродат) на больших заводах. Периферия этих контроллеров вполне рабочая и неприхотлива в обслуживании. Меняется проц. дорабатывается ПО, подключается верхний уровень по Ethernet, никакого перемонтажа. Когда контроллеров сотни, это удобно.

Некоторые ссылки есть http://www.prolog-plc.ru/beck/ipc.php?content=links.htm - тут .
Полных аналогов пока нет. Есть встраиваемые одноплатные компьютеры с CoDeSys, есть чипы с разными ОС, но так чтобы в комплекте был генератор МЭК системы исполнения (бесплатный !!!), чтобы так  просто можно было свои полноценные ПЛК делать со встроенным CoDeSys нет.

Кстати, на упомянутой выше конф-и будет нач. отдела маркетинга Beck IPC GmbH Марк Скойтерс. Давайте замечания и пожелания, он постоянно пытается их раздобыть.

Не согласен. Был осенью на выставке HiTechHouse, на семинаре выяснилось, что продаётся либо дешёвый старый вариант, либо ну очень не дешёвый новый (опер. система)

Новый что?

Есть новая серия чипов SC123, SC143. Они дешевле текущей серии SC11-13. Все цены есть на сайте. Реальная проблема с новыми чипами – это корпус BGA, на коленке его не запаять. Можно обратится в компании, специализирующиеся на контрактной сборке, например Fastwel, у них такое оборудование есть. SC13 можно монтировать любым паяльником.

Возможно речь о стартовом комплекте разработчика DK61? В него входит компилятор Paradigm, который стоит 890 Евро. Но 1) он действительно того стоит, 2 комплект это приобретается 1 раз на всю жизнь, поэтому его цена особо никого не пугает.
Если пугает, то есть комплект http://www.beck-ipc.com/ipc/products/category/view/index.asp?cat=2&prod=33075&sp=en - EK61

Из новинок BECK интересны модули http://www.beck-ipc.com/ipc/products/category/index.asp?cat=5&sp=en - радио Ethernet для чипов. Скоро будут чипы под EtherCAT.

BECK - целый микрокомпьютер в одном корпусе, на базе кристалла x186. Есть две группы чипов : 8-ми разрядные со стандартной памятью 640 Kb, в утолщенном корпусе под панельку DIP32 - это SC11, SC12, SC13. И 16-ти разрядные с расширенной памятью до 8 Mb - SC123, SC143, в корпусе BGA-177 с шариковыми монтажными выступами, что сильно осложняет их монтаж, а значит и использование, хотя характеристики их мощнее. В чип встроены таймеры, контроллер прерываний, COM порты, контроллеры I2C, SPI, есть интерфейс  Ethernet  и еще другая периферия.
Чипы с приставкой  -IEC в названии - снабжены лицензией. В среднем SC13 обходятся за 106 EUR, SC143 - 200 EUR.
На сайте фирмы Пролог очень много информации по BECK-у, будто сайт почти весь посвящен ему. Подробные описания аппаратного устройства и логической структуры памяти и ПО, многочисленные примеры исходников программ работы с разными устройствами, в том числе с шинами I2C, SPI, USB, обмен по TCP/IP, работа с FLASH памятью, и вплоть до WEB, FTP и HTML.
К этому трудно что-то добавить, но все-таки можно дать немного замечаний, выявленных на собственном опыте.

При покупке чипа к нему прилагается SDK - среда разработки целевой платформы (Target), с помощью которой собственно и становится возможной стыковка BECK-а с CoDeSys. Среда содержит быблиотеки системы исполнения .LIB, подключаемые к проекту на CoDeSys. В SDK формируются наборы портов ввода / выода, длительности и временные соотношения программных циклов, назначаются системные события и их обработчики, и вообще весь функциональный набор будущего контроллеравыра. На выходе вырабатываются файлы  .TRG,  .CFG  и некоторые другие через которые вся подготовленная конфигурация компилируется в исполняемый код. После загрузки кода становятся доступны возможности среды CoDeSys, такие как  отладка в OnLine режиме, мониторинг, визуализация, передача файлов по TCP/IP и др. Работа закрытого контроллера полностью видна из среды CoDeSys, хотя инструментальный компьютер можно отключить и контроллер продолжает работать совершенно автономно. Так-же OnLine можно и подключиться, чтобы что-то подправить, измнить на ходу параметры. Современная интегрированная система.
Для начального запуска BECK-а служит набор программ - ChipTools. С их помощью прописываются адрес TCP/IP, задаются базовые аппаратные параметры. Можно также полностью перешить содержимое постоянной памяти с операционной системой, но делать это страшно осторожно ! Прошивки RTOS прилагаются с разным составом компонентов : от тяжело-навороченных с  WEB-серверами, до облегченных с одной поддержкой TCP/IP, а то и вовсе без того, смотря - будет ли данный контроллер выполнять роль центрального обменного узла для остальных, или рядовой исполняющий блок.
По нашему мнению, SDK еще не доработан в части гибкости конфигурирования групп портов ввода / вывода. Замечены неприятности и во встроенном ПО. Чипы поставляются со встроенной многозадачной операционной системой реального времени - RTOS. Задачи самой RTOS работают стабильно, выдерживая отведенный квант времени. А вот с задачами ПЛК дело похуже. Как одна из задач, через так-называемую RTS внедряется исполняемый модуль PLC, и работает на одном из высоких приоритетов, но не как положено для жесткого режима времени, а подчас перебивается другими функциями, больше всего операциями обмена по Ethernert. Колебания квантов времени доходят до нескольких раз (!) В некоторых случаях - это не допустимо. Хотя тут можно подобрать структуру комплекса : контроллеры с интенсивным сетевым обменом не ставить на операционные исполняющие роли, а у тех в свою очередь свести к минимуму внешний обмен или сделать его контролируемым.
186-я архитектура процессора почти однозначно определяет схемотехнику внешних подключений. Типовые схемы прилагаются в документации и содержат множество фрагментов подключения внешних портов, COM портов, I2C, SPI. Они поддерживаются функциями API операционной системы, и особых сложностей вроде не представляют.
Можно подключить внешний FLASH диск - но не механический с IDE интерфейсом. Дело в том что функции 13-го прерывания, обслуживающего диски упрощены, и многие содержат просто функции-заглушки. Схемы подключения FLASH диска также прилагаются ( можно сбросить на емел ).
Для внешнего обмена имеются шесть блоков ввода / вывода, по 256 портов в каждом - предостаточно !  Разрабатывать соединения с платами ввода / вывода  надо тоже внимательно : время между выдачей на шину данных и фронтом импульса строба - довольно критично, порядка 10 наносекунд. Надо предусмотреть дополнительные локальные защелки.

А вообще - аппарат передовой !

С уважением, SAN.

Откуда 200? Реально самый дорогой - 129. Причем это не в среднем, а по максимуму при покупке 1 штуки. Но по одной штучке покупают разве что радиолюбители, оптовые же цены меньше вдвое.
Далеко не все используют эти чипы с CoDeSys, многим не нужно обеспечивать программирование  своих устройств конечными пользователями, при этом достаточно компилятора C, т.е. чипы без индекса IEC, они дешевле на 10 EUR.

В части конфигурирования ограничения понятны, такой полуфабрикатный (бесплатный) подход дает меньше возможностей по адаптации, чем традиционное приобретение полного комплекта CoDeSys SP в исходных текстах. Увы понятия 'хорошо' и 'бесплатно' трудно совместимы

Потрясающе. CoDeSys бурно развивается !

А вот есть технический вопрос по среде разработки. В настройках меню Project, в пункте Options, в разделе Build - есть задание Number of Data segments. Можно понимать как - число сегментов данных. ЧТО это за установка, О КАКИХ сегментах идет речь, КАК можно ими управлять, КАКОВ доступ с точки зрения адресов памяти, НА что они влияют, КАК эта настройка отражается на исполняемом коде ...

По возможности осветите эти вопросы.

С уважением, SAN.

http://www.prolog-plc.ru/3s/conf_07.htm - Подробности и регистрация.
Регистрироваться для участия уже пора!

Для IPC@CHIP CS11/13 может быть только 1 сегмент. Поэтому в этом диалоге всегда должна стоять единица.

BTW: с учетом Ваших пожеланий в CoDeSys 3.x добавлен REFERENCE TO он же алиас.
Введены объединения UNION и тип LTIME (длительность с точностью до наносекунд). В стандарте МЭК 61131-3 этого пока нет. Кроме того, реализован I/O Mapping, позволяющий гибко управлять связями переменных проекта с каналами, как дополнение к существующему в МЭК механизму связи ПО с железом через прямые адреса (AT).

Off sanwork: PS отличный спам фильтр у Вас на мыле, пробиться через него просто не реально!

Первоначально опубликовано Mixer И когда же мы увидим сей удивительный продукт CoDeSys 3.0 ...

Так уже и 3.1 вышел. Вопрос только в том, когда на Российском рынке появятся контроллеры со встроенной системой исполнения для 3.x. Немецкие точно осенью будут, наши пока не столь оперативны.

Конференция в этом году в основном посвящена новшествам CoDeSys + ее (конференцию) распробовали изготовители оборудования и достаточно активно просят время для презентаций. В абсолютном большинстве участники конференции опытные люди, использующие ПЛК годами и их мнение об опытных образцах весомо. Как минимум 4 новых контроллера будут включены на публике впервые...
(Надо поставить в зал пару лишних огнетушителей )

ALIASES (о необходимости которых ... говорили ... ), да еще и UNION (в основном для внутренних данных) - великолепно !

ALIASES  -  это прорыв, дающий возможность однонаправленного продвижения проекта, обратные звпросы заказчиков и потери времени должны сократиться.
Технически,  Алиасы не превносят ничего нового - ведь для МЭК-данных механизм разнотипного доступа к области памяти уже существует - AT%, и логическая целостность среды никак не затрагивается. Зато пользовательские преимущества - налицо. Конечный программист, в каждый момент времени будет работать с небольшой группой переменных, с собственными понятными именами, а не извлекать их из общего обширного интерфейса, где в два счета можно запутаться в однообразных нумерованных названиях. Отсюда резко падает вероятность ошибок. Да оно и подтверждается многократной практикой.

Еще можно сказать о, якобы, сложности среды CoDeSys. Она не сложнее других, общеизвестных - C++ Builder , AutoCAD ,  да те-же  CorelDraw , Photoshop ...  и многое др.
Никто не заставляет использовать все сразу. Возможности имеются, и ждут своего часа, придет время - они пригодятся. Дело совсем в другом - в том, чтобы когда действительно понадобится та или иная функция, от нее было бы получено то, что ожидалось, чтобы она оправдала свое назначение.

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

Ну а теперь по делу. Было бы хорошо организовать полноценную связь  CoDeSys  c  C++.  Зачем нужен сам  C++  - вопрос отдельный, допустим, что нужен.
В данное время эта возможность далека от желаемой. Слегка обозначено взаимодействие с функциями  C++  через "внешние" псевдобиблиотеки, да и то с большими ограничениями, с каким-то странным выравниванием функций по байтам (!), что можно сделать только на Ассемблере, невозможность использования общей области данных и т.д.
Конечно, тут не все так просто - CoDeSys  и  Си ,  в определенном смысле разнородные системы, особенно по части распределения данных - свободных (куча) и фиксированных.

То же касается полной подднржки  ActiveX  элементов в HMI визуализации.

Но все это, уже длинный разговор.

В  CoDeSys радует эффективность исполняемого кода.
В новых появляющихся системах больше внимания уделяется внешней раскраске, компиляция кода - на втором плане. Это нехорошие поползновения, ведь к некачественному коду особенно чуствительны "легкие" контроллеры, типа  ADAM , WAGO  и подобные.

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

CoDeSys поддерживает много разных аппаратных платформ. Для них используются разные компиляторы Си с совершенно различной структурой объектных файлов. Поэтому сделать красивую универсально стыковку с внешними биб-ками не получается. Они поддержаны для всех аппаратных платформ,  но в каждом случае есть своя специфика. Реально они используются OEM для интеграции CoDeSys со своими know how. Глобально наша цель сделать CoDeSys так, чтобы никаких внешних инструментов не возникало желания использовать вообще.

 Кстати вчера мы открыли официальный сайт 3S на русском языке. См. http://www.3s-software.ru - http://www.3s-software.ru

ok. добавил про форум

Тут надо пояснить.
CoDeSys  так-и-так стоит на  C++.  Не считая  .NET FX,  транслятор построен на самом, что ни наесть Си. Си-шная программная структура видна невооруженным взглядом, только замаскирована под  STEP7  -  усеченный Паскаль-подобный диалект с графическими  LD, CFC  и другими редакторами.

Так что речь идет не о добавлении в среду чего-то нового, а вовсе наоборот - о воссоединении  языка, у которого много чего сократили и сделали правила построже.
Отсюда, отпадает вопрос - зачем в  CoDeSys - C++.

Эта тема простирается дальше.
Сейчас накопилось уже много разных сред программирования, и каждая для чего-то хороша. Нет универсального инструмента на все и про все. Мир как-раз хорош своим разнообразием, а не попытками натянуть все на одну мерку. Для  "железа" хороши  ASM  и  C,  для  WEB-а  -  Perl,  для  Медии -  Jawa,  и т.д.с.д.

Так вот, следующая ступень в развитии информационных технологий  -  интеграция разных платформ между собой, использование преимуществ каждой из них. Таковые попытки конечно уже есть  -  .NET Framework,  C#  и  пр.  Нельзя сказать что они прямо-таки вызывают восторг.
Для промышленных систем требуется интеграция со своими особенностями, чтобы программные компоненты не утратили своей силы и эффективности. Кстати, в  CoDeSys  кое-что реализовано - например, WEB-визуализация. Этакая смесь Си, Жавы, ИксэМэла. И вобщем-то, неплохо. Каждый делает свое дело, и нисколько не снижает скорости исполняющего кода.
Здесь уже возникает проблема некого стандартного взаимодействия между платформами. но никак не ".. зачем нужен Си .."

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

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

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

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

Преобразуйте разные варианты CFC  в  IL , и сами все увидите.

Чтобы лучше понять об чем речь - небольшая задачка.
Как вы думаете за сколько тактов установится истинное состояние вот этой схемы ?

За один,  за два ? ...  Нет, и не за три,  а за пять !
Блок-схема  -  всего-лишь  графическое изображение текста, так-сказать, экранизация.
Реальная же электрическая схема мгновенно реагирует на изменения в любом месте.

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

результата получалось совсем не то.

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

PS.

Вычисления в CoDeSys выполняются не матричными уравнениями как в SPICE моделировании радиосхем, а простыми - линейными. Можно набросать какую-нибудь блок-схему, преобразовать в текст  IL , и терпеливо поизучать в каком порядке выполняются логические уравнения, и расположены в них переменные с неизвестными.  В еще большее заблуждение можно впасть при использовании динамических элементов с обратными связями, например - триггеры.

Я это излагаю за тем, чтобы кто-то сразу принял бы верный тон, начиная творить в CoDeSys.

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

Кстати напоминаю про конференцию! http://www.prolog-plc.ru/3s/conf_07.htm - Пора записываться!
По опыту прежних лет основной вал заявок приходит за неделю, когда уже все нормальные номера в гостиницах заняты.

Ну вот - дальше LD перевести в IL, то-есть в последовательность строчек текста. Лучше бы конечно в ST, но такого преобразования нет. Смысл тут в том, что последующие уравнения используют результаты предыдущих, которын в свою очередь еще не готовы, и т.д. Очень наглядно это видно на простейшем триггере из двух И-НЕ. По идее он должен быть полностью симметричным, но после пары шагов (в ручном режиме) становится ясно, что модель не совпадает с реальным прототипом.
В самом общем случае логическое равновесие наступает при количестве проходов не меньше числа уравнений, то-есть элементов. При определенном порядке, истинное состояние может установиться и при меньшем числе проходов, вплоть до одного. Но главное, что этот процесс не гарантирован. Если пяток элементов еще можно проработать, то схемы с десятками элементов, и еще со сложными обратными связями, проконтролировать невозможно. Тут прибегают к простому принципу - отрабатывать по кускам.

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

К _IP_:

А вот возник вопрос такой: известно ли как устроена в CoDeSys функция TIME? Просто возвращает содержимое какого-то регистра или может быть вдруг какие-то прерывания обрабатываются или еще что?

А если это просто регистр, то как часто обновляется? Независимо или поцикленно?

Что за функция TIME, в смысле стандартные МЭК функц. блоки таймеров TON, TOF?

Они работают внутри так: в контроллере есть 1 аппаратный таймер. Экземпляров функц. блоков TON, TOF может быть неограниченно много. Каждый из них имеет внутри переменную, по которой 'засекает время' при старте. Далее при каждом очередном вызове он проверяет, вышло ли заданное время или нет. Т.е. прежде чем проверить изменение выхода таймера, его нужно обязательно перед этим вызвать. Если блок не вызывать  (например, обойти его в программе), то время все равно идет. В целом стандартный таймер позволяет определить что время уже вышло, но не гарантирует, как давно оно вышло. Чтобы поймать этот момент с нужной точностью нужно с соответствующей частотой его опрашивать.

По умолчанию, аппаратный таймер = регистр, который обновляется независимо по прерыванию через 1мс. Должно быть так.
Однако, есть в природе несколько ПЛК с CoDeSys в которых внутренний регистр таймера не обновляется между циклами ПЛК. (Изготовитель ПЛК может сделать так для повышения быстродействия или др. причине.) Т.е. этот момент лучше проверить на конкретной модели ПЛК: сделать цикл while  с условием выхода по таймеру, если завис – то независимого обновления нет.

Есть там функция TIME();

Да, она просто возвращает значение вышеописанного регистра. Практически это время с момента рестарта.

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

Но есть куча приемов для отладки в режиме RT. Все зависит от конкретной частной задачи.
Все они требуют элементарных рассуждений.

Все таймеры и счетчики в CoDeSys сами ничего не считают. Они только "выхватывают" значения системного аппаратного счетчика, который работает непрерывно. После открытия счета таймеры начинают давать приращение своей внутренней переменной. При сбросе - обнуляют.

На выходе  TP  сигнал  Q  меняется не сам-собой, а после нажатия кнопки отладки (F5). По истечении заданного времени (реального) системный счетчик достигнет величины срабатывания (и продолжит считать дальше), но сигнал на выходе не изменится - таймер будет "заморожен". Его состояние изменится при нажатии кнопки. Это равносильно тому, что время срабатывания таймера было задано вручную - и смысл отладки достигнут !  Не видно никаких "неудобств".
Кстати, такая-же ситуация возникнет при задании времени цикла больше времени таймера. Если цикл задачи будет с периодом  5 сек.  а значение таймера  1 сек. , то промежутки времени точнее  5 сек.  все-равно нельзя будет отсчитать. Если задача не назначена, то программа будет крутиться в режиме FreeWheeling - как в Windows, с максимально возможной скоростью.
У программы нет ни глаз ни ушей, о времени она судит по сигналам таймеров, поэтому логика работы программы никак не нарушается.
Отладку с breakpoint-ами лучше делать в режиме симуляции - Online->Simulation Mode, так-как в точке останова возникают конфликты среды с системным счетчиком. И вообще, надо избегать точек останова, а лучше использовать пошаговый режим - он более "родной" для систем Реального Времени.

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

ИМХО точки останова никак не связаны с концепцией распределения аппаратных ресурсов в многопоточной среде. Обеспечивает это распределение детерминированное выполнение в системе реального времени или реализующее вытесняющую многозадачность. Какая собственно разница. Сам по себе процесс по большому счету любой может быть остановлен на любом шаге, если при этом будут остановлены все сопутствующие процессы. Это видно из простых логических умозаключений. Другое дело, что среда программирования прерывает только процесс разрабатываемого приложения, но среда исполнения при этом никаких изменений не претерпевает, продолжая функционировать в обычном режиме, посему и таймер привязанный к аппаратному таймеру не может быть остановлен. Но это вовсе не говорит о неприемлемости точек останова. Более того возьмите хоть SoftIce он позволяет поставить в стоп вообще всю ОС. Да собственно выполнение любого кода останавливается по  завершении кванта времени выделенного потоку. Так что это нормально естественно и логично, и ничего предосудительного в поведении таймера нет…

Дэк-с ... Проблемы-то вроде нету.
Вот слегка измененный пример.
Две переменные  var1 и  var2  находятся в обоих ветках условия.
Время  _T_cycle  устанавливается таким большим, чтобы спокойно успеть заметить изменения. При большом времени, скажем - T#10s, точка останова и вовсе не нужна !  Но если нужна (когда много переменных), то можно и поставить.
Сначала изменияется  var1. При переключении таймера - var2. Все хорошо видно.
Чтобы  Win  не зависал, надо включить режим симуляции - поставить галочку  Online->Simulation Mode.

Теоретическая часть.
Точки останова опасны не для железа, а для программы.
Как было совершенно верно замечено ( Dismay ), если все части программы, связанные одним таймером остановить, то программа ничего не заметит. Но это идеализированный демо-случай. Практическую пользу имеют как-раз остановы отдельных модулей, и здесь ситуация сложнее.
Приходилось отлаживать программы работающие не от системного счетчика, а вообще от внешнего генератора. Здесь не помог даже Великий и Могучий SoftIce (хотя он имеет доступ к четырем аппаратным отладочным регистрам процессора). Пришлось вставлять свои баги, чтобы программа достигнув интересующего места остановилась и неминуемо разрушилась из-за нарушения последовательности логики. Но золотые крупицы ценной информации успевали появиться.
Хочу еще раз повторить - в каждой ситуации нужны конкретные приемы и решения.

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

Отнюдь !
Каждый более-менее писамший Кодер знает, что средства отладки в несолько раз больше самой программы. В простом случае эти средства находятся в стороне, и наблюдают за работой. Когда дело посложнее, то отладочные нструменты приходится внедрять в код самой программы. Есть даже понятие - отладочный код.
Когда прога становится похожа на правду, отладочные примочки постепенно отцепляют, пробуют в рабочем режиме. И так несколько раз.

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

То была статическая отладка. Динамическая (в реальном времени) добавляет свои специфичные особенности.
Во 1-ых, точки останова работают не так, как в статике. После первой остановки, следующий шаг будет сделан не сразу на следущую команду, а через цикл. То-есть, прежде чем перейти на следущую после метки строчку, будет сделан полный цикл. Разумеется, хронологическая последовательность событий нарушится и дальнейшие результаты бесполезны. Спросите - зачем тогда нужны точки останова в RT ? Они нужны ради единственного шага, который может дать ценные сведения. И где-попало breakpoint-ы не ставят.
Вообще, каждое средство предназначено для определенных целей. Не следует возлагать лишнего, и ожидать больше чем может инструмент, а потом ругать, что он плохо сделан.

2-ое.  Надо уточнить фразу : " .. посмотреть как считает счетчик ..".
Как считает сам системный счетчик с частотой 1 кгц. (или 10 Мгц. в ядре) (?) - вряд-ли вы это прямо сможете увидеть !
А вот изменение значения функции таймеров в CoDeSys - так оно происходит с частотой цикла программы ! 

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

3-тье.  Останавливать счетчик  RT  не имеет смысла - на то он и счетчик Реального Времени ! Дело не в плохой разработке среды. Есть вещи принципиально невозможные. Рассмотрение момента времени и движущееся время - несовместимы (как длину измерять в квадратных килограммах). Если остановить счетчик, то он перестанет быть счетчиком Реального Времени - в этом смысл его сути ().

Часто бывает надо выяснить какую-то конкретную предполагаемую ситуацию. Например, значения переменных при определенном значении другой переменной. Или состояние при достижении какого-то числа счетчика  и т.д.  Специально на эти случаи вставляется отладочный код, или точка останова.
Обычно подобные приемы и используются при отладке в RT.

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

To Mixer http://www.prolog-plc.ru/tmpl.php?content=info3.htm - http://www.prolog-plc.ru/tmpl.php?content=info3.htm

SAN, а вы не думали оформить эти измышления в виде публикации? Почитать было бы многим интересно а не только форумчанам.

Поставил точку останова на IF, попал в нее. Далее вручную поменял значение выхода  Tmr_cycle.Q и пошел в какую надо ветку. Экземпляр FB таймера вообще можно раскрыть в отладчике и поменять значения внутренних перемененных, дабы привести его желаемое состояние.

Жалко конечно, что время нельзя останавливать. Пока я сплю будильник (аналог таймера МЭК) мог бы постоять

Приветствую.
Да, я хотел бы изложить некоторые соображения по вопросам программирования для систем Реального времени. Известные методы в сочетании с собственными исследованиями.
Где и как можно опубликовать статью?  Каковы требования к материалу - об'ем, форма и т.д. ?

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

Прочитав вышеприведенную дискуссию, вспомнил ситуацию почти 20-летней давности. Тогда я работал в г. Северодонецк НИИУВМ. Я разрабатывал отладчик микрокода. На этом микрокоде программировались процессорный и другие модули. Так как "микрокодистов" не хватало, поручили писать программы на микрокоде обычным программистам ( а точнее -ткам). Вот и у них возникали точно такие же проблемы: почему после останова все зависает и так далее. С этим они шли ко мне. Когда я обратился к главному разработчику, он мне ответил: "Ты свой отладчик изменить не сможешь и мы архитектуру поменять не сможем, просто эти программы должны писать другие люди, которые понимают где можно ставить точки останова".

Ничего вам это не напоминает?

По поводу загромождения кода отладочными кусками: Это естественно. Отладчик дает только базовый набор инструментов, они работают эффективно только в умелых руках . В каждой программе есть своя специфика и соответственно свои узкие места и разные ключевые данные. В CoDeSys V2 нет директив условной трансляции, чтобы включать/выключать отладочные фрагменты.  Однако, это удобно делать через биб-ки. Т.е. объединяем ключевые POU в биб-ку и делаем 2 версии: отладочную и рабочую. В менеджере библиотек подключить при компиляции нужную можно 'легким движением руки'.

ИМХО Любой POU нужно писать так, как будто он работает во враждебном окружении (концепция защитного программирования). Т.е. может получить на вход совершенно 'дикие' данные, контроль на допустимость лишним не будет. Кроме того,  ОЗУ вполне имеет шанс сбойнуть. Программа при этом не должна с ума сойти, а постепенно сама выправить данные. Например, в циклах не стоит писать '=' в качестве условия окончания, лучше '>' или '<'. Если вдруг переменная получает нереальное значение, то надо установить ее в некое разумное значение. Все это совсем не сложно, нужно просто думать об этом и выработать привычку, что достигается практикой. Ну и выуживается из программ и публикаций опытных людей

Отличная мысль! Было бы очень интересно.
Написать надо так, чтобы самому понравилось. Обязательно дать почитать 2-3 людям и учесть их критику. Влезать в некий размер не стоит и стремиться. Разбивка на части и красивая верстка (даже не пытайтесь) – это задача профессионалов редакции.
1) Поскольку данный форум относится к журналу СТА, то в первую очередь я бы обратил внимание на него. По поводу требований к подготовке материалов – вопросы к редакции, они с удовольствием ответят. + http://forum.cta.ru/forum_topics.asp?FID=13 - раздел же есть специальный на форуме.
2) Посмотрите на журнал http://www.asucontrol.ru - ПАСУК , который печатает весьма разнообразные и часто неординарные статьи. Его редакторы практически не правят авторский текст (не всегда это хорошо), который обязан сам отвечать за свой труд.
3) Вообще журналов сейчас уже стало больше чем авторов. Т.е. найти 'свой' вообще не вопрос.

Хочу продолжить тему следующим вопросом.

Создал я на базе двух блоков TP генераторы коротких импульсов, которые тактируют работу (EN/ENO) инвертеров двух переменных. У TP1 PT1=T#2s , у второго PT2=T#4s. При запуске программы генерируется 2 меандра со скважностью 50% и периодом 2*PT1 и 2*PT2. В начале все синхронно переключается в одной фазе, а потом со временем возникает какая-то рассинхронизация (смещение фазы)... Ума не приложу в чем дело?

Возможно, перезапуски таймеров происходят не абсолютно одновременно и эта мизерная разница аккумулируется ими. Я бы после PT1 поставил счетчик/делитель импульсов на 2 вместо PT2 чтобы все было гарантировано четко.

Посидел, подумал еще. И понял, что на сброс генератора импульсов тратится 1 цикл (т.е. в моем случае 100ms), который я не учел, выбирая период. Привильно для входа PT блока TP будет задавать время в виде (T#Ns -T#100ms) , где T#100ms- это период рабочего цикла котроллера! 

А может использовать не два отдельных генератора, а ОДИН формирователь общей сложной последовательности - практикуется довольно часто, реализуется довольно просто и многими способами (хотя я не в курсе конкретной задачи)

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

Логично, это я и предлагал: 1 таймер + делитель.

Еще вопрос о таймерах:

Требуется чтобы определенное событие проиходило каждые 8мс, как это сделать с помощью таймеров кодесиса? Прерываний я так понял никаких нет по таймерам как например в контроллерах Атмел...

Не это точно не все, если будет больше одной задачи в Task крутиться прийдеться семафорить доступ к общим переменным ибо это уже будет многозадачное приложение и наворотить можно в случае “ивсе” такого что потом не разберешь ничего.

Первоначально опубликовано Mixer Пишешь свой POU в котором делаешь все, что нужно. Далее определяешь его в Task configuration и ставишь время T#8ms. Все.

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

Создал два таска, у одного период 8мс и приоритет 0, у другого период не указан и приоритет 1...

Поставил точки останова в обоих подпрограммах и останов происходит только в таске с приоритетом 0, может конечно если подождать долго то наконец и во второй зайдет

А если приоритеты одинаковые поставить, то видно что срабатывание происходит реже чем 8мс, я там счетчик инкрементирую, и в визуализации видно что частота около 1Гц...

Ну незнаю где там Вы поставили точки останова, но с многозадачностью в CoDeSys все достаточно ровно однако. Смотрите Task в онлайне и увидите что все POU вызываються...

Пара вариантов без использования многозадачности:
1) На FBD можно генератор импульсов на 8мс поставить, после него детектор фронта и далее что надо.

2) На SFC делаю простейший POU . Он состоит из начального шага и еще одного, в конце переход на начальный шаг. Во всех условиях переходов ставлю TRUE. Далее в атрибутах шага ставлю минимальное время 8мс. В него вставляю начальное действие на любом языке и в нем делаю что надо.