LabVIEW Reference Design for Serial Communication

[jorgeinSD]

Hello,

I'm getting started on a project to create a serial (RS232) device driver meant to be used in a hospital environment. The Data Packet Format seems to me fairly common:

Start Packet (ASCII_SOH)

Packet ID (16-bit integer)

Data

CRC - 32-bit of all bytes between but not including ASCII_SOH & the CRC

End Packet (ASCII_EOT)

ASCII_DLE expansion used in all bytes

Multibyte integers transmitted low-byte first

Is there a LabVIEW Reference Design for Serial Communication that I can use to get started? - My hope is that there's something already done by NI or LabVIEW users that can minimize recreating the wheel too much. An example will be just fine of course.

Thanks !

Jorge

[crossrulz]

Other than the example that ships with LabVIEW, I don't know of one.  Unfortunately, since you are dealing with binary, you can't use the Termination Character.  I would recommend reading your start packet and packet ID and then read the rest of the data based on that packet ID (I am assuming each packet ID will have a different size for the data).

[jorgeinSD]

Thanks for the response; your advice is appreciated. Since there's an End of Packet character there's no fixed or predetermined data size. The shipping examples are too basic, as you'd expect. I'll play with the Instrument Driver Project wizard; I believe it can be used to create serial interface drivers as well. I noticed a new tool: LabVIEW Instrument Driver Development Studio; I installed it but I can't find it in the palettes or menus or examples; not sure what it did to the LabVIEW installation. I couldn't find much help online either other than announcements of new fixes for it.

NI??

I guess I am hopeful of a reference design or more sophisticated driver example. If I find one, I'll update this forum entry.

Jorge

[Dennis_Knutson]

The wizards aren't going to provide much help, in my opinion. The project wizard I've used is centered more on generic functions (initialize, set parameter, read output, etc) and not such low level protocol as yours. In fact, the read and write templates assume ascii strings such as used by gpib, usbtmc, ethernet, instruments. If you wanted an easy to implement LabVIEW program, you would skip all of the binary stuff and just send the data as ascii with a termination character.

[DavidBoyd]

I'm in agreement with Dennis on this - there's no good wizard that'll guide you for this kind of generic code development.  That said, it doesn't sound too difficult.  I've had to develop instrument driver code for devices whose protocols looked much like this - the classic <SOH>...<ETX> framing, along with CRC computation, and the DLE escaping/unescaping mechanism within the payload chars.

I do need to point out that, based upon your description, you will not be able to make effective use of the VISA termchar mechanisms, despite your earlier reply.  Your "end-of-message" character is not, when taken solo, unique within your character stream (assuming from the rest of your description that the data is arbitrary).  It's only unique when it is NOT DLE-escaped.

Which leads back to the Idea Exchange wish for an overhaul of NI-VISA to allow more advanced pattern matching  for finding message boundaries. (Breath_holding_mode=false).

Best regards,

Dave