I copy a file from an C# Backend Service via FTPS on the FTP from our PLC.
99% of the time this works just fine.
But sometimes suddenly the file can not be read or copied manually from the FTP Server onto my Notebook.
If i copy the file from the C# backend folder via drag an drop onto the ftp via FileZilla it works ever time.
But i do not think the problem is the C# backend because they are using framework
components and do not get any error during the process.
After this Problem occurs, in generell the FTP behaves very strange.
Other Files on the Server can be copied or read but some of them are faulty because they have information in it from other files, like they are merged.
To solve this problem i have to do a intial installation of the plc!
I tried everything i can imagine of and now i do not know what to try next…
Delaytimes between copy and read, delete file if read was not possible and copy file again usw.
Is there anywhere a log of the ftp server? I can not find any entries in the AS LogViewer…
I copy a file from an C# Backend Service via FTPS on the FTP from our PLC. 99% of the time this works just fine.
That means storing files on FTP server does not always work ? What means to ‘copy’ ?
And you always do this with the C# backend ?
But sometimes suddenly the file can not be read or copied manually from the FTP Server onto my Notebook.
That is reading file from FTP server ? What does ‘copying manually’ mean ?
And this always works when using Filezilla ?
After this Problem occurs, in generell the FTP behaves very strange.
which client is connected then ? Filezilla or C# backend ?
Other Files on the Server can be copied or read but some of them are faulty because they have information in it from other files, like they are merged.
Also with Filezilla ?
To solve this problem i have to do a intial installation of the plc!
so just restarting the PLC is not enough ? Did you try to read the faulty files by examing the CFast ?
I tried everything i can imagine of and now i do not know what to try next…
Perhaps it is an reasonable try to isolate the problem from your C# backend e.g. try to reproduce the issue with FileZilla or use WinSCP which can be used as a command line tool in an automated environment ?
The Files are generated by the C# backend on the APC and also stored on the APC. If we trigger a Load on the Frontend,
the backend copies the file from the APC on the FTP of the SPS. Then we read the file with the FileIO Fbs.
When the error occurs, the FileRead FB returns that he has no access to the file.
Then if i try to copy the file with FileZilla from the FTP on my Notebook to be able to read it,
FileZilla tries to do it but stops the Download with an error.
If I try to delete the File on the FTP with FileZilla it works just fine.
Then if I trigger the load via the frontend again I have the sam problem again.
Both because of my debugging. Before the issue happens, only the backend.
After the problem occurs, every time I have a File transfer from the backend or from the plc
on the FTP, files are getting merged. Some parts of one file appear suddenly in other files and so on.
I have to try but because this happened on an commissioning project I had to do
the initial installation to be able to continue.
The issue is so rare it is very hard to track…
A Reboot is not enough. Also a shutdown is not enough. I even tried to disable and enable the FTP
after we have the issue with the B&R FB for the FTP.
Bbut well we can’t rule out your specific C# backend as the source of the error at this point.
I would focus to isolate the problem.
For example, generate the files using the backend, but use a ready-made FTP client (e.g., WinSCP) to transfer them.
That would also make it easier to reproduce the error.
Analysing the files by directly accessing the drive (CF Reader) could also give some new hints.
We might also gain new insights if we use FTP instead of FTPS. That would also allow you to capture the traffic using Wireshark.
And always: hardware information, version numbers and error codes are often helpful.
There may have been an issue that has already been resolved in newer versions of the AR.