I'm using a cRIO 9039 in my project. I save some data files (tdms) in the SD card of the cRIO. I activate the Embedded UI of the cRIO to enable the user to interact with the application.
The cRIO is connected to the local network. I want to send a specific tdms file from the cRIO to a PC of the network when the users clicks in the User interface.
I have seen some examples to send files to the cRIO from the PC or to get data from the cRIO, but no from the cRIO to a PC interacting with the cRIO application.
Has anyone done something similar ?
I don't know how configure the open sesion.vi from the webDAV palette.
The problem with using webdav to send files to a Windows machine is that you would need to setup a webserver on the Windows machine and configure it to offer webdav.
The only fileserver-oriented server available by default is SMB/CIFS/Windows Network Shares. There are some on these forums who have successfully setup CIFS on the RT target to access Windows Network Shares, but the problem is that configuration and use is largely Windows-install-specific: the same configuration to access one machine's Windows Network Share fails on another (due to some differences in the configuration being required above the host, username, and password).
It is a larger general problem, you will find many, many forum posts for any distribution about difficulties mounting Windows shares as Microsoft has made the technology a moving target. Even accessing a share on a machine with one version of Windows from a machine with a different version of Windows is a hit-or-miss exercise.
There are, of course, other options such as setting up a FTP or SFTP server on the Windows machine, in the SFTP case there won't be a native LV palette to work with, you can either check out LabWerx LabSSH product or work through System Exec calls to work with the server.
I used to used FTP to push files from a cRIO to a PC and as BradM says you will need to have a FTP server running on the Windows machine and then use those credentials to have the cRIO login remotely. To do this with any security there is some amount of setup on the Windows machine (i.e. IIS, Firewall, User accounts, etc.) . Managing this gets difficult because Windows is well.... Windows and FTP server setup is different from OS to OS. I got tired of it and moved the server to the cRIO. I found it was easier to send the file path to the PC via other means. In my case I Simple TCP messaging and then have the PC UI use WebDAV to login to the cRIO and fetch the file. Simple and robust.
So, do you think that would be a good idea to use FTP protocol, creating the server in the windows machine?
I cannot and do not recommend setting up an FTP server for all of the reasons that firstname.lastname@example.org mentioned. It is difficult to secure the server itself, and FTP as a protocol is unencrypted, making it unsuitable if the network traffic ever crosses an unsecured public network.
My recommendation would be either to use WebDAV, with the server side existing on the cRIO, or SFTP, with the server existing on either the cRIO or the Windows side. Be extra careful if either the Windows machine or even the cRIOs will be exposed directly to the Internet.
FTP as a protocol is unencrypted, making it unsuitable if the network traffic ever crosses an unsecured public network.
Yeah, the first time I used Wire Shark and saw the FTP login credentials go by in plain text I was a little surprised.
Hi All - I've got a similar setup with a cRIO-9035 and a laptop. This conversation sounds like the best thing is to run a VI on the PC to GET the file rather than run something on the cRIO to PUT the file. I'd rather not have to push start for two VI's, so what do you recommend for one of the VI's launching the another? Thanks.
If the server is running on the target (as is the case for the WebDAV server which is running by default, or the SFTP server, which is enabled through MAX), there's no need to start a VI on the target; the server is a separate process that's always running and able to accept requests that come in from the client (in this case, your VI running on your Windows PC). The VI (using, e.g., the WebDAV palette) on the PC then makes requests to get the information from the server running on the target.
There are many possible solutions here, it really depends on your requirements and what the intended end use-case is.
Thanks BradM. At a high level, I'm developing a realtime control for a pneumatic cylinder with a remote cRIO 9035 and a local Win 7 laptop connected via USB. I'm programming with Labview 2016. The realtime is just programmed with scan engine and a timed loop. The non-realtime is programmed with a while loop. I've gone both ways, putting the non-real time on the cRIO and communicating with FIFOs and putting the non-realtime on the laptop and communicating with shared variable networked FIFOs. I'd like to add data acquisition as a feature. My idea so far was to have the cRIO record the data and save it as a file on the cRIOs hard drive, then have the laptop fetch the file. I've gotten this to work with WebDAV, but I don't want to have to start both my real time VI on the cRIO and the non-real time VI on the laptop every time want to run. I would like one of the VIs to call the other, so that when the file is saved on the cRIO, it is also transferred to the laptop, all from one "apparent" VI.
However, as I write this, I'm starting to talk myself out of this approach. It is likely that there will not be a laptop/PC always connected to the cRIO. There would probably be an accumulation of files on the cRIO. Maybe it would be good to have the two VIs not call one another. Eventually, I'll probably want to have the VI run independently in the CRIO, and only connect the laptop to download accumulated data files and/or debug/tune/configure the realtime controls. If this is the case, I'm not sure how I would have the laptop discover the files to download. Maybe have the cRIO keep a list of data file names in a master file with a fixed file name. Or, have the cRIO put all the files in a sub-directory, and the VI on the laptop could just get all the files in that directory. I'm thinking option #2 would be the easier of the two.
Any thoughts on my options?
andy, thanks for clarifying.
Just for stating the starting conditions, we have an RT application (either deployed through a live connection, a so-called "interactive" deployment, or as a built application) that is capturing data and saving this to disk. We also have a host PC side that is running some G that pulls this data from the controller.
Now, the method in which the code is run on the target (which, if you're pressing a "Run" arrow as you've said, leads me to believe this is an interactive deployment from a PC host LabVIEW project) matters and makes a difference. You may want to consider looking into a built application set to run on RT target startup (see: Building and Deploying a Stand-Alone Real-Time Application (Real-Time Module)). There is a way, through LabVIEW project scripting, to get an aspect of what I think you're asking for (run the host PC VI, it deploys and runs an RT target VI), but all of this needs to be in the same project (the host PC VI is under "My Computer" and, in the same LV project, there is your RT Target), but this is fairly complex and probably overkill for what you need. I'd recommend the Startup App approach.
If you want to collect up data and analyze all of the data at infrequent intervals, it does seem that on-RT-target logging and from-PC-fetching is a reasonable approach (depending on the rate that data is being acquired). In which case, you may want to consider a time-period-delineated file storage (and automated cleanup) mechanism. All of this said, the RT application design side of things is not really the goal of this forum, rather the means of using the underlying Linux system in ways that are less-than-supported by NI is really the goal of these forums. You may want to post your overall application architecture thoughts and needs in a posting here: LabVIEW boards , tagged with "RT" and titled appropriately). When the question comes to getting logs off of a target using something other than WebDAV, that jibes with the goal of this board.