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. 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...).

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?