How to send TDMS file using TCP/IP

[Texas_Diaz · Accepted solution]

For what you're trying to do, you're using the wrong VI.  

Think about what you're trying to do with respect to the target the VI is running on.  If you're running on the cRIO target, you want to use "FTP Put File" if you want to PUT a LOCAL FILE onto a REMOTE HOST (i.e. have the cRIO PUT a file onto the desktop PC).  If you're running on the PC, you could use the "FTP Get File" if you want to GET a REMOTE FILE and copy it to the LOCAL HOST.  

For the cRIO perspective, sending a file from the cRIO to the Host PC, you want to use the FTP Put File.vi - you're currently using the FTP Get File.vi.  

Also remember that from the cRIO perspective, you're placing the file into the remote account's directory - if you shared your desktop directory as your home directory for your LabVIEW user account, you can just provide the file name (with no path info) for the "remote file path".  

For example, I set up FileZilla Server on my PC to have a single user, LabVIEW (with no password).  I set my home directory to C:\Users\ddiaz\Desktop which is my desktop directory.  I had to set my local file to "c:\myfile.zip" and the remote file to "myfile.zip" - since my home directory for the LabVIEW account is my desktop, it will just use the desktop as the default directory.

EDIT:  I also had to make my home directory WRITEABLE, which is not enabled by default.  You do that from within the user window where you add directories for the user; click on the directory, and put a check in the WRITE box on the right.  

EDIT:  I also had to make the "ACTIVE" parameter on the VI set to "FALSE" so that FileZilla would use a Passive FTP connection (active connections didn't seem to work).  I also set the "binary" parameter on the VI set to "TRUE".

-Danny

[SEGIO]

Ok, I understand. But it's the same thing doing in a different way (I mean, the final result is the same). Yesterday I implemented finally the example of FTP Put file and it worked. On monday I will try the other way that you told me with FTP Get file. The next step is temporize sending file.

Thank you really much, your information was very useful.

[SEGIO]

The other day I finally could put the file from RT to PC. But I've a new problem now. This file that I transferred is a data acquisition, and I want to see if the values are the same. I put the file in a read from measurement file to read this data, but I get this error:

Error 8 occured at Read From Measurement File.

Possible reason(s):

LabVIEW: File permission error. You do not have the correct permissions for the file.

NI-488:DMA hardware error detected.

I've read some solutions to this problem but I can't solve it. I've tried to change binary to not binary but nothing changes. I've configured FileZilla as:

Files: read,write,delete,append (activated)

Directories: list, + Subdirs (activated)

Can someone help me?

Thank you very much in advance.

[SEGIO]

Solved, it was because I located the file in C:\ and I didn't have Total Control of the file.

On the other hand, FTP get file doesn't work. And I've some questions:

¿Why I have to put the local path if it's configured previously in FileZilla?

In the remote path, I should put the name of the file. The problem is that in FTP get file I don't put the direction of the file (and in my case is not exactly in C:\ RT)

Thanks

[Texas_Diaz]

The issue here is that you've got to remember who is talking to who.  There are two actors at play here - the FTP Client and the FTP Server.  In all cases, the FTP VI (no matter which one you're using) is the FTP Client.  The Client always must talk to a Server.  The user settings (from the login information) only come from the server - when using an FTP Client, it's assumed you have unrestricted access to the machine the client is on.  When an FTP Client talks to an FTP Server on a remote machine, the FTP Client only has access to whatever the FTP Server allows.  

So let's look at two scenarios:

FTP Get VI:

You use the FTP Get VI in order to talk to a remote FTP server to copy a file from the remote machine to the local machine.  On an RT target, the login has the root directory as the user directory, so you have full access to the hard disk and can request any file in the system you want.  You specify the location within the user directory you want to pull the file from (using "c:\" is a matter of "user friendliness", and isn't required) and then you specify ANYWHERE on the LOCAL MACHINE you want to save the file.  

FTP Put VI:

You use the FTP Put VI in order to talk to a remote FTP server to copy a file from the local machine onto the remote machine.  On the remote system you provide login credentials to, you specify where - within the user directory - you want the file(s) to go.  Using "c:\" isn't always allowed, since user directories are not necessarily tied to drives.  You can specify the path to the file to copy to the remote location as any path legal on the local machine (local path), but you can only specify legal locations defined within the FTP server of the remote machine to copy a file TO (remote path).  

So, except for special cases, if you're using an FTP VI you are NEVER using the FTP server on the system the VIs are running on.

If this is helpful, don't forget to click the "Kudos" on the left.  🙂

-Danny

[SEGIO]

I understand all what you said, but I can't implement FTP Get File. When I'll in the office, I'll put a screenshot of what I have.

Thanks again

[SEGIO]

I put the images that I promissed, any help will be grateful!!

FTP Get file.vi which doesn't work

Error when I run FPT get file program

FTP Put File which works fine

[Texas_Diaz]

Okay, there's two problems here.  

1. NEVER use a captiol letter in a drive path on a cRIO.  Especially those using VxWorks.  The paths "c:\users\myfile.txt" and "C:\users\myfile.txt" are completely different paths as far as VxWorks is concerned, since the C drive is actually mounted as a lowercase letter ('c') and VxWorks is incredibly case-sensitive when it comes to paths (especially the drive letters).  Also, I ASSUME that there's a directory on the cRIO called "c:\Users\EESA" where the "data.tdms" file can be found.  Is that correct?  If not, that path needs to be exactly the path on the cRIO where the file can be found.
2. You must provide the full path - including filename - for the file location on the host.  You're only using "C:\Users\EESA\Desktop" which is already a directory - you need to use "C:\Users\EESA\Desktop\data.tdms" so that it creates the actual file correctly.  Did you create a LabVIEW account on the FTP server on the cRIO (likely through the web server on the controller)?  If so, you need to make sure the LabVIEW account on the FTP server on the cRIO uses the root at its default directory.  If not, or you're unsure, try using the "anonymous" username with a blank password if you have any questions about this.

-Danny

[SEGIO]

1- Ok, I didn't know that, it's essencial.

2-I forgot to put the file name, if you see the FTP Put File you can see that I did it right. On the other hand, I'm not sure if there is a LabVIEW account on the FTP server on the cRIO because I didn't configure that (teacher did it). But I think so because if I put the IP of the cRIO in the web browser I can acces to the cRIO's files.

Thank you very much, I hope it'll work. I let you know if there is something wrong again 😉

[Texas_Diaz]

Be careful - the FTP server and the Web Server you interact with (using the IP address in a web browser) don't actually share user information.  You cannot actually create FTP accounts on RT targets (that question was "bait" to see how much you knew about the system). 

In general, on an "unlocked" target (we'll get into what that means in a minute) you can log into the FTP server with essentially any username and any password.  Yeah, we're working to deprecate FTP in the future.  Anyway, you can lock the target in one of two ways:

1. Older versions of MAX have the ability to "lock" the target by setting a system password - this sets the login password on the FTP server, and that in turn seriously restricts what can be done via the FTP server by NI software (such as MAX for installing/uninstalling/querying software).  Again, that's older versions of MAX, and when the Web Interface was implemented that functionality was gutted in MAX and moved within the Web Interface.
2. Within the web interface, if the admin account within the web server has a password set, the FTP server is locked down and you can ONLY access the FTP server using "admin" as the username and <your admin password> as the password.  So if someone sets the admin password, the admin account is the only account that can access FTP.  Setting the password back to blank will unlock the FTP server again.

-Danny