Multiple protocols and interfaces

[jcz]

What would be the best approach to design & write an application that need to control a device using multiple protocols via multiple interfaces (e.g. SCPI over GPIB and SNMP over ETH) ?

Before anyone answers OO, I'd like to complicate this question by saying that it needs to work with LV 7.1.1 (aka not OO).

Jakub

[Grampa_of_Oliva_n_Eden]

What would be the best approach to design & write an application that need to control a device using multiple protocols via multiple interfaces (e.g. SCPI over GPIB and SNMP over ETH) ?

Before anyone answers OO, I'd like to complicate this question by saying that it needs to work with LV 7.1.1 (aka not OO).

Jakub

I used to use VI Server to deploy a background process for each "plug-in" that could support the interface, and provided a generic interface so that all of the various plug-ins looked the same.

Shane's Nugget found here

http://forums.ni.com/ni/board/message?board.id=170&message.id=255002&query.id=917330#M255002

maybe helpful.

Ben

[Mark Yedinak]

You could still use an OO approach although it would not be native LVOOP. You could use the Endeavo toolkit or dqGOOP for example. We have several classes which were implemented in dqGOOP since they were created back in the days of LV 7.1. We still use them today and they work well. It would be nice to convert them to native LVOOP but we don't have the luxury of the spare time to do that.

One of the classes that we have is a generic connection class very similar to what you describe.

[ShaunR]

What would be the best approach to design & write an application that need to control a device using multiple protocols via multiple interfaces (e.g. SCPI over GPIB and SNMP over ETH) ?

Before anyone answers OO, I'd like to complicate this question by saying that it needs to work with LV 7.1.1 (aka not OO).

Jakub

Are you describing a single device on multiple interfaces an protocols (e.g a dvm that has gpib eternet and rs232 interfaces that you want to test) or is it multiple devices

on multiple interfaces such as motors on rs485, dvms on gpib and digitalio on ethernet that are used in conjunction?

[jcz]

Thanks for all your replies.

@Ben : good idea with using VI server. I will have a closer look into this.

@Mark : yes, I am aware that I still could use LVOOP, but I think the whole program would then be over complicated in this case.

@Shaun: I will have a single device (different variants of this device) connected to a PC on multiple interfaces an protocols

I think I am going to use my current architecture that I used to develop another application ( see: http://lavag.org/top.../page__p__58451 ).

[ShaunR]

Thanks for all your replies.

@Ben : good idea with using VI server. I will have a closer look into this.

@Mark : yes, I am aware that I still could use LVOOP, but I think the whole program would then be over complicated in this case.

@Shaun: I will have a single device (different variants of this device) connected to a PC on multiple interfaces an protocols

I think I am going to use my current architecture that I used to develop another application ( see: http://lavag.org/top.../page__p__58451 ).

I my bluetooth stuff somewhere on this site, I address multiple transport layers. It'd be worth taking a look to see how its implemented but basically it makes the interface (TCPIP, UDP, IRDA, Buetooth in the example) transparent to the protocol. Might be a way forward for you to simplify your low level stuff.

Edited October 13, 2009 by ShaunR

[Mads]

As people here have already mentioned you can still use an OO-like approach:

I've made several systems in LV 7 and older where you have multiple units multidropped on different types of communication links. The user configures a set of channels and can add units on each channel. Based on the configuration I instantiate the necessary channel handlers and unit VIs (Open a reentrant reference to the VIs, or use VITs, and run them with the run method without waiting for them to complete...Use a notifier or user event to control their termination, config reload etc.)).

The unit "objects" have a generic que based interface to the channel handlers; each channel has an output que and each user of the channel have an input que. The unit configuration tells it what channel it is on, and it uses the channel tag to get a reference to the channel's que. The unit can then send data to the channel using the channel que - and the channel will return data on the unit's reply que when the reply is available (using the tag of the unit embedded in the message it received on it's que). The ques pass clusters that, in addition to the message data and the tag of the user object - contain parameters like timers, expected reply length (if no reply is expected then the channel handler knows that and does not wait for one), errors etc.

Unless you make a general plug-in based framework with sub-panel based configuration windows etc. it can be difficult to make the system flexible enough to fit *all* types of protocols and units though.

One way I've solved such cases has been to write plug-ins (launched by a general "plugin launcher") that handle certain types of IO outside the standard IO architecture. In many cases these plugins just "translate" the new protocols to one of the "native" ones and hook up to the rest of the system on a standard channel.

Edited October 14, 2009 by Mads