VISA wrapper for IVI

[drsimonz]

Hi, I'm new to the board, sorry if this is in the wrong section or anything. I did search for this topic and found nothing. My problem is this:

I have an automated tester using 5-10 different instruments. Some of the equipment isn't always available so I want to enable my software to use one of several models (with different drivers) for the same role in the test. The problem is that some units use IVI drivers, while others have VISA-based drivers. IVI sessions can't type-cast into VISA sessions, or vice versa. I could use plain text to pass the instrument addresses around, but wouldn't I be losing other data stored in the session?

I normally store my instrument sessions in a global to simplify the wiring to all my sub-VIs (is this bad practice?). My current solution is to use one VISA session, one IVI session and an enum which lets the sub-VIs know which one to use. But it would be much nicer if I could somehow create a "wrapper" session that allows me to treat the IVI device as a VISA instrument. Is that possible?

Hopefully I'm not doing everything horribly wrong...I'm completely self-taught and have spent a long time trying to come up with "good practices" without much external input. Thoughts?

[ShaunR]

Hi, I'm new to the board, sorry if this is in the wrong section or anything. I did search for this topic and found nothing. My problem is this:

I have an automated tester using 5-10 different instruments. Some of the equipment isn't always available so I want to enable my software to use one of several models (with different drivers) for the same role in the test. The problem is that some units use IVI drivers, while others have VISA-based drivers. IVI sessions can't type-cast into VISA sessions, or vice versa. I could use plain text to pass the instrument addresses around, but wouldn't I be losing other data stored in the session?

I normally store my instrument sessions in a global to simplify the wiring to all my sub-VIs (is this bad practice?). My current solution is to use one VISA session, one IVI session and an enum which lets the sub-VIs know which one to use. But it would be much nicer if I could somehow create a "wrapper" session that allows me to treat the IVI device as a VISA instrument. Is that possible?

Hopefully I'm not doing everything horribly wrong...I'm completely self-taught and have spent a long time trying to come up with "good practices" without much external input. Thoughts?

Well.The intention of IVI was to do exactly what you are describing transparently, but you've found the weakness in the plan Its a good idea (note I say idea because I'm all for interchangeable drivers) as long as your all manufacturers do it (which they don't). But the real killer is you can only create them in CVI (that I'm aware of).

So the "proper answer" is to take your current drivers and turn them into IVI drivers. But that's no good to real people.

I would take a look at Transport.lvlib (you will need to unlock the library to see the guts). It won't help directly, but it will show how I resolved the same problem for for TCPIP, UDP, Bluetooth refs. You will be able to use the same technique to transparently switch between the two systems..(But the age old addage applies....."If it ain't broke, don't fix it!" )

I normally store my instrument sessions in a global to simplify the wiring to all my sub-VIs (is this bad practice?)

Yes.]

Edited September 14, 2010 by ShaunR

[crelf]

My current solution is to use one VISA session, one IVI session and an enum which lets the sub-VIs know which one to use. But it would be much nicer if I could somehow create a "wrapper" session...

Welcome to LAVA!

I'm with Shaun - IVI is theoretically awesome, but it falls in practice. I'm not sure if there were things that the IVI Foundation just didn't think through, or if it's that the standard wasn't meant to be as all-encompassing as I'd expected. That said, for what it is, it works well. The interchangability in VISA, for that matter, has gotten me out of some tight spots more than once.

On to your issue: your post screams OOP. Sounds like you want a parent class that has some common stuff in it and 2 child classes (one for VISA, one for IVI) that have methods to override the parent methods for opwn, write, read, close, etc. Have you thought of using LVOOP?

[drsimonz]

Thanks for your input. If I had the CVI tool available I'd be glad to rewrite all my VISA drivers. I'd get paid to brush up on my amateur C skills and I wouldn't have to worry about the manufacturers' questionable driver quality. Sadly I don't have that, or the time. The OOP solution sounds interesting, if convoluted....learning how to use that would be useful in general. In the mean time I guess I'll just scrape by with non-generalized code.

I normally store my instrument sessions in a global to simplify the wiring to all my sub-VIs (is this bad practice?)

Yes.]

Sorry if this issue has been discussed thoroughly somewhere else....why is that a bad idea? I've implmeneted semaphores in most of my drivers so there's no potential for collisions (I'd use VISA lock/unlock but can't seem to find a similar version for IVI...).

[ShaunR]

Thanks for your input. If I had the CVI tool available I'd be glad to rewrite all my VISA drivers. I'd get paid to brush up on my amateur C skills and I wouldn't have to worry about the manufacturers' questionable driver quality. Sadly I don't have that, or the time. The OOP solution sounds interesting, if convoluted....learning how to use that would be useful in general. In the mean time I guess I'll just scrape by with non-generalized code.

Sorry if this issue has been discussed thoroughly somewhere else....why is that a bad idea? I've implmeneted semaphores in most of my drivers so there's no potential for collisions (I'd use VISA lock/unlock but can't seem to find a similar version for IVI...).

Well. You've already run into one on the major problems (race conditions) otherwise you wouldn't have had to use semaphores. You wouldn't need to do that if you'd used (say) a functional global.

Another issue is that global variables significantly complicate debugging especially for people not as familiar with the code as you are. You, as the developer, know every inch of your code and can probably tell by the symptoms where bug is probably hiding. I, as someone not as familiar, just see a sea of globals in many sub VIs (could be hundreds). Where do I put my probes? I cannot probe the global itself (Unlike a functional global).

The original argument for globals being bad practice was that they break the data-flow paradigm of labVew. Now that LabVvew is being promoted as an OOP language, this is a bit moot. But it isn't just labvVew where it is perceived as bad practice. Most languages suggest that local variable scope is the preferable solution. However. I can think of 1 or 2 situations where I would go against the flow and use a global variable.

I'm sure others will chime in with their thoughts, but I would guess they are not supportive of global variables.