05-10-2013 09:50 PM
How do I tell FTPClient.exe the target address when I start this executable with System Exec.vi in Labview? I do not want to reinvent the FTP File utility that MAX uses with real time targets. I want to start this executable from a labview support utility without going through MAX to do it.
Can this be done?
Solved! Go to Solution.
05-11-2013 10:17 AM
Since the RT hosts an ftp server, you should be able to use system exec from your PC to do this. Also, if you have the internet toolkit, you have FTP functions available, and will also have examples of using them in the LabVIEW help.
05-11-2013 11:44 PM
Thanks for the response. What occurs when I use system exec to execute FTPClient.exe, it does not recognize the URL for the target. The control on the front panel is empty. Since the target is on the internet, I reasoned that the FTPClient.exe needed the URL as an input to the executable at run time. I tried various ways of including the target URL using the inputs to system exec. vi but none of them worked. Maybe FTPClient.exe automatically attempts to locate the target URL and there is another problem with the internet connection.
So the question is "Does FTPClient.exe require the target URL at run time as an input?"
05-12-2013 09:42 PM
Why on earth would anyone choose to use FTPClient.exe? Okay, that was snarky, but honestly the better solution is to use FileZilla Client. It's free and sooo more fully-featured than FTPClient.exe. You can run FileZilla Client from the command line too (https://wiki.filezilla-project.org/Command-line_ar
05-13-2013 10:34 AM
This is pretty useful I didn't realize the FileZilla client had command line arguments. Off hand, do you know what the overhead of calling the system exec VI to do this stuff is as compared to the FTP functions in LabVIEW? I'm assuming it would be relatively negligible as related to the file transfer as a whole. I ask because I usually use the NI FTP functions, but am always having issues with little things that I end up troubleshooting (notably getting active/passive setting correct) and from what I can tell when using the FileZilla client GUI it handles this for you. If the command line arguments call functions that handle this stuff under the hood, I may consider writing a LabVIEW wrapper for them.
I'd be interested in your thoughts.
Also, on a side note, we met while I was at NI working on some PXI TCP driver troubleshooting stuff last October. Hope all is well.
05-13-2013 11:14 AM - edited 05-13-2013 11:19 AM
We actually evaluated using FileZilla Client instead of the FTPClient.exe, but at the time the command-line wasn't as fully-featured as it currently is. But, then again, we're looking to kill FTP sometime in the future in favor of a more secure method of transferring files (can't comment much more on that) - once we're done making up our mind we'll switch to a client tool (whether we use a common free one or develop one ourselves) that can handle all supported methods of communication.
Okay, so your question was in regard to using the FTP functions versus the FileZilla Client. Well, the two sets of tools are designed for two different scenarios - the FTP VIs are designed for programmatic use, and the FileZilla client would be for manual use; FileZilla Client can only launch and connect to a server via the command line, it can't actually perform transfers via the command line (that has to be done manually). Both tools should only be used for occasional FTP usage to/from a target, you should always be mindful not to use FTP too much to/from a target; the danger is that both PharLap and VxWorks systems have a fixed pool of sockets, and each FTP transaction (using FTP VIs or using FileZilla Client) uses an individual socket - you cannot reuse that socket until it completes, which can take up to 2.5 minutes. So, if you hammer the target with FTP requests you may be put into the "penalty box" and won't be able to communicate with your target until a socket becomes available on the target again. FTP transfers within MAX use one socket per SESSION, not one socket per file, so while it's a little slower (since files are transferred serially) it doesn't blow out your socket pool when transferring tons of files.
05-13-2013 11:59 PM
Thanks for the info. Your "snarky" response "suggests" an answer to my question. However the complete answer to my original question is that it is not possible to use FTPClient.exe outside of MAX. Therefore it is not possible to pass in the target address at run time if the FTPClient.exe is run external to MAX. FileZilla is a good choice - there are other FTP clients out there too, but you have pointed out a robust choice. Thank you.