CRIO stops responding during FTP

[fsahmed]

Hello,

I have a realtime application on CompactRIO 9022, which shares a .csv file with an external website through FTP. There are two file transfer modes; in the first mode, the file is updated by the labviews RT VI, and is transferred to the site's ftp server using labview's FTP PutFile VI. In the second mode, the file is updated by the website, and is acquired by the RT VI using FTP GetFIle VI. The problem is that in both these modes, the VI hangs and I get "Waiting for Realtime Target to respond". 

Already Tried:

Ran Trace, the processor remained at 24%, memory 40%. No peaks anywhere before or after the target got hanged. 

Doubt: 

Could it be due to the fact that no checks have been placed upon whether the file is open or not, at the time of transfer??? 

Thanks in advance for ur help,

[User002]

Perhaps this thread can give you some leads:

http://forums.ni.com/t5/LabVIEW/System-timout-when-reading-data-from-cRIO9073/m-p/2188462

Br,

/Roger

[timtamslam]

Can you manually FTP files off of the target to a desktop machine without any problems? (I'm trying to isolate whether the issue is specific to the communicating with the external website) I would use any one of the options listed in this white paper:

FTP Options with LabVIEW Real-Time (I find that through a web browser is easiest)

http://www.ni.com/white-paper/3365/en

Have you tried using binary transfer mode instead of ASCII? You can switch these using the boolean input at the bottom of the VI. I've seen this clear up some issues before. 

If I had to guess, this is what I think is happening. It sounds like the RT processor is looking to FTP the file to the server but it is being denied. As the RT controller continues to send the file, the ethernet port buffer is filling but not being cleared out properly by the FTP server. This would make sense in the circumstance of a minimal processor usage and a "Waiting for Realtime Target to respond" (I'm guessing you're running this VT interactively from the host desktop, correct?). With the ethernet buffer filling with unhandled FTP packets, the Desktop computer can no longer communicate with the target. 

I've very curious to see if the basic tests I mentioned before are successful. Hope this helps!

[Mugur]

Hi all

Apologies for posting on a slightly remotely related issue, but I want to avoid filing a ticket.

My problem: I cannot access the cRIO via FTP client at all.

Previously I used Filezilla Client to replace the rt.exe.

Recently I tried it again but the client would not connect at all. Tried alternative client as well.

The cRIO is in a remote location and therefore I can't connect via a development computer. I am limited to remote controlling the Windows PC that acts as a data logger (executable application).  

Can it be due to some intensive activity of the controller? I've tried to flip the 'no app' microswitch to no avail (someone did it for me at the remote location)

any help much appreciated,

thanks

Mugur