IVI vs OOP Factory pattern for New Tester Instrument Driver

[ronghuaw]

I have a chance to develop new tester that will be Teststand+LabVIEW....now i think about the instrument driver is IVI or OOP Factory pattern...both have some pros & cons...what's your opinion? and why? thanks

I forget mentioned that this tester will be duplicate for many lines and will be long term maintenance

[asbo]

Well, IVI is already written for you, and built into TestStand ... unless you're dealing explicitly with hardware which IVI doesn't support out of the box?

[crelf]

both have some pros & cons

Maybe *you* should start by telling us what you think they are?

I'm a big fan of IVI - as abso said, it's there already, which has big advantages in that it's supported across several instruments classes and by a foundation that's thought through the architecture much more deeply that I would. Also, it's off-the-shelf and already tested by many people in many ways.

That being said the cons I see of IVI is when your instrument doesn't support the IVI standard(s). For example: some hardware vendors will make instruments that are IVI "compatible", in that you can talk to them using IVI drivers, but their setup might require a custom step to put the device into a mode where it'll respond. Or all of the IVI methods work, except for the one you need. Also, if the instrument isn't supported at all, then IVI doesn't make sense.

In summary: I suggest you don't make this a blanket choice between IVI or a custom applied OOP pattern, I'd choose IVI everywhere you can, and backfill with custom code where you can't.

[Falevoz Y.]

Hi,

Did you already used the LVOOP and the factory patern with TestStand? What is your feedback? Could you give an exemple?

thanx

[ronghuaw]

Hi All..thanks for the reply...and i just worry about that in the future that if new instrument can't support the IVI that need some custom code.

My initial plan is OOP Factory pattern for IVI like instrument driver has similar interface and new child class when new instrument added or replacement, it's easy to add new "NO IVI compatible" instrument but need more work, but if IVI and in future must use the "NO IVI compatible" instrument seems a lot work to do to modify the exist work?

so the problem is put work on beginning or future?Am i right?---it's still depend on the must use the "NO IVI compatible" instrument

Hi Falevoz Y.

I haven't start use the LVOOP and factory pattern with TestStand...so no example here. It's not difficult to implement

[Falevoz Y.]

Hi,

That's what I thought, but when we asked to NI France on the feedback they had on the use of LVOOP with TestStand, they answered that nobody tried in France and asked the US R&D. We have no answer yet. We are worried of dealing with youth bugs. I'd like to start my new project this way, but the rest of team think the risk is too important.

bye

[crelf]

My initial plan is OOP Factory pattern for IVI like instrument driver has similar interface and new child class when new instrument added or replacement, it's easy to add new "NO IVI compatible" instrument but need more work, but if IVI and in future must use the "NO IVI compatible" instrument seems a lot work to do to modify the exist work?

Hmmmm - in that case, I guess you could start by creating LVOOP drivers that wrap the IVI functions, and if you get a new instrument that isn't IVI compatible, you can clone the driver class to a new instrument specific driver. You might even want to implement this with inheritance: have a parent that has all of the IVI functions in it, and only override a method in a child class if the parent doesn't do what you want. This might actually work... Oh, except that TestStand doesn't support LVOOP dynamic dispatch I guess you'd need to wrap it in another class...

[Falevoz Y.]

Oh, except that TestStand doesn't support LVOOP dynamic dispatch I guess you'd need to wrap it in another class...

Dealt with that on my first experiments... I was a bit desapointed, but I think it's logical because subclasses are not in memory. I found a tips to do that manualy... The object connectors of subclasses methods are parents classe type. So, I can call them by reference in the parent methods. It's a bit heavy, but it work...

The OOP aproach is less interesting with the loss of dinamic dispatch, but it keeps the interest of encapsulation...

Edited October 21, 2011 by Falevoz Y.

[crelf]

The OOP aproach is less interesting with the loss of dinamic dispatch, but it keeps the interest of encapsulation...

Right, but is encapsulation enough to go that route when the inheritance makes it awesome?

[Falevoz Y.]

Right, but is encapsulation enough to go that route when the inheritance makes it awesome?

My team answered NO...

[crelf]

My team answered NO...

Yeah, I'd tend to agree.

[CRoebuck]

Hi,

That's what I thought, but when we asked to NI France on the feedback they had on the use of LVOOP with TestStand, they answered that nobody tried in France and asked the US R&D. We have no answer yet. We are worried of dealing with youth bugs. I'd like to start my new project this way, but the rest of team think the risk is too important.

bye

Hi there,

Me and my team have used LVOOP (Factory pattern) with TestStand very recently. It works but with a very big "BUT", You must use TestStand 2010 SP1 and must specify the LabVIEW project being used for each step configuration, if you wish to make naked calls to dynamically dispatch vi's in TestStand (passing in the LVOOP class from TestStand. If you use an older version the DD doesn't work and you end up always calling the parent implementation.

If you must use TestStand < 4.5 then you will need to put your dynamic dispatch vi's in a wrapper vi and let LabVIEW do the dispatch (I have no idea if the deployment works, TestStand probably see's lots of vi's with the same name and gives up.

Chris