FTP Problems... 3-4 minutes for transfer

[Megan B.]

Hi technomage,

I've had trouble replicating the slow transfer behavior you are seeing.  I used the VI that you posted and ran it on both an 8176 and an 8186 (no 8184s handy).  I was able to transfer a 3MB file in about one second.  The controller is set to autonegotiate.

I was ftping to the NI FTP site, ftp://ftp.ni.com/incoming.  Can you try using your VI to transfer the file to this ftp site?  Also, I'd like to make sure that you aren't experiencing similar slowdowns when running the VI on your host machine instead of your controller.

Thanks,
Megan B.
National Instruments

[technomage]

Hi Megan. Thanks for your reply. It may be difficult for me to connect to the Internet and perform this transfer. I will see what I can do.

In the meantime I have the following situation. I have two 8184's, running RTOS, and a laptop connected through a router/switch. No Internet connection. A few weeks ago I had built a vi, which performed very well. It generated a timestamp for the filename, stored the data on the HD of the 8184, and when the data aquisition was finished it would then do a "PUT" over to the laptop, and finally delete the file on the 8184. The transfer was only taking about 1 second after the aquisition was finished.

I moved on to other things for a few days. Then I fired it up again and saw these 3 minute transfer times. Since then I have tried to transfer, using GET or PUT vi's as required, in both directions, laptop to 8184, 8184 to laptop, and tried this on both 8184's. I have also tried the Multiple GET and Multiple PUT vi's to see if they worked differently. I may see if I can set it up to transfer from one 8184 to the other...

I have watched it with execution highlighting turned on and I see that the FTP function blocks all seem to take about 25 seconds to complete, after they have all parameters sent to them. 

My next step was to trim it down as far as I could, eventually down to the vi's I posted here. (Originally I was using FTP Open Session and FTP Close Session, as well. When I looked inside the Get and Put functions I saw that they actually take care of these functions anyway.)

As I mentioned in my posts, I have a network analyzer which captures ALL packets on the network interface card. I examined these and I saw that there simply isn't any communications during these mysterious wait times. Not even UDP or anything else. I verified this by watching the activity lights on my switch.

Next I spent about a day researching the various parameters I can apply to the FTP server on the laptop, but found nothing unusual. I have tried Active and Passive, Binary and ASCII, Autonegotiate, half-duplex, and full-duplex, but the response is the same.

Then I fired up WS-FTP graphical ftp client software to see how it would perform. All is normal. It will transfer almost instantly. Next I went to the command line on the laptop. Again, it will transfer as fast as I can type the commands.

I am more or less convinced that the problem lies somewhere on my laptop, but it only shows up when a vi is controlling the transfer.  I think I will have to load Labview on to another computer to see if it is the laptop or not. Unfortunately I have it registered on the laptop.

Sorry for the long post, but I do like to provide as much info as I can.

technomage

[technomage]

After some experiments I carried out today I am now convinced my problem lies with the National Instruments FTP service running on the RTOS chassis units.

Today I disabled the Microsoft Windoze FTP service. Then I loaded WS-FTP Server and set it up to start on Windoze startup. I used the command line to verify that it was started and running. Then I specifically set up a "User and Password", rather than using anonymous.

I ran my transfer vi's again, and again it took almost 3 minutes. Dissection of the packets again shows me that the laptop FTP server is simply waiting for a reply from the NI chassis FTP service. Each wait is around 25 seconds. Send USER, wait 25, send PASS, wait 25, set ASCII, wait 25, set PORT, wait 25, send RETR filename, wait 25, send QUIT wait 25, logout.... Very Nice!

Unless someone can tell me how to get at the configuration of the FTP service on the RTOS chassis, I guess I will have to abandon FTP transfers. This causes me to seriously re-think the usefulness of Labview as it applies to my project. I guess possibly I can abandon RTOS and run Windoze on the chassis units... Maybe FTP will work better that way...

[Megan B.]

Hi technomage,

Did you have a chance to try it from another computer?  You don't need to worry about installing LabVIEW on a second computer, it's fine for these debugging purposes.  Also, have you tried reformatting your RT controller and reinstalling the software?

Thanks so much,
Megan B.
National Instruments

[technomage]

Hi Megan. Thanks again for your time. I haven't figured out how to run it on another computer, or try FTP over the 'net. I simply don't have the resources.

Today I tried replacing the file "ftpserve.dll" on one of my RTOS chassis, with the same file on my laptop. It made no difference. I also looked inside EVERY ini and dat and cfg file I could find to see if I could find somehting that tells the RT FTP client how to behave. I can't seem to find anything. I can configure the Microsoft FTP service when I boot into XP, but any changes I make there won't have any effect on the FTP client which runs when I am running the chassis in RT. I just cannot seem to find the parameters which get passed to this command line FTP client.

Still hunting down this problem...

technomage

[technomage]

I have come to realize that I have no less than 5 different ways I can open an FTP communications link from the laptop to the RTOS chassis.

1. "DOS" Command Line.

2. MAX File transfer utility

3. Internet Explorer

4. WS-FTP Pro

5. Programmatically with my vi's.

The first 4 work flawlessly and amazingly fast. I believe that they would all use the same FTP utility at the RT Chassis end. However when I use vi's, I see this 25 second wait time between FTP commands. I would really like to figure out what this problem is, because much of the application I am trying to develop depends on FTP transfers.

Megan suggested formatting the HD and reloading everything, but I would prefer it if I could find the problem files (or configuration) and simply fix them. Are there any FTP gurus employed by NI? Somebody must have had this before... Anybody?

technomage

[Kevin_Price]

Meanwhile, there's a potential work-around using "System Exec.vi" to perform an FTP file transfer from the "DOS" command-line.  We did our file transfers this way a few years back when we didn't have the programmatic FTP vi's.

You'll probably need to play around a bit and learn how to parse out success and error text, but it certainly can be done.  I don't recall now whether we issued an FTP 'put' from the RT side or an FTP 'get' from the host side.  If the latter, you'll need some sort of signaling system to alert the host that the RT system has a file ready.

Another semi-ugly idea would be to send the file through TCP/IP.  The RT side could read file chunks as raw bytes (array of U8 values), convert to string, and send vi TCP/IP.  The host side would receive the messages, convert to U8 arrays, and recreate the file byte-wise.

Good luck solving your problem so you can have an even better solution...

-Kevin P.

[technomage]

I FOUND IT !!!

The problem was buried 6 layers deep in subvi's!

1. I used FTP Put File.vi.

2. Inside that is FTP Put Multiple Files.vi.

3. Inside that is FTP Open Session.vi.

4. Next level is FTP Get Command reply.vi.

5. Then comes TCP Read xTP Reply.vi.

6. Last one - In here is TCP Read.vi. It one hardcoded parameter for the number of bytes to read, which is set to 2048. Also there is an ENUM which has the following selections:

a) Standard (default)

b) Buffered

c) CRLF

d) Immediate

I discovered that to solve my problem I had to change the ENUM value to Immediate.

The Help states the folowing:

Standard - Waits until the bytes you specify in "bytes to read" arrive, or until "timeout ms" runs out. Returns the number of bytes read so far. If fewer bytes arrive it returns the partial number and reports a timeout. (The bytes to read was hardcoded at 2048, I was attempting to send it several MB, so I think it should have worked fine. It never did return a timeout, which is supposed to be internally set in this vi to 25 seconds.)

Immediate - Waits until the function recieves ANY bytes. Waits the full timeout only if the function recieves no bytes. Returns the number of bytes so far. Reports a timeout error if the function recieves no bytes.

I have no idea why this cropped up. The thing was set to Standard (default) when I found it. This vi did work a couple of weeks ago. Anyway, thanks to all who answered this post. I don't understand why this is the answer but it works now.

technomage