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

Насколько знаю у B&R System 2000 является многозадачной, завтра уточню и вроде дока на русском была как раз по операционной системе контроллеров (она у них собственная) попробую вам слить

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

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

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

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

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

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

ИМХО, во многом все-таки все зависит от среды исполнения. При корректной реализации доступа к разделяемым ресурсам (глобальным переменным) издержки при совместном доступе обычно значительно ниже, чем остановка выполнения основного кода программы и вызова POU по прерыванию. Насколько я понимаю, проблемы совместного доступа в CoDeSys призвана помочь решить библиотека SysLibSem.lib. Которая позволяет обеспечить последовательный доступ к разделяемым ресурсам, единственное разумное правило на мой взгляд которое требуется здесь, заключается в том, что не следует блокировать доступ к разделяемым ресурсам на время большее чем необходимо доступа к ним на чтение или запись. То есть не следует устанавливать семафор в начале POU к примеру если Вы обратитесь к ней только в конце, иначе процесс будет удерживать блокировку все время выполнения программы. Я давно мучаю WAGO 750-841 как раз на предмет совместного доступа, вопрос о необходимости использования семафоров пока так и остался открытым, конечно я не писал многометровых листингов, но серьезных сбоев при обращениях из разных процессов к одной переменной мне так и не удалось увидеть, даже без семафоров. При доступе к переменным типа BOOL ИМХО регулирование доступа вообще теряет смысл, потому как “… пол мальчика не продается…”. В остальном, просто следует учитывать, что “процесс” в объектно ориентированной среде тоже должен рассматриваться как объект и устойчивость совокупности происходящих в нем переходов не должна зависеть от комбинаций состояний разделяемых ресурсов, в противном случае критический ресурс должен быть в самом процессе. То есть продумать декомпозицию необходимо. Вообще, на мой взгляд весьма полезно почитать Гради Буча “Объектно-ориентированный анализ и проектирование”. Книга в общем то не о многозадачности но концептуально подразумевается что подход как раз и должен обеспечивать стабильность как раз в этом случае…