Issue with FILE_READ() AXC F 2152 not work correctly

[jjimenez]

Hi nextmates. I have a issue when try read a file with AXC F 2152 in PLC Enginner. Now i use this code for read a file of 18 bytes and save on personalized struct. When try read file, read nothing and not get a error. The file have data. When i write a file. the program create a file in same directory from i read. This is code example, only run in warm init. FILE_OPEN1(Execute:=TRUE,Name:=‘p.bgn’);

FILE_READ1(Execute := FILE_OPEN1.Done, Handle := FILE_OPEN1.Handle, LengthRead => lalala, Buffer := Plc_conf, MaxLength := 50, Error => Errore, ErrorID => errorecode);

FILE_CLOSE1(Execute:=FILE_READ1.Done,handle:=FILE_OPEN1.Handle); Thanks for advance.

[Eduard_PLCnext_Team]

Hello jjimenez, In a test with the AXC F 2152 with FW 2019.6 is the FB working correctly (see screenshot below). The error and status 10 on the Read FB only indicates that the end of the file has been reached. This behavoir is similar to cpp reference of “fread” function, please see description of “Return Value”: http://www.cplusplus.com/reference/cstdio/fread/ Best, Eduard

[jjimenez]

Thanks very much. I try with this code read the ‘p.bgn’ but read 0 bytes, i need only 1 read cycle when boot plc. while i go test you example.

[Eduard_PLCnext_Team]

Hello jjimenez, please test the showed example and if needed you can also implement it in ST-Code. Please note, the ESM-Task/Program will be started after successfull PLC-Boot. Best, Eduard

[jjimenez]

I a lot sorry for reply so later. I was testing the Eduard example but i see that FILE_READ block get a error. From this example translate the program to Struct Text(ST) with help of Spain phoenix contact support. We saw not possible execute all lines 1 time. every read need n times of execution for read correctly the file. Now i can read file without problem but not understand how work this functions blocks. Best regard.

[Martin_PLCnext_Techn]

Hello, If I am reading your code correctly, you are counting the total number of scan cycles for all the File I/O functions to be completed, in sequence. Four scan cycles does not seem to be excessive in this case. If you are expecting that the complete sequence of function block calls will be completed in one scan cycle, then you are expecting each of the function block instances to block the real-time task until they are complete. This would be bad, because potentially long-running processes (like File I/O) could take significantly longer than the scan cycle time. So what is probably happening in this case is that each function block instance spawns a worker thread to perform the requested operation (file open, read, close), and then immediately returns to allow the task processing to continue. So even if each file operation is super-fast, each of them will still take one scan cycle to complete. Hope this helps explain the behaviour you are seeing. Martin.