LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using a cRIO as a VISA device

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

0 Kudos
Message 1 of 8
(3,094 Views)

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.

 

Best Regards

Alex E. Munkhaus
Certified LabVIEW Developer (CLD)
System Engineer
0 Kudos
Message 2 of 8
(3,048 Views)

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

0 Kudos
Message 3 of 8
(3,035 Views)
You are comparing apples to oranges. A VISA interface does not require SCPI anymore than an instrument with SCPI commands requires the use of VISA. If you already have a tcp/ip interface, have you tried adding a raw tcp/ip instrument in MAX and seeing if the VISA writes and reads work? I'm not sure what you would gain by this, though.
0 Kudos
Message 4 of 8
(3,026 Views)

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

0 Kudos
Message 5 of 8
(3,015 Views)
I don't have a cRIO to try it with. As I said, if you have some existing tcp/ip code, try it with the VISA functions. I'm still not convinced of any advantage. You will have less flexibility and the cRIO will not automatically appear as VISA resource.

A UI for a tcp/ip or VISA connection could be identical except one has an ip address and the other has a resource name control.
0 Kudos
Message 6 of 8
(3,010 Views)

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! 🙂

0 Kudos
Message 7 of 8
(3,004 Views)
It is an interesting idea to get a crio to respond to scpi. I cant work out what commands could be used for such a general purpose instrument yet though. A while ago I almost had to make a crio pretend to be a dmm by responding to scpi over serial, but we found a replacement meter and I never completed the project. Shame ... ill add this was to support an old application where no source code was available so I had to mimic the original meter. I do think you have an interesting idea which is worth persuing.
Michael
0 Kudos
Message 8 of 8
(2,996 Views)