04-22-2014 04:30 PM
Hello,
I'm looking at using several cRIOs for various DAQ and control functions, with a 'master' computer communicating to the various cRIOs via ethernet to perform various test related tasks.
What I would like to do is code the RT portion of the cRIOs so that the master computer talks to them like 'any other' VISA message based device, so I don't have to re-invent the wheel in terms of all the low level TCP coding.
In other words, I want to cRIO to respond like a VISA enabled device (like a scope, or voltage source, meter, whatever), and I'm hoping someone else out there has already laid the groundwork for making a "cRIO driver" that makes it respond like a VISA device.
Any suggestions or pointers would be greatly appreciated!
Thanks in advance,
Chad
04-23-2014 02:27 AM
Hi Chad.
Unfortunately, I have not heard of anyone that have implemented SCPI commands on a RIO. However, it is possible to communicate between a Windows Host and a RIO target using the serial port. I have found a simple example, that you might can use as inspiration. In order for this example to work, I think you will need a NULL Modem cable. That basically means that the TX on one side is tied to the RX on the other and visa versa.
Community: Serial Data Transfer Between cRIO and Host
Also, when working with serial communication, it is always a good idea to check that everything works, before actually connecting devices. This can be done by doing a loopback test.
How to Do a Serial Loopback Test
I hope this information is helpfull.
04-23-2014 08:41 AM
Alex,
Thank you for the example. I don't have any problems communicating with the cRIO via ethernet (which really isn't much more complicated to program than the serial port example), I was hoping to avoid having to develop the SCPI layer that would have to go on top of the communications (serial or ethernet), such as the parser, message formatter, error handler, etc.
I'm actually fairly surprised nobody has developed a 'cRIO as generic device' interface before now, it struck me as a fairly obvious extension of that platform!
Ah well. Thanks again for your help.
Chad
04-23-2014 09:37 AM
04-23-2014 10:16 AM
Dennis,
I realize that neither VISA nor SCPI depend on either, or are (necessarily) related, but that's not really the point of my request. You're much closer to what I'm interested in when you said you're 'not sure what [I] would gain by trying to connect to the cRIO as a raw tcp/ip instrument. What I am looking for is any examples or previous work which would allow a cRIO to act like a 'standard' device to another labview program, running on a UI machine.
There are two main reasons for this. The first is, as I'm sure you're well aware, it is a tremendous coding effort to develop a truly robust mulit-client TCP link, along with the command parser, format generator, etc that would be needed. This has clearly been done many times on other devices, although it apparently hasn't been done in labview (at least by anyone willing and able to share their code).
The second reason is simplicity of coding on the UI machine. My group is only responsible for the cRIO coding, so I'd like to keep the interface with the UI machine as simple as possible, and I'd much rather them be able to use some of the standard VISA vi's instead of having to code their own TCP comm loop.
I'd much rather not use some cludgy single-use code for this, but the development time for this is probably much bigger than the time alloted for just the functional (DAQ) portion of the cRIO programming we're on the hook for, so I was hoping someone out there would have a base I could build from.
As I mentioned above, it seems surprising to me that something along these lines hasn't been worked before. One of the big plusses of labview is the driver support NI has for so many classes of hardware out there. It seems like an obvious step to extend that capability to the cRIO and cFP platforms, such that they could be developed to appear as 'just another device' to other labview code.
Any thoughts?
Chad
04-23-2014 11:09 AM
04-23-2014 11:13 AM
So far, this seems to be about the closest I've found to what I'm looking for:
http://www.ni.com/example/27739/en/
It's certainly doesn't make use of the standard device driver calls, but at least it has a defined API. That's the wonderful thing about standards: there are so many to choose from! 🙂
04-23-2014 12:00 PM