[uni 6]

Ясно, в общем, вы не знаете как работает Beremiz изнутри или аналогичные системы, на которые я указывал. Дальнейшее обсуждение бесполезно, пока не увидите и не соберёте проект самостоятельно. 

[tonyk_av 39]

16 minutes ago, uni said:

Загрузчик - это не среда исполнения.

Естественно.

19 minutes ago, uni said:

В случае с matiec нет такой отдельной среды исполнения

Вот её-то и надо сделать.

19 minutes ago, uni said:

мэк программа и среда исполнения являются одним целым - единицей компиляции

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

 

20 minutes ago, uni said:

Эта прошивка всегда разная для любой правки мэк кода

Она разная для разных программ пользователя.

 

21 minutes ago, uni said:

Вы можете повредить среду исполнения, так как она собирается пользователем. 

Если ты её так сделаешь, то- да.

 

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

[uni 6]

Вот вам проект, балуйтесь. Я только что проверил, он собирается в моей системе. Нужно поставить Arduino IDE 1.8.x, так как там есть готовый компилятор, и указать путь к avr-gcc.exe в PATH, перед запуском Beremiz IDE. Также нужно поправить содержимое файлов установки IDE, которые приложены в архиве. Это папка c_ext и matiec, но я уже точно не помню что там менялось и менялось ли. В папке test находится проект и дополнительные файлы.

compile_result.txt содержит вывод компиляции, который показан на картинке. Должно получиться то же самое. Ещё раз повторяю, на картинке с Proteus'ом показан совершенно голый мк ATmega2560, в котором даже нет загрузчика, не то, что среды исполнения. Beremiz записывает в совершенно голый мк 1 файл, который является результатом компиляции проекта, содержащего мэк-программу и "обвязку" для её запуска.

beremiz_test_20221005.7z

Изменено 5 октября, 2022 пользователем uni

[mantech 42]

46 минут назад, uni сказал:

Вот вам проект,

Я правильно понимаю, насколь бы не был сложен алгоритм программы МЭК, она вся будет размещаться в бесконечном цикле функции main (for (;;))  ? 

А все временные отсчеты в ISR(TIMER0_OVF_vect)

Или я что-то упустил?

Изменено 5 октября, 2022 пользователем mantech

[uni 6]

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

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

Есть специальные картинки, которые это поясняют. Это ограничения стандарта. Таким образом, если у вас 4 RS'а, то запросы по ним с мэк уровня всегда будут идти поочерёдно - сначала обработается 1-й RS, потом 2-й и так далее. Это удручает тех, кто сталкивается с этим впервые.

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

Изменено 5 октября, 2022 пользователем uni

[mantech 42]

27 минут назад, uni сказал:

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

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

Хм, это уже интересно, надо как-нить подумать и попробовать реализовать это на своем фреймворке, там почти все, что нужно есть, спасибо...

[uni 6]

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

Изменено 5 октября, 2022 пользователем uni

[mantech 42]

37 минут назад, uni сказал:

Таким образом, если у вас 4 RS'а, то запросы по ним с мэк уровня всегда будут идти поочерёдно - сначала обработается 1-й RS, потом 2-й и так далее.

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

ЗЫ. RS- я в курсе, что это триггер, а не посл. порт)))

7 минут назад, uni сказал:

но исполняться они всё равно будут друг за другом. 

Это существенно упрощает реализацию, раньше думал, что там все может работать параллельно)))

 

И еще в догонку, вопрос - минимальный интервал таймера какой там принят? 1мс или 1мкс ?

Изменено 5 октября, 2022 пользователем mantech

[uni 6]

Для matiec нет, я как раз писал квазипараллельное использование 4-х RS'ов для Codesys, используя хитрый алгоритм, но там был драйвер на ST. 

А вообще, это нужно создать функциональный блок и поставить ему в соответствие код на Си, используя примеры в самом matiec (в папке вроде должны быть, где Beremiz, или в самом проекте matiec на github) . Блоки эти можно посмотреть по входам и выходам в том же Codedys'е в асинхронном исполнении. 

RS тут это последовательный порт как раз, а по поводу разрешения таймера я специально привёл картинку из Протеуса. Я не помню какой я там тик установил, но маленький. Если я возьму его больше, то меандры на графиках будут смещаться относительно друг друга, другими словами, указанное время в мэк таймере не будет соответствовать реальному интервалу. Это уже экспериментально проверять. 

Изменено 5 октября, 2022 пользователем uni

[tonyk_av 39]

12 hours ago, uni said:

но исполняться они всё равно будут друг за другом

Не совсем так. Забыли указать обработчики прерываний.

[uni 6]

1 час назад, tonyk_av сказал:

Не совсем так. Забыли указать обработчики прерываний.

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

Литература:

1. Coder's Corner: The IEC 61131-3 Software Model.

Да, кстати, я отчасти ошибся, судя по картинке. Задачи, для которых указан приоритет и время цикла, могут прерывать остальные. Давно уже не практиковался. В реализации runtime моего примера вроде бы нет такой поддержки.
За несколько лет работы с Codesys'ом мне так и не пришлось использовать Event'ы. Там в настройках проекта есть специальный список Событий, на которые можно написать обработчик (назначить мэк-функцию).

Цитата

It should be noted that multitasking is NOT required by IEC 61131-3 and that not all hardware will support multitasking. However, if implemented, tasking will follow the behavior outlined here. Unique aspects of task configuration are, of course, implementation dependent and the controls vender should be consulted prior to configuration of task with any potential to impact personal safety or equipment security.

 

Изменено 6 октября, 2022 пользователем uni

[tonyk_av 39]

1 hour ago, uni said:

Я имел в виду мэк-элементы, т.е. все сущности, из которых состоит мэк-приложение

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

15 hours ago, uni said:

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

Что значит "работающие на мэк уровне"? Или здесь с формулировкой напутано, или глупость.

Если драйвер протокола Модбас работает на прерывании, то он принципиально не_может работать последовательно с чем-то. Например, время цикла сканирования 1 секунда. И чё, через секунду начнём обрабатывать пришедший запрос? Ха-ха три раза. Поэтому приходится использовать двойную буферизацию данных при общении с внешними устройствами, плюс задействовать объекты синхронизации доступа к данным ПЛК.

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

[uni 6]

52 минуты назад, tonyk_av сказал:

Что значит "работающие на мэк уровне"? Или здесь с формулировкой напутано, или глупость.

Это означает, что они являются элементами программы для ПЛК, т.е. написаны при помощи МЭК-языков. Что это такое написано в стандарте ГОСТ Р МЭК 61131-3-2016.

52 минуты назад, tonyk_av сказал:

Если драйвер протокола Модбас работает на прерывании

Покажите, пожалуйста, слово "прерывание" и его определение в стандарте ГОСТ Р МЭК 61131-3-2016. 

52 минуты назад, tonyk_av сказал:

Например, время цикла сканирования 1 секунда. И чё, через секунду начнём обрабатывать пришедший запрос?

На каком языке реализован драйвер Modbus? Какой код работает с интерфейсом связи? Если драйвер реализован на МЭК-языке то, да, будете ждать 1 сек, а потом обрабатывать то, что находится в буфере приёмника.

К слову, мои реализации Modbus-RTU (TCP) Slave для Codesys 3.5 входят в SDK для ПЛК АГАВА. Можете скачать, посмотреть на временные диаграммы и попробовать сделать лучше.

Изменено 6 октября, 2022 пользователем uni

[tonyk_av 39]

40 minutes ago, uni said:

Покажите, пожалуйста, слово "прерывание" и его определение в стандарте

Подраздел 4.3:

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

49 minutes ago, uni said:

Если драйвер реализован на МЭК-языке то, да, будете ждать 1 сек, а потом обрабатывать то, что находится в буфере приёмника.

Почему не вынести его в рантайм? Ждать конца сканирования, ИМХО, как-то примитивно. Из-за одного ПЛК, долго отвечающего на запрос, будет тупить весь сегмент сети. Ужас.

[uni 6]

Не надо стесняться показывать весь отрывок подраздела 4.3. В нём сказано, что ваши "отличные языки" должны придерживаться всех пунктов выше, т.е. функция, ФБ и методы - в понимании стандарта, а также типы в понимании стандарта. Форма может быть заимствована, синтаксис может, но всё остальное должно быть в рамках стандарта. Я так и не понял как мэк-функция, мэк-ФБ и мэк-методы связаны с прерываниями? На уровне программных компонент мэк-программы это невозможно, потому что никаких прерываний там не существует как сущностей.
 

1 час назад, tonyk_av сказал:

Почему не вынести его в рантайм? Ждать конца сканирования, ИМХО, как-то примитивно. Из-за одного ПЛК, долго отвечающего на запрос, будет тупить весь сегмент сети. Ужас.

Дело в том, что реализовать поддержку любого протокола в ПЛК можно по-разному. Никто не мешает сделать жесткую поддержку в runtime, когда таблица регистров Modbus строго определена (X, Y и прочим раздаются постоянные адреса). Проблема в том, что runtime в этом случае не доступен пользователю и у него навсегда будет только такая реализация. При этом мэк программа полностью отделена от реализации такого драйвера и ничего про него не знает.

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

Есть ещё один вариант - реализовать Modbus Slave прямо в виде ФБ на мэк-языке, используя другие ФБ, которые работают с последовательным портом или сетью. Так сделано у меня, но эта реализация привязана к конкретному ПЛК - Codesys, потому что там экземпляр блока с Modbus можно поместить в задачу, задав ей высокий приоритет и малое время цикла. Такая задача будет успевать обрабатывать запросы.

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

Тут ещё нужно дать определение драйвера. Что такое драйвер? Он тоже есть в стандарте? Думаю, что нет. Тогда как он представлен внутри мэк приложения? Если они друг о друге ничего не знают, то и обсуждать тут нечего. Если runtime драйвер управляется с мэк-уровня битами регистров ПЛК, то для мэк-программы это просто биты и всё, как и все остальные. Это не имеет отношения к временной диаграмме работы задач.

Бывают мэк-драйверы. С ними история другая. Они подчиняются общей логике работы мэк-приложения, т.е. если их 10 штук, то все они работают по очереди.