Многозадачность и языки МЭК

Первоначально опубликовано Dismay ...При доступе к переменным типа BOOL ИМХО регулирование доступа вообще теряет смысл, потому как “… пол мальчика не продается…”...

 

Однако: 1) изменение одного байта (тем более бита) особенно в 32х разрядных системах может тоже выполняться за несколько ассемблерных команд. 2) компилятор может оптимизировать код, сохраняя значения переменной в регистрах. 3) задача 1 делает IF X = TRUE THEN всякие вычисления, предполагающие, что X = TRUE, а в это время более приоритетная задача 2 меняет X и все портит. Т.е. напрашивается требование защиты семафорами всех глобальных переменных, даже BOOL, которые используются более чем в одной задаче. Так?
Наверное, наиболее правильно вообще организационно разделить задачи по максимуму. Каждая должна работать только с определенными входами/выходами, к которым не лезут другие. Взаимная синхронизация только путем обмена сообщениями, как будто работают несколько разных ПЛК. Реально ли это?

 

Первоначально опубликовано evgeny А разве ISAGraf 5 версии не многозадачный ещё?

Да все приличные МЭК системы многозадачные, даже Изограф. Проблема в том что, реализовать это проще, чем научиться грамотно применять в прикладных проектах.

 

Первоначально опубликовано evgeny И не пугает ли вас цена QNX?

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

 

 

 

Первоначально опубликовано _IP_ ...При доступе к переменным типа BOOL ИМХО регулирование доступа вообще теряет смысл, потому как “… пол мальчика не продается…”...

 

...предполагающие, что X = TRUE, а в это время более приоритетная задача 2 меняет X и все портит. Т.е. напрашивается требование защиты семафорами всех глобальных переменных, даже BOOL...

 

В данном случае простая логика показывает, что если более приоритетная задача изменила значение булевой переменной, то сие ни что иное, как требование момента, свидетельствующее об изменившемся состоянии контролируемого объекта. И с семафором или без такового в текущем цикле выполнения адекватной реакции от алгоритма POU ждать не приходиться это уже к вопросу о времени реакции. Разделяемые переменные любого типа я рассматриваю как переменные ссылочного типа, то есть не защищенный ресурс, следовательно, в течение одной логической цепочки использую исключительно результат однократной проверки, так что все таки  “…пол мальчика не продается…”. ИМХО только инкапсулированные данные можно использовать не задумываясь о возможных внешних воздействиях. Вообще, на мой взгляд, любые способы обеспечения устойчивости должны быть логически обоснованы в каждой конкретной задаче, избыточность должна быть обоснована.

К вопросу о применимости многозадачности могу ответить словами Гендальфа о “Паландире” в башне Сарумана:

-“Нам ли бояться Интернета!”

 

Первоначально опубликовано _IP_ 'Классические' программы для ПЛК пишутся в виде одной циклической задачи. Чтение входов, обработка (прикладная программа), запись выходов. Но во многих современных средах МЭК 61131-3 программирования можно делать несколько циклических задач. Некоторые называют это вредным и опасным, другие напротив считают очень удобным.

Хороший вопрос! ;)
Я его здесь на форуме активно подымал ... 1-1.5 года назад... И тогда, и сейчас утверждаю, что многозадачность для МЭК 61131-3 & PLC - это не более чем рыночно коммерческая "рюшечка": производители закрытых hard-PLC сами загнали себя в угол (10-15 летней практикой, в том числе и МЭК), а теперь ... наобещают:
- в UnityPro Schneider Electric задачи в PLC могут быть (одновременно ;)): а). периодическая, б). циклическая, в). таймерная, г). по событию, д). высокоприоритетная...

Господа, задача в системе, в которой принципиально нет синхронизаций и взаимодействий (а в рамках парадигмы МЭК - их нет!) может быть только одна и единственная...
Конечно, вы можете запустить на 1-м процессоре 2 (или N ;)) автономных и не взаимодействующих задач - но это будут 2 или N разных АСУТП: например, АСУ управления напольным оборудованием ж/д станции + АСУ управления электрокофеваркой диспетчера этой станции ;)...

Первоначально опубликовано _IP_ Имеет ли кто-либо позитивный опыт написания таких программ? Поделитесь опытом. До каких пор это хорошо и где лежит порог за которым нужно использовать более радикальные средства (например QNX)?

Имею некоторый ... позитивный опыт ;), который утверждает (мой опыт):

- для высоконадёжных СУ в критических областях применения системы, базирующиеся на Windows XX - это бред изначально и по определению ... и не зря у вас интерес к слову QNX;
P.S. на сегодня QNX - вполне самодостаточная ОС, и пишу я эти тексты сюда - из-под неё.

- для построения таких QNX-систем совсем не обязательны технологические tools и вполене достаточно средств ОС...
P.S. я не утверждаю, что они не нужны или лишние (например, адаптированные в QNX ISaGRAF & CoDeSys - вполне приличные изделия, или RealFlex), я говорю, что они не являются необходимыми.

- ... и МЭК языки там неуместны, достаточно С/С++ (и берусь утверждать, что С++ - в болешей мере, чем привычный и любимый pure C) + технлогии SWITCH-программирования проф. Шалыто из С.-Петербурга.

Кого заинтересуют соображения и аргументы на этот счёт - можете почитать здесь:
http://qnxclub.net/modules.php?name=Forums&file=viewforum&f=18
- единственно, это потребует много времени: а). это обсуждения и аргументация за более года работы б). с изложением кодов, тестов и промежуточных результатов ... в). + они достаточно хаотичные и разрознённые.

Первоначально опубликовано _IP_ Хотелось бы найти или выработать некий перечень правил: делайте так и так, иначе будет это и это… Для МЭК систем наверное такой информации пока нет. Может быть опытные QNX программисты смогут дать ссылку, где толково объяснено что и как, понятным языком с примерами на С?

- эта ссылка, как вариант - то что вы просили: дальнейшие детали можем обсудить там или здесь.
Кроме того, посмотрите:
http://www.books.ru/shop/books/357604
- на эту книжку "сподвигли", в частности, и разговоры здесь в форуме о многозадачности года 1.5 назад... а если лень книжку листать ;), то вот здесь:
http://qnxclub.net/files/articles/pthread/pthread.pdf
- есть очень предварительная её редакция.

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

Порог, за которым требуется многозадачность - он не только никак не связан со скоростью/производительностью, но даже не коррелирован с ними: многозадачность - это ещё одна парадигма/альтернатива последовательностному программированию, и вы любой из них 2-х выбирайте "на вкус", но это ника не связано с производительностными критериями - критерии выбора здесь совсем другие.
Это почти то, что другими словами пишет здесь:

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

- это - абсолютно верно. Но (!) только в рамках убогой парадигмы, навязываемой hard-PLC + выразительными возможностями МЭК языков.
В этом случае: послушайте умудрённый цитируемый выше совет ... : "никогда не говори никогда" (с) - никогда не раззевайте варежку на многозадачность в МЭК PLC

Первоначально опубликовано Olej это - абсолютно верно. Но (!) только в рамках убогой парадигмы, навязываемой hard-PLC + выразительными возможностями МЭК языков.

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

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