OOP Communication Abstraction Layer as a possible replacement for VISA / UDP / TCP / GPIB / etc. in LabVIEW Instrument Drivers?

[Ehouarn]

Hi,

My company is designing and producing testing equipment, some of them can work with two different types of Communication (Serial Port through a RS-232 interface or Ethernet UDP).

The problem is that I don't see myself creating instrument drivers where the commands and acknowledge are duplicated just because the communication layer is not the same. Unfortunately VISA does not support UDP (TCP yes, but unfortunately, the management of the communication is, alas, not that transparent).

Most of the commands that work in a SerialPort are also available when using the Ethernet UDP Communication.

My Idea is to create a Communicant Class that would contain a couple of methods to override and that would trigger some errors in this base class (cause I consider it as abstract, so the default "implementations" of those methods to later override are solely to generate errors).

Also a couple of attributes will make the class not really able be instanciated as there would be a need to Start and Stop before using the other methods (to override, e.g. Send, Receive).

The set of protected methods of override (dynamic dispatch), provided by the Communicant Base class:

• OnSend(String data)
• String OnReceive()
• OnStart(String)
• OnStop()

and some others public to not override (static [in the LabVIEW meaning of it!] ones)

• Start(String)
• Stop()
• String Receive()
• Send(String)

Among the attributes that would be embedded:

• Semaphore for SyncRoot purposes
• Timeout

By the way, for the sake of clarity, I an trying to make this post as short as possible, so the definitions are not that exhaustive as they should be.

I ended up with the following hierarchy:

• Communicant (abstract)

• CommunicantSerialPort (non-abstract)

• CommunicantSocket (abstract)
• CommunicantSocketUDP (non-abstract)
• CommunicantSocketTCP (non-abstract) (just here to demonstrate the sake of the abstraction ;-))

Some subclasses embed some additional Start and Stop methods with overloaded methods, like having a IP and IPEndPoint control to make it more understandable.

I tried and it seems pretty convenient and clear, no more duplication when using different communication means, a command is simply using a Communicant and its related methods to communicate, through the underlying the appropriate resource.

I am pretty satisfied with the use of the OOP just for the communication layer, the problem is that I feel a bid sad that this seems not really compliant with the LabVIEW Instrument Drivers Standarts.

For the same reason that I feel, it would be even better to have Object Oriented Instrument Drivers (some equipment can clearly have some relations as the ones found in inheritances), a Instrument has methods and properties.

Is that so much contradictory to the NI Guidelines to Instrument Drivers: Why? Any good reasons?

[mikeporter]

The idea is basically sound and I would go forward with it IF you can convince yourself that only experienced LabVIEW developers will using the drivers.

Mike...