Существует ли в CoDeSys v.2(v.3) альтернатива #if defined

[Вова]

Здравствуйте!

В языке Си есть директива #if defined, говорящая препроцессору компилятора, что следующий код нужно компилировать в машинный код (прошивку) или нет, исходя из некоего условия. Пример:
В начале программы

#define a
//#define b

Условие "a" установлено, условие "b" закомментировано.
Далее, где-то в программе

#if defined (a)
	ANCON0 = 0b01001100;
#else
	ANCON0 = 0b01000011;
#endif

Здесь если установлено условие "а" откомилируется в состав прошивки выделенная красным строка, иначе - выделенная зелёным. Таким образом очень удобно, например, писать код, который будет работать на разных процессорах, описав все различимые вещи в подобных #if defined, а условием выбирая нужный процессор. И смена целевого процессора производится закомментированием всех остальных и выбором одного, то есть пара нажатий кнопок.
Теперь собственно вопрос. Есть ли в кодесис подобная возможность быстрой смены части конфигурации, программы и описания переменных? Т.е., можно ли сделать две альтернативные части конфигурации, скажем, для условия "release" переменные "Right", "Up", "Vertical" и тому подобные сконфигурированы как дискретные входы/выходы ПЛК. А для условия "debug" эти же переменные сконфигурированы как биты входных/выходных переменных подчинённого модуля связи.
Сам вижу решение только в написании двух кусков блоков описания глобальных переменных и закомментирования ненужного целиком. В принципе не намного сложнее чем так, как привык, но это только если касается описания переменных, то есть одного куска. А если нужно по-разному настроить конфигурацию, по-разному написать часть программы, то есть в более общем случае?
В общем, есть какое-либо подобное решение такого вопроса? Спасибо заранее.

PS забыл в названии темы поставить знак вопроса, а отредактировать уже нельзя

[Вова]

Спасибо, а как это будет выглядеть на st? Графические языки плохо понимаю.

[Herzog]

Я бы тоже хотел иметь возможность условной компиляции.
Но не для кросплатформенности (такая задача не стоит и никогда не стояла), а для отладки - заменять аппаратные входные сигналы отладочными программными.
А то потом ищи в десятке мест, где вставил дебаговские затычки.

С уважением,
Herzog

[Вова]

Но не для кросплатформенности (такая задача не стоит и никогда не стояла), а для отладки - заменять аппаратные входные сигналы отладочными программными.
А то потом ищи в десятке мест, где вставил дебаговские затычки.

Кроссплатформенность просто в пример привёл, а так, конечно, тоже нужна именно возможность отладки.

a:=SEL(FLAG_DEBUG,REAL_RightSensor,VIRT_RightSenso r); или POU_FB(in:=SEL(FLAG_DEBUG,REAL_RightSensor,VIRT_Ri ghtSensor));
и т.д.

Честно говоря, ничего не понял. Мне нужно (пока только это), чтобы для каждого символьного имени входа и выхода, используемого в программе, было два объявления, одно вида:

RightSensor AT %IX3.0.0: BOOL; (* реальный вход *)

Другое вида:

RightSensor AT %IW8.0.0.0: BOOL; (* бит входной сетевой переменной, управляемый мастером *)

И чтобы переключать с "реальных" на "виртуальные" входы/выходы можно было "одной кнопкой". А использовать переменные просто:

IF RightSensor THEN... 

Без дополнительных сущностей. Такое возможно? Если нет, то всё понятно, и вопрос снимается, но если возможно, то хотелось бы об этом знать, чтобы не изобретать велосипед.

[Herzog]

вроде я про это и толкую, только вместо if-ов у меня sel, почитайте документацию

Sel тот же if, только в профиль.

Но условная компиляция имеет гораздо большие возможности.
Например, кусок кода:
#ifdef (флаг-условие А)
... 200 операторов ...
#else
... еще полсотни другого кода ....
#endif
не компилирует одновременно 250 строк, а - в зависимости от условия А - либо первые 200, либо вторые полсотни.

Если же использовать простой if, то Вам может прости не хватить памяти - как для программы, так и для данных. Если Вы отлаживаете запись в retain, то без условной компиляции придется компилировать два набора данных - один истинный, другой отладочный - и объема retain может не хватить.
Так что простые sel и if условную компиляцию не заменяют.

С уважением,
Herzog

[Николаев Андрей]

Если я все правильно понимаю - ни о какой условной компиляции речи идти не может - в контроллер заливается полностью скомпилированный, машинный код под конкретный тип ЦП.

[Herzog]

Если я все правильно понимаю - ни о какой условной компиляции речи идти не может - в контроллер заливается полностью скомпилированный, машинный код под конкретный тип ЦП.

Вы не правильно поняли.
Условная компиляция подразумевает различные варианты построения программы в соответствии с заданным условием.
Например, PLC работает в системе, используя входные сигналы от внешнего "железа", которого на момент отладки нет. В этом случае можно симитировать внешние сигналы программно, отлаживая другие части программы. Участок кода, выполняющий иммитацию, запускается в компиляцию при задании условной константы (например, #define USB_DEBUG), а когда дело дойдет до реальной отладки на "железе", то условие закоментируется (строка, #define USB_DEBUG комментируется) и компилируется настоящий, а не отладочный код - воспринимающий реальные сигналы со входов.

С уважением,
Herzog

[Вова]

Вы не правильно поняли.
Условная компиляция подразумевает различные варианты построения программы в соответствии с заданным условием.
Например, PLC работает в системе, используя входные сигналы от внешнего "железа", которого на момент отладки нет. В этом случае можно симитировать внешние сигналы программно, отлаживая другие части программы. Участок кода, выполняющий иммитацию, запускается в компиляцию при задании условной константы (например, #define USB_DEBUG), а когда дело дойдет до реальной отладки на "железе", то условие закоментируется (строка, #define USB_DEBUG комментируется) и компилируется настоящий, а не отладочный код - воспринимающий реальные сигналы со входов.

Совершенно верно. Правильнее было назвать тему "существует ли условная компиляция в кодесис". Странно, что

ни о какой условной компиляции речи идти не может - в контроллер заливается полностью скомпилированный, машинный код под конкретный тип ЦП.

ну да не мне судить стандарты МЭК. Если её нет, придётся извращаться.

Насколько я понял задавшего вопрос, его желание не снимать ПЛК с производства, а через ModbusTCP симитировать входные сигналы если потребуется. Все это будет подаваться с ПК, но не через КДС, поэтому раскоментировать отладочные функции и обратно будет проблематично.

Да, здесь всё верно. Конкретно то, что требуется сейчас, решается-таки относительно просто - в области глобальных переменных целиком комментируется блок либо присвоения реальным входам/выходам переменных "сенсоров" и "выходов", либо блок присвоения этим переменным адресов в области ввода/вывода по TCP. И так как контроллер работает в slave режиме, то переконфигурировать настройки связи не нужно (slave же сам не говорит, если его не спрашивают, поэтому проц в "реальном" режиме отвлекать не будет).
Но вот в случае, когда надо именно менять куски кода в зависимости от отладки/рабочего режима, либо настройки конфигурации, условная компиляция незаменима. Герцог сказал, повторюсь, условная компиляция работает на этапе так сказать прекомпиляции, грубо говоря это то же самое, что закомментировать один кусок кода и раскомментировать другой - скомпилируется только один кусок. Только у условной компиляции намного больше возможностей.
С той же конфигурацией, я вообще не вижу, как можно менять её настройки быстро и "одним махом" кроме как по одному ручками.

Мой же вариант, ПЛК слушает на своем слейв устройстве некий флаг, он всегда FALSE и только при отладке в TRUE. Далее в отличии от IF-ов, SEL можно вставить на вход любого функционального блока, функции и т.п. Причем его входами могут так же выступать блоки и функции, что позволяет уместить отладочный код хоть в 500 строк

Тут снова ничего не понял, нужно курить документацию, пока что спасибо. Но что-то кажется, что это даже не "не совсем то, что нужно", а "совсем не то, что нужно". Но может быть, ошибаюсь, надо почитать про эти SEL.

[Herzog]

ну да не мне судить стандарты МЭК. Если её нет, придётся извращаться.

И здесь более-менее приемлимой альтернативой могло бы стать использование системы контроля версий на уровне исходных текстов.

1. Вы пишете истинный код работающий на "железе", сохраняете его как очередную версию (скажем номер 17).
2. Далее пишите версию в отдельной ветке вариант с отладочным кодом. Сохраняете ее (допустим версия 18). Сохраняете файл различий версий 18 и 17.
3. Долго и нудно отлаживаете в ветке, начинающейся с версии 18, части программы, не связанные с железом (можно, я больше не буду ставить кавычки на этом слове?)
4. Сливаете ветку 18+ с веткой версии 17. Сливаете получившийся файл с файлом различий шага 2 и получаете отлаженный код, готовый к работе на железе.

Преимущество использования СКВ - она выделит Вам все различающиеся места и Вы не забудете ни одно из этих мест, как могло бы быть при редактировании вручную.
Однако все это чисто гипотетически, поскольку сравнения версий на уровне исходных кодов в CodeSys нет (Обсуждалось в этой теме).
Мне, например, приходится использовать изврат, для использования СКВ типа Tortoise SVN параллельно записывая файл проекта и его исходные коды через макрос.
После чего, поскольку проект не собирается из исходных кодов, вручную (Ctrl-Ins Shift-Ins) вставлять получившийся код в проект.

С уважением,
Herzog

[Малышев Олег]

В проекте можно исключить из компиляции один POU и включить другой - это конечно не так удобно как ifdef - но работать можно