Глобальные переменные

Философский вопрос
Можно обойтись. Но:
1) если переменные действительно общие и логически не принадлежат ни одной задаче, (например время суток) то логично им быть глобальными с объявлениями отделенными от задач?
2)концепция глобальных переменных проста и понятна. Их обожают начинающие. Хочется писать понятные программы, дабы иметь возможность скинуть с себя сопровождение.
3)развитие глобальных переменных вылилось в сетевые переменные. Задачи можно раскидать по нескольким ПЛК. Их глобальные переменные просто объявляем сетевыми.
4)в ПЛК всегда есть глобальные переменные, как минимум это образы входов/выходов.
5)в системах с реальной многозадачностью (такое бывает в ПЛК), одна задача может сбойнуть/подвиснуть и будет снята. Лобовое обращение типа T1.var1 тут потенциально опасно.
В идеале задачи вообще должны быть независимыми. В будущей редакции стандарта МЭК 61131-3 даже вырисовывается такая штука как приложения. Это очень крутые задачи с индивидуальными образами входов/выходов, которые можно автономно останавливать, запускать, изменять и отлаживать. Получается несколько виртуальных ПЛК в одном.
Стратегически, лучше бы общие переменные запихнуть в некие объекты (блоки) и снабдить их интерфейсом для обеспечения целостного безопасного доступа всеми. Но это уже ООП, что опять же, относится к будущей редакции стандарта МЭК.

Задачи МЭК запускаются как нити. При вытесняющей многозадачности всегда есть опасность работы с общими данными. 1 оператор МЭК программы может разворачиваться в несколько в машинном коде, особенно при программной реализации реал и длинных типов, более приоритетная задача может влезть и все испортить. Конечно, тут нужны семафоры и пр.
ИМХО 99% МЭК программ однозадачные. Для CoDeSys я видел всего 2 реальные огромные МЭК программы с десятками циклических и событийных задач (авторы команды из Германии и Италии). Поэтому возникает вопрос, стоит ли эту тему вообще обсуждать применительно к программированию ПЛК? Широкого отклика это не имеет.

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

Ну мы же пишем правильные МЭК программы, без трюков извращенских . Все переменные размещает компилятор статически. Он четко следит за пересечением областей. Хороший компилятор даже умеет генерить исключения при залезании в чужую память, даже при попытке записи в массив за его пределы. Глобальные /локальные – области видимости. Они помогают людям избежать ляпов.

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

Не всегда. 1) ПЛК может иметь 8 или 16 бит проц. Для него простое сложение двух DINT это 20-30 машинных команд. Есть бит проц с эмуляцией мат сопроцессора. 2) Умножение REAL может состоять из 200 машинных команд. 3) Совсем нежданно: в PC совместимых и многих др. проц. нет битовой памяти, запись дискретного выхода (1 бит) у них это несколько команд. 4) Может одна задача проверить значение атомарной переменной на допустимость (например, <> 0) и спокойно перейти к своим вычислениям (например, делить нечто на ее значение) или логическим последовательностям, и в этот момент другая задача возьмет и изменит переменную (допустим, обнулит) и полный капут. Оттестить такие штуки не реально. Может год работать, а под куранты сделать бах. Можно и еще хуже примеры придумать. Они есть в литературе для программистов по многозадачным системам. Для МЭК тут особой специфики нет.

Первоначально опубликовано Максим Ананских Ну мы же не будем всерьез рассматривать 8-разрядные ПЛК?

Стратегически ДА, но... Изначально при разработке CoDeSys V3 была установка не поддерживать 8 и 16 бит системы. Однако эволюция развивается по спирали. Появились распределенные системы, программируемые реле, параметризованные устройства и др. простейшие. Все это массово делают на AVR, PIC и Infineon C16x. Хотим, не хотим, заказчикам надо. Короче, 16 бит компилятор уже сделали... + Стандарт МЭК не ограничивает разрядность проц.

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

Нет. Рассмотрим установку 1го бита в 32 бит системе (проц. общего назначения). Машинные команды: 1)прочитать 32 бит ячейку памяти в аккумулятор, 2) логическое ИЛИ аккумулятора с маской (и вот тут упс, другая задача эту ячейку памяти поменяла) 3) записать значение из аккумулятора в память (и испортить результат второй задачи).

Первоначально опубликовано viktorz Можно ли вообще обойтись без них? в каком случае без глобальных переменных не обойтись. Скажем создал две задачи и одной цикл 10 мс (T1) , у второй 1сек (T2). Что обмениваться данными между задачами можно же в задаче T2 написать T1.var1, где var1 - внутренняя переменная задачи T1. Попробовал работает. точно также и с массивами. Заранее спасибо.

Три четыре месяца назад были созданы подобные алгоритмы. В системе не предусматривающей синхронизации доступа в принципе. Захватом и инкапсуляцией данных на начальном этапе так же пренебрегли. Мотивировали сие тем, что в результате применения новейших нано технологий мультизадачный контроллер сам все разрулит.
Два алгоритма выполняются раз в секунду. Один из алгоритмов периодически пишет переменную типа BOOL в другом. Результат: Вчера доподлинно установил, что переменная меняется по ходу выполнения алгоритма потребителя, нарушая его работу. Периодически переменная вообще не воспринимается алгоритмом потребителем приводя к редким "окнам" в выполнении. Вывод: При взаимодействии двух независимых задач (процессов) применение синхронизации, инкапсуляции, методов Invoke (запроса на обработку или подобных механизмов основанных на событиях) могут быть не всегда очевидными. Но их отсутствие приводит к очень трудно отслеживаемым ошибкам...