ПЛК объектно-ориентированное программирование - использование методов

Question

Я пишу программу для ПЛК Schneider с использованием структурированного текста, и я пытаюсь сделать это, используя объектно-ориентированное программирование.

Будучи новичком в программировании PLC, я написал простую тестовую программу таким образом:

okFlag:=myObject.aMethod(); 
IF okFlag THEN 
    // it's ok, go on 
ELSE 
    // error handling 
END_IF  

aMethod должны выполнять некоторые операции, ждать результата (есть «Тайм-аут» проверить, чтобы избежать тупики) и возвращает ИСТИНА, либо ЛОЖЬ

Это то, что я ожидал, во время выполнения программы

1), когда okFlag:=myObject.aMethod(); достигнуто, код внутри aMethod выполняется до тех пор, результат не возвращается. Когда я говорю «выполнено», я имею в виду, что в следующем цикле сканирования выполнение aMethod продолжается с той точки, в которой оно было достигнуто раньше.

2) результат метода вызова проверяется и основной поток программы выполняется

и это то, что происходит:

1) aMethod выполняется, но поток программы продолжается. То есть, когда он достигает конца aMethod значения, которое возвращается, даже если события, которые aMethod должны ждать, все еще выполняются.

2) на следующем цикле, aMethod вызывается снова и перезапускается с самого начала

Это первое решение, которое я нашел:

VAR_STATIC 
    imBusy: BOOL 
END_VAR 

METHOD aMethod: INT; 

IF NOT(imBusy) THEN 
    imBusy:=FALSE; 
    aMethod:=-1; // result of method while in progress 
ELSE 
    aMethod:=-1;   
    <rest of code. If everything is ok, the result is 0, otherwise is 1> 
END_IF 
imBusy:=aMethod<0; 

и основная программа:

CASE (myObject.aMethod()) OF 
    0: // it's ok, go on 
    1: // error handling 
ELSE 
    // still executing... 
END_CASE 

, и это, похоже, работает, но я не знаю, правильно ли он подходит.

Есть несколько библиотек от Schneider, которые используют методы, которые возвращают логическое значение и, похоже, работают так, как я ожидал в своей программе. То есть: когда цикл достигает вызова метода в первый раз, поток программы «отклоняется» каким-то образом, так что в следующем цикле он снова вводит метод до его завершения. Это способ иметь такое поведение?

Answer 1

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

Как правило, я бы рекомендовал, если вы собираетесь использовать этот подход, - попытаться отделить свой автомат от своего рабочего кода; вы можете реализовать конечный автомат с шагами X, а затем привести свой рабочий код к этапу statemachine.

Простой пример может выглядеть следующим образом:

stepNo := 0; 
IF (start AND stepNo = 0) THEN 
    StepNo = 1; 
END_IF; 

(* there's a shortcut unity operation for resetting this array to zeroes which is faster, but I can't remember it off the top of my head... *) 
ActiveStepArray := BlankStepArray; 

IF stepNo > 0 THEN 
    IF StepComplete[stepNo] THEN 
     stepNo := stepNo +1; 
    END_IF; 

    ActiveStepArray[stepNo] := true; 
END_IF; 

Тогда в других разделах кода вы можете поставить ...

IF ActiveStep[1] THEN 
    (* Do something *) 

    StepComplete[1] := true; 
END_IF; 

IF ActiveStep[2] THEN 
    (* Do Something *) 
    StepComplete[2] := true; 
END_IF; 

(* etc *) 

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

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

Надеюсь, что это поможет.

Answer 2

Почему бы не использовать SFC, это делает вашу жизнь проще во многих случаях, так как это язык автомата. Сделайте подпрограмму, состояние ожидания сделайте еще ... rince и повторите. :)

Не зависайте только для ST, другие языки IEC лучше в некоторых других задачах и держите вещи как можно более ясными. В кругах программирования ПЛК должно быть не так много менталитета «это мой торт», поскольку он относится ко многим другим областям программирования, так как временной шкале приложений может быть 40 лет, и вы покинули фирму 20 лет назад, чтобы улучшить работу, а программы почти всегда местоположение/клиент или по меньшей мере аппаратное обеспечение.

http://www.automation.com/pdf_articles/IEC_Programming_Thayer_L.pdf