crio write to measurement problem

[phdieum]

I am trying to use the write to measurement function in my .vi which is running under my RT target Crio.  I am aware of how it writes directly to the target Crio flash memory by default and can see the file by accessing the Crio via ftp://.  What I would like to do, but have been unable to so far, is write the file to my computer's harddrive instead of the Crio flash memory.  I have entered a path in the write to measurement in the form of //computer_name/shared_folder.   This shared folder has been set as shared with corresponding full-control permissions and security allowances.  With the firewall disabled, the file is not being written to my computer's harddrive for some reason. 

Additionally, I have read the posts regarding the TCP Communication - RT.vi, but I'm not quite sure of its purpose and I don't know what to input as code,source, & Machine Alias? 

Any help would be greatly appreciated.

-jason

[JackDunaway]

Keep in mind, the cRIO is not running Windows, so the term "Shared Folder" has no context on VxWorks. There are a few methods of interfacing the cRIO/PC as a file client/server, but the easiest method would involve using the FTP palette under the Internet Toolkit. You can call Put Buffer or Put File from the RT code to place contents on a client machine, assuming the client machine has a valid FTP client running.

[Marcelo_I]

As Jack mentioned, the cRIO can't speak "Windowsese," so it can't communicate with Windows shares. The only file sharing available is through FTP, so you have two options: write the file on the cRIO and then send it through FTP to an FTP Server, or send the data straight to the computer through TCP and write the file there.

If you're going the FTP route, first you need an FTP server on your Windows machine. Filezilla has a great one that is easy to configure, just make sure you install the server, because the FTP Client is not enough. Then use the FTP VIs to send your file from the target to the server.

With TCP it's a little more complicated, but you get rid of the overhead that comes with writing the files twice (once on the cRIO, then a second one on your Windows machine.) For this you need two VIs, one on your cRIO which will be reading your data and then sending it with the TCP VIs. Then another one on you Windows computer that listens for a connection and receives the data on the same port you specify on your target. Then writes it to a file. There are examples for this in the help, and looking at the code will make it clearer than I can explain it here 🙂

One last thing. Both FTP and hard-drive access are, by definition, non-deterministic. Make sure to keep this logic outside of any Timed-Loop or Time-Critical VIs to get the best performance.

[JackDunaway]

---

@Marcelo I wrote:

With TCP it's a little more complicated, but you get rid of the overhead that comes with writing the files twice (once on the cRIO, then a second one on your Windows machine.) For this you need two VIs, one on your cRIO which will be reading your data and then sending it with the TCP VIs.

---

There's no need to write the file on the host using FTP if you use Get/Put Buffer(s) - operations can be done in memory without writing to disk. On the other hand, Get/Put File(s) requires files on both host and client.

I would recommend not regressing to TCP if you're wanting to just transfer files over ethernet - stay in the FTP layer, unless you're interested in the academic exercise of re-writing a file-transfer protocol using the same underlying mechanism (TCP/IP) as the current File Transfer Protocol.

One final option, if you don't have Internet Toolkit with the Pro version - Datasocket Read/Write. You can use FTP protocol with Datasocket primitives.

[phdieum]

Thanks Jack/Marcelo,

From what I had read in other posts it seemed you could specify a network path for the Crio to write to, but I guess not.  I was just trying to avoid using FTP and have it write directly.  I will try the options you mentioned and keep you updated.  Again, thanks for your input.

-jason