08-23-2011 08:29 AM
I have an application running on a cRIO and PC at 8 different locations.
THe cRIO's log to tdms files 24/7, and the hostPC at each station FTP's the tdms files across at midnight everyday.
I am getting this error intermittently at some of the stations (the following string is from my error log (time errorCode ErrorString:
"8/23/2011 12:00:04 AM 1 TCP Write in NI_InternetTK_FTP_VIs.lvlib:FTP Command.vi:1->NI_InternetTK_FTP_VIs.lvlib:FTP [QUIT].vi->NI_InternetTK_FTP_VIs.lvlib:FTP Close Session.vi:3->getFilesFromCrio_subvi.vi->HostPC.vi"
It has the Error Code 1 which is pretty strange?
Any ideas why this would be happening intermittently? Also, and suggestions around this, or ways to handle this situation?
08-24-2011 01:56 AM
Maybe that is already fixed in LV2011 see http://zone.ni.com/devzone/cda/tut/p/id/13257 and look for ID
258485 | FTP VIs do not close session if there is an error |
Hope it helps
Christian
08-24-2011 05:42 PM
Hi markza,
Do you know if you are encountering any errors with your TCP Write? How are you handling your errors (are you logging them in any way)? If you are encountering an error, that may affect the FTP transfer-a bug that was fixed in LabVIEW 2011.
~kgarrett
08-25-2011 03:04 AM
I am logging the errors to text file after each state of my state machine - with a timestamp, code, error string and also the next state of my state machine.
I dont think that I'm getting a write error as all the data seems to be there every time, but as a rule, I always just log every error as it happens after every state, then i clear the error before it executes the next state. To add to this, no state is really dependant on the other states...so this method of error handling works for my application (in my opinion). Surely if I ever get a write error, it would propagate through (as I am wiring all the error terminals) and it would log that instead of the close session error?
Its rather intermittant, so maybe it is something NI's fixed with Labview 2011? Not too sure. I have downloaded Labview 2011, but it'll take a few days to get the new software to site.
08-25-2011 04:09 AM
Hi!
Is the file you are downloading through FTP open and used for logging?
Can be the problem due to concurrent access for writing and FTP reading?
08-25-2011 04:41 AM
Hmmm, it is possible yes. But on the cRIo side it only logs only every minute, so it opens the file, logs, and closes it straight away on the minute change.
There is a possiblility though that this could happen - where by some chance they clash. The cRIO isn't synced to the PC clock either, so the chance is remote. But yeah, you're right, it could definitely happen.
I'll try check it out. Could explain why its so intermittent.
05-16-2012 04:08 AM
I have the same issue. A cRIO is saving a tdms-log every minute and sends an UDP-telegram that a new log is created and ready. Then I made a desktop log fetcher that logs on with FTP and get the new file.
Seems to work for a while (sometimes for days), but then suddenly I get this error. To remove it I need to close the vi's so are out of memory then I can start them again and it works. In an application I need to restart the application to remove it or I will get the error for ever. So it looks like it goes into some state that it cannot recover from even as the FTP connection is closed between every attemt.
Anyone?
Error code 1:
TCP Write in NI_InternetTK_FTP_VIs.lvlib:FTP Command.vi:24->NI_InternetTK_FTP_VIs.lvlib:FTP [QUIT].vi->NI_InternetTK_FTP_VIs.lvlib:FTP Close Session.vi:2->NI_InternetTK_FTP_VIs.lvlib:FTP Get Multiple Files and Buffers.vi:1->NI_InternetTK_FTP_VIs.lvlib:FTP Get Multiple Files.vi->fetch files FTP.vi->LogFetcherTool.vi
05-17-2012 11:02 AM
Is this error particular to the code you have created? Have you tried any of the out-of-box example code for UDP communication? It would be good to know if it's something in the programming or an issue with your system altogether.
05-18-2012 06:27 AM
I used the UDP receiver and sender as a base. It is very basic and does work all the time while the FTP is haveing problems.
This said, I removed all UDP communication on the desktop VI's and I have not been able to repoduce the error after. So there may be something I'm doing wrong with the UDP that affects the FTP communication.
Workaround:
I made a FTP script to check if the log file date and time (Get Path Info.vi -> date) every 10 sec, if changed, get the new log.