Перегрузка функций в CODESYS

[RomeoVar]

Ничего пока не получилось.
А работает в CODESYS динамическое выделение памяти?
Я нашел библиотеку CMM (Codesys Memory Manager) Только там справка никакая.
Всего один FB - LinearMemoryManager и много методов. В частности есть Alloc, Free. И (как будто) конструктор - FB_Init
Только при попытке использования этого FB компилятор мне выдает "не найдено подходящего конструктора FB_Init для данного функционального блока"
А что я сделал не правильно я так и не понял. Поэтому от выделения динамической памяти я пока отказался
Но все-же - может кто скажет вообще можно работать с динамической памятью из CODESYS и как.
СОвсем на просторах интернета ничего не нашел

[Евгений Кислов]

https://help.codesys.com/webapp/_cds...rsion=3.5.17.0
https://help.codesys.com/webapp/fb_f...rsion=3.5.17.0

[RomeoVar]

В целом разобрался, нужно потестировать но ПЛК пока далеко. Пытаюсь на эмуляторе прогнать, однако при вызове FB FILE.GetSize сразу вываливается ошибка ASM_CREATEJOB_FAILED 5113 Job creation of AsyncManager failed
Эмулятор не поддерживает работу с файлами?

Вы уж не сердитесь. Просто много вопросов возникает по ходу "пЪессы". Платформа пока новая, в процессе изучения

[Евгений Кислов]

В целом разобрался, нужно потестировать но ПЛК пока далеко. Пытаюсь на эмуляторе прогнать, однако при вызове FB FILE.GetSize сразу вываливается ошибка ASM_CREATEJOB_FAILED 5113 Job creation of AsyncManager failed
Эмулятор не поддерживает работу с файлами?

Вы уж не сердитесь. Просто много вопросов возникает по ходу "пЪессы". Платформа пока новая, в процессе изучения

Эмулятор действительно не поддерживает работу с файлами.
Используйте виртуальный контроллер:
http://www.owen.ru/forum/showthread....l=1#post296706

[Евгений Кислов]

А что мне даст входной параметр eStructData если у меня будет только один входной параметр pStructData?

С помощью "одного входного параметра pStructData" можно передать в блок любые данные любых типов.

Но тогда нужно тщательно контролировать соответствие eStructData типу структуры входного параметра иначе меня будут ждать непредсказуемые "чудеса"]]

Это справедливое высказывание. Программирование - оно вообще во многом именно про "тщательно контролировать".

И еще вопрос по ходу: Тут по поводу указателей на экземпляры у меня вопрос - ведь процессор на самом деле 32 разрядный, а это значит что выборка по шине данных происходит, грубо говоря по 4 байта за один цикл чтения по шине данных. Соответственно если структура данных занимает неполных 32 бита, должно происходить выравнивание. Не произойдет ли "искажение" сохраняемых/получаемых данных если использовать POINTER TO BYTE а сами данные будут INT или того хуже FLOAT, или вообще какие-нибудь сложные структуры?

Выравнивание памяти в структурах есть.
Пользователь должен учитывать его при обработке структур.
См. также:
https://help.codesys.com/webapp/_cds...rsion=3.5.17.0

[RomeoVar]

С помощью "одного входного параметра pStructData" можно передать в блок любые данные любых типов.

Спрошу иначе. Какой тип pStructData будет объявлен в FB?

Я сделал так:

FUNCTION_BLOCK SaveDataToFile
VAR_INPUT
	sFileName		: STRING;
	pstDataMC		: POINTER TO MACHINE_CONFIG;
	pstDataRCP		: POINTER TO RECIPIES;
	pstDataDP		: POINTER TO DRIVE_PARAMS;
	szData			: UINT;
	eNameData		: STRUCT_NAME; 
END_VAR

А в коде FB я обрабатываю так (кусок логики):

FILE_WORK.WRITE:
		CASE eNameData OF
			STRUCT_NAME.MACHINE_CONFIG:
				fbFileWrite(xExecute:=TRUE, hFile:=hFile, pBuffer:=pstDataMC, szSize:=szData);
			STRUCT_NAME.DRIVE_PARAMS:
				fbFileWrite(xExecute:=TRUE, hFile:=hFile, pBuffer:=pstDataDP, szSize:=szData);
			STRUCT_NAME.RECIPIES:
				fbFileWrite(xExecute:=TRUE, hFile:=hFile, pBuffer:=pstDataRCP, szSize:=szData);	
		END_CASE
		IF fbFileWrite.xDone THEN
			fbFileWrite(xExecute:=FALSE);
			CASE eNameData OF
				STRUCT_NAME.MACHINE_CONFIG:
					wCRC16_std := MEM.CRC16_standard(pMemoryBlock := pstDataMC, uiLength := szData);
				STRUCT_NAME.DRIVE_PARAMS:
					wCRC16_std := MEM.CRC16_standard(pMemoryBlock := pstDataDP, uiLength := szData);
				STRUCT_NAME.RECIPIES:
					wCRC16_std := MEM.CRC16_standard(pMemoryBlock := pstDataRCP, uiLength := szData);	
			END_CASE
			enState := FILE_WORK.WRITE_CRC;
		END_IF
		IF fbFileWrite.xError THEN
			CASE enFileErr OF
				; //Обработчик ошибок
			END_CASE
		END_IF

МОжет можно проще, но я не понял как

[Евгений Кислов]

Спрошу иначе. Какой тип pStructData будет объявлен в FB?

POINTER TO BYTE, например.
Если для блока содержание структуры не имеет значения (например, нет необходимости ее парсить) - то eNameData вообще не нужен.

[RomeoVar]

POINTER TO BYTE, например.

А PVOID не лучше? Я просто с ним никак не разберусь. В Си есть тип переменной VOID, который как раз и используется в случаях когда заранее не известен принимаемый тип. Если это так, то PVOID будет лучше чем POINTER TO BYTE

[Евгений Кислов]

А PVOID не лучше? Я просто с ним никак не разберусь. В Си есть тип переменной VOID, который как раз и используется в случаях когда заранее не известен принимаемый тип. Если это так, то PVOID будет лучше чем POINTER TO BYTE

В CODESYS указатели фактически хранятся как переменные типа DWORD (для 32-битных платформ) или LWORD (для 64-битных платформ).
POINTER TO <TYPE> - это синтаксический сахар над этим DWORD/LWORD, который позволяет компилятору проверять соответствие типов при разыменовании и обеспечивать индексный доступ.
CAA.PVOID - это просто псевдоним (ALIAS) для типа __XWORD. Это платформо-зависимый тип, который на 32-битных платформах превращается в DWORD, а на 64-битных - в LWORD.

Поэтому принципиальной разницы между описанными вами вариантами для описанной вами ситуации я вообще не вижу.

[RomeoVar]

ТАк правильно объявлять переменную с таким типом правильно как ?

POINTER TO CAA.PVOID

или просто
CAA.PVOID т.к. это уже указатель?