Модели поведения в CODESYS 2.3

[capzap]

http://www.owen.ru/forum/showthread....l=1#post282567

ни чего не понял, в обоих случаях исследуете код тела цикла, только в первом варианте красочно расписываете как всё плохо, а во втором зачем то сделали свой REPEAT, хотя если в теле такие же проблемы как и в первом варианте то разницы между обеими вариантами нет
Теперь если использовать REPEAT и перед ним принудительно переменной присваивать FALSE то код выполниться один раз, если не активировать условие цикличности внутри тела, а если это будет функция, то и фальш присваивать не обязательно.
И к тому же такие способы диагностики некорректного кода больше подходят к чужому коду а не собственному, вот пользуясь случаем хочу спросить про Вашу подпись, какими тестами пользуетесь в КДС, мне например не встречались, сам я только записывал нужные значения в фифо

[Осинский Алексей]

И к тому же такие способы диагностики некорректного кода больше подходят к чужому коду а не собственному

В первую очередь - да. По работе, иногда, приходится читать чужой код.
Но и свой, написанный давно, код можно сходу не разобрать. Не знаю, как у Вас, но у меня с течением времени подход к проектированию меняется. Иногда смотрю на свой код 3-6 летней давности, и думаю, "зачем так написал? можно же было вот-так... и было бы лучше, быстрее, понятнее (ненужное зачеркнуть)".

Вот пользуясь случаем хочу спросить про Вашу подпись, какими тестами пользуетесь в КДС, мне например не встречались, сам я только записывал нужные значения в фифо

Для тестирования модулей (ФБ, функций) на текущий момент использую самописные тесты.
и для CDS2 и для CDS3 подход схожий (ниже тестируется некий ФБ для управления прожектором):
1) Объявляю структуру, содержащую желаемые значения входов и выходов тестируемого ФБ

Скрытый текст:

TYPE SpotlightTest :
STRUCT
	eDirection				: SPOTLIGHT_DIRECTION;
	eSensorsState				: END_SENSOR;
	xNeedToTurnOn				: BOOL;
	eCurrentDirection			: SPOTLIGHT_DIRECTION;
	xIsTurnedOn				: BOOL;
	xIsMoving				: BOOL;
	xDirectionChanged			: BOOL;
END_STRUCT
END_TYPE

2) Реализую функцию, назначение которой:
2.1) Установить значения входов;
2.2) Вызвать тестируемый ФБ;
2.3) Сравнить значения выходов с ожидаемыми;
2.4) Вернуть TRUE, если состояние выходов ФБ равно ожидаемому, иначе вернуть FALSE и записать сообщение в лог с сообщением о том почему тест провален

Скрытый текст:

Интерфейс

(*
Задает состояние входов ФБ типа prv_FastOutPulseGenerator по адресу pfbFopgToTest.
Вызывает его и проверяет состояние выходов.
Если состояние выходов не соответствует ожиданию - добавляет запись в лог.
Возвращает TRUE, если состояние выходов соответствовало ожиданию.
FALSE во всех остальных случаях
*)
FUNCTION AssertSpotlightOutputs : BOOL
VAR_INPUT
	sModuleName				: TestMessage;		(* Название теста *)
	pfbSpotlightToTest			: POINTER TO Spotlight;
	stTestToExecute				: SpotlightTest;
END_VAR

Реализация:

AssertSpotlightOutputs := FALSE;
IF pfbSpotlightToTest = 0 THEN
	AddMessageToTestLog ('AssertSpotlightOutputs', 'Некорректный указатель на ФБ');
ELSE

	pfbSpotlightToTest^.eSensorsState := stTestToExecute.eSensorsState;
	MoveSpotlightToDirection (pfbSpotlightToTest, stTestToExecute.eDirection);
	pfbSpotlightToTest^.xNeedToTurnOn := stTestToExecute.xNeedToTurnOn;

	pfbSpotlightToTest^();

	IF pfbSpotlightToTest^.xIsTurnedOn <> stTestToExecute.xIsTurnedOn THEN
		AddMessageToTestLog (sModuleName, 'Некорректное состояние xIsTurnedOn');
	ELSIF pfbSpotlightToTest^.eMoveDirection <> stTestToExecute.eCurrentDirection THEN
		AddMessageToTestLog (sModuleName, 'Некорректное состояние eMoveDirection');
	ELSIF pfbSpotlightToTest^.xIsTurnedOn <> stTestToExecute.xIsTurnedOn THEN
		AddMessageToTestLog (sModuleName, 'Некорректное состояние xIsTurnedOn');
	ELSIF pfbSpotlightToTest^.xIsMoving <> stTestToExecute.xIsMoving THEN
		AddMessageToTestLog (sModuleName, 'Некорректное состояние xIsMoving');
	ELSIF pfbSpotlightToTest^.xDirectionChanged <> stTestToExecute.xDirectionChanged THEN
		AddMessageToTestLog (sModuleName, 'Некорректное состояние xDirectionChanged');
	ELSE
		AssertSpotlightOutputs := TRUE;
	END_IF
END_IF

3) Пишу ФБ-тесты (1 ФБ - 1 тестируемая концепция), в которых
3.1) массив структур SpotlightTest заполнен в соответствии с тем, что хочу протестировать
3.2) Происходит последовательный вызов функции из п.2 и передача ей необходимого теста и ФБ

Интерфейс ФБ примерно следующий::

VAR_OUTPUT
	xDone					: BOOL;
	xBusy					: BOOL;
	xPassed					: BOOL;
	xFailed					: BOOL;
END_VAR
VAR CONSTANT
	m_c_sModuleName			: TestMessage					:= 'Spotlight.EndPositionTest';
	m_c_usiTestStepsCount		: USINT						:= 9;
	m_c_astSteps			: ARRAY [1..m_c_usiTestStepsCount] OF SpotlightTest :=
		(eDirection := DIRECTION_TOPLEFT, xIsMoving	:= TRUE, xDirectionChanged := TRUE, eCurrentDirection := DIRECTION_TOPLEFT),
....

Ну а наполнение, думаю, понятно.

4) Дело за малым - вызывать тесты по очереди.

Для CODESYS 3.5 разрабатываю библиотеку, чтобы уменьшить количество написанной вручную обвязки.
Но, пока что, она не на той стадии готовности, когда ее можно показывать людям.

А для тестирования проекта в целом использую Process Simulator (ПО бесплатно, с открытым исходным кодом).
Такая мини-скада, основная задача которой эмулировать поведение исполнительных механизмов.
Есть возможность писать свои скрипты на C#.
Все никак руки не дойдут до написания статьи на эту тему.