for New Instrument Driver, can I encapsulate Serial Interface?

[tomhigh]

  I'm creating a new LabVIEW Driver for a new instrument that uses a Serial Interface. The Instrument has a SCPI library and I use that for control and communication. The hitch is that the Instrument defaults to a Terminal Mode (including Echos). I need to initiate Serial Communication and Send a "SCPI" mode command which also stops the 'Echo' reaction. After that I can Send & Recieve information just like a traditional SCPI instrument.

  Because an Instrument Reset or some Instrument errors can cause the Instrument to drop back into Terminal Mode without notifying the software, I find it necessary to monitor all communication for a "Terminal" like reaction and restore "SCPI" mode if required.

  My solution to this problem is to encapsulate all actual communication in a "Communication Handler" that keeps track of the Serial Port in use and handles any error conditions internally. Because of this, any actual commands (VIs) that I create for the Driver do not need VISA Resource Inputs or Outputs as the actual VISA Resource is encapsulated in the Communication Handler which is only given the actual SCPI Command for processing.

 There are other advantages to the Communication Handler such as easier Communication Logging and cleaner Block Diagrams that contain the command VIs.

 My big question is: Is it OK to handle Serial Communication in this manner in a LabVIEW Driver that I will eventually submit to NI for approval?

 Thanks,

  Tom Highfield (CLD)

[Albert.Geven]

how do you handle more than one instrument when hiding the visa resource.

At least you need an input to differentiate between two instruments on two serial ports.

[tomhigh]

Hi Albert,

  Thanks for responding.

  To be clear, the interface is actually a USB/RS-232 adapter, which doesn't really change things much. Once my Instrument is plugged into a USB Port, a COM # gets assigned to it. As it turns out, that COM # gets associated with the Serial Number of the USB Interface Adapter and generally stays the same when the Adapter is plugged into different USB Ports. As usual, COM Ports are locked when opened so no 2 devices can try to use the same Port.

  I do have a Visa Resource selector that shows which COM Port the Communication Handler is using and my Communication Handler will display a Popup Visa Resource selector if there is any confusion about which COM Port to select. I believe this is what avoids the problem you describe.

  By the way, once a COM Port is selected and works, the actual selected Port gets stashed in a Configuration file for the next time.

Tom

[Dennis_Knutson]

Does it work when a built-in serial port is used?

[Dennis_Knutson]

Note do I think you answered Albert's question. If two instruments are used in the same program, how do you differentiate between them?

[tomhigh]

Dennis,

  The Instrument that I'm creating the driver for connects to the computer with a USB cable. The Serial Adapter is built into the Instrument and it's driver gets installed woth the application. This means that standard or adapted serial ports can't be used.

  I've never mentioned that the instrument that I'm building this driver for is Freescale's RF Power Tool. You highlighted the possibility of someone using more than 1 RF Power Tool in the application that they might be building (Albert may have meant that, but I missed it). I'll admit that I'm not sure how to answer that. I've been creating a GUI for the RF Power Tool that will be shipped with the Tool. I've been using the VIs I created in my Instrument Driver to support the GUI and I may have concentrated too much on my GUI and missed some issues related to helping someone else use the driver.

  Thanks to both you and Albert for highlighting this issue. I agree that my encapsulation of the VISA Resource may cause problems when addressing multiple copies of the RF Power Tool in a single application. Having multiple RF Power Tools in a single application is a distinct possibility and my Driver does need to be able to deal with that.

   When I'm done studying this issue and have settled on the best solution, I'll post my results here for the folks that have helped me with good advice. Initially, I think I may need to remove the encapsulation from my driver, but possibly keep it in my GUI.

Thanks for the help,

  Tom

[Albert.Geven]

Hi Tom

It surely is nice to hide details when not needed, but someimes you need to initialize an instrument in the beginning.

So indeed if you need several identical instruments in one app you should have a selection at least at init time.

But that is the easy part, once you realize the problem.

Good luck with making it work.

[tomhigh]

 After much consideration, I decided to eliminate the 'Encapsulated' VISA Resource and add VISA Resource Ins & Outs to all of my VIs. I did this by first making a copy of my Driver & then changing that. My existing application still uses the old Driver with the encapsulated VISA Resource, but I'm looking at the best way to change over to the new, more standard driver. Although it is not required, my App is a very good way to test the actual driver and I don't want to lose that capability.

 The Instrument that my App controls is a SCPI device, so I don't really need a LabVIEW Driver because I been using SCPI since it origination.

 Decisions, decisions...

Thanks for the help everyone. You highlighted a problem that I was seemingly blind to. Much better to hear that from my peers instead of my customer.

Tom Highfield