Need to accept continuous RS-232 data over serial line

[pblase]

I am fairly familier with the methodology for creating a LabView serial instrument driver. These, however, are all query-response. I need to write a driver to accept continuous packets of data from an instrument such as a digital compass, say at 10 Hz. Is there a good example that I can follow?

[Labviewguru]

,

Look at the examples database for circular buffering (in DAQ). This will get you on your way to solving your problem.

You will need to use the old serial port VIs (user.lib?) to do this. What I believe you need to do (I have worked with GPS receivers, and loads of serial data from instruments) is to read the no. bytes at the port, then immediately read the port. The read should clear out the bytes it counted, and then clear the way for a new read. If you put this in a slightly deterministic loop, of 10Hz (use the wait till next ms multiple primitive to do this) then you should be able to sync up with your compass, and not suffer any overflows. Be sure you setup your port with a big enough buffer.

Good luck

[Stu 708]

The VISA functions work the same way. just read bytes available and read that many bytes via VISA in a continious loop.

[Kemmerer]

I agree with the method for reading the data. But once I read this type of data stream, I append the new data to a shift register. I then scan the data in the shift register to see if it contains one or more full records. If so I pull them out of the shift register, and process them. In this way, you don't have to slow up your loop to try to sync up with the data stream. It handles having less data or more data than a single record, and gives the fastest possible response.

Hope this helps,
Bill Kemmerer

[pblase]

What's the best way to implement a shift register? I tried something like this, but it wasn't working right. With the way that LabView handles strings, I'd like to make sure that I am, in fact, overwriting the same memory and not just using up the heap.

[Kemmerer]

Here is a simple program I wrote recently. It's not real pretty (I had about an hour to get it ready for the CES show), but it shows the method I was talking about. I use the older serial VI's out of habit. I had data coming in very slowly, so didn't worry about the case where I had more than one record.

Expand the window to see the buffers and the stop button.

Cheers,
Bill Kemmerer

[Greg_McKaskle2]

> What's the best way to implement a shift register? I tried something
> like this, but it wasn't working right. With the way that LabView
> handles strings, I'd like to make sure that I am, in fact, overwriting
> the same memory and not just using up the heap.
>

The shift register probably isn't the issue. It is merely the best
method for getting data that is an output of a loop diagram to be an
input to the next iteration. Frequently, you will want the first loop
diagram to have an empty value or some other known value and you will
wire the value into the outside left of the shift register. Other times
you will want to "maintain" the data from the last time the loop is run,
and at that point, you can leave the left outsid
e unwired.

The way that memory usage grows and grows is when the inside of the
appends or concatenates data and uses a shift register to make it the
input the next iteration. If the logic inside the loop doesn't have any
way of limiting the size of the string or array, then the application
may eventually use so much memory that the application cannot continue.

So, in general, the shift register is one part of the equation, but only
when it is combined with a concatenate or append.

Greg McKaskle

[Spaz]

You may find Dave Thomson's Serial Tools V1.6 (available @ http://www.originalcode.com/occdl.html ) useful. These utilize the same 'old serial port VI's' that LabviewGuru references but packages them in higher level routines that include the standard error in/out clusters I've grown accustomed to. The 'Read Serial Port with TimeOut.vi' allows you to read data from a circular buffer with timeout limits as well as specify termination characters for scanning through the buffer for a complete packet.

You can call this VI at your interval to prevent a serial buffer overrun and if a specific termination character exists in the buffer it will remove and return the packet from the buffer while appending any new serial data to the buffer.

If your serial device spews
serial data with no initial command to start you can first call the VI with 'Return Partial' = True and disregard the returned data to synch up with the serial device. Afterwards each call to the VI with a specified termination character and 'return partial' = false should return a single packet. Your circular buffer could get big if you are receiving packets faster than your picking them out, but you can edit the VI to pick out all the available packets and return them in a string array rather than a single string.

Hope this is useful. Good Luck.

[Spaz]

You may find Dave Thomson's Serial Tools V1.6 (available @ http://www.originalcode.com/occdl.html ) useful. These utilize the same 'old serial port VI's' that LabviewGuru references but packages them in higher level routines that include the standard error in/out clusters I've grown accustomed to. The 'Read Serial Port with TimeOut.vi' allows you to read data from a circular buffer with timeout limits as well as specify termination characters for scanning through the buffer for a complete packet.

You can call this VI at your interval to prevent a serial buffer overrun and if a specific termination character exists in the buffer it will remove and return the packet from the buffer while appending any new serial data to the buffer.

If your serial device spews
serial data with no initial command to start you can first call the VI with 'Return Partial' = True and disregard the returned data to synch up with the serial device. Afterwards each call to the VI with a specified termination character and 'return partial' = false should return a single packet. Your circular buffer could get big if you are receiving packets faster than your picking them out, but you can edit the VI to pick out all the available packets and return them in a string array rather than a single string.

Hope this is useful. Good Luck.

[pblase]

Thanks much.