LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial Port "idle time" detection ???

I need to detect the idles between messages on my serial port. The
messages do not have unique sync bytes or anything like that... there are
just gaps between messages.

330MHz K6/2... Win98... LabView 6.0.2... 9600 baud data rate... max message
rate is 10pps... message length varies, but is less than 40 bytes...

I've tried to reading the serial port every 10 msec, checking for no
characters... then, I continue to read the port every 10 msec concatenating
the characters until I find another gap... this technique works
occasionally. ( I think I just get lucky and get a short 6 byte message in
a single read from the port... I guess if I ever have to concatenate read
data, I must be dropping characters, or something? But why?)

Does
anyone have any suggestions?

Thanks,
Bill
0 Kudos
Message 1 of 5
(4,755 Views)
Detecting gaps is easy by number of bytes at port.vi. Check the number of bytes at a high sampling-rate. If the number stays the same for a certain time, you have a gap in between the messages.

Patrick de Boevere
0 Kudos
Message 2 of 5
(4,755 Views)
As I said in my original post, I've tried reading the port every 10 msec...
at 9600baud, I should see at most 10 characters... and when I see no
characters at the port, I should have a gap...

Too bad it doesn't work !

I don't seem to be getting more than 10 characters, it's just that I'm
dropping lots of characters... messages that require two consecutive 10 msec
reads seem to be lost... I have the feeling Windows will not let me access a
serial port that rapidly...

Can anyone explain exactly how the LabView Receive Buffer affects actual
reads from the LabView Serial Port driver (serpdrv) and from the actual
Windows serial port driver SERIAL.vxd, SERIALUI.dll and VCOMM.vxd ???

And is there a problem with switching rapidly between a real Operating
Sys
tem function call (like these Serial Port Reads) and the actual LabView
Application (In UNIX, I believe it's called a context switch between Kernel
Mode and User Mode, I just don't know if the same problem exists under
Windows.)

Thanks,
Bill


PdB_Serenity_nl wrote in message
news:506500000005000000C67C0000-1021771306000@exchange.ni.com...
> Detecting gaps is easy by number of bytes at port.vi. Check the number
> of bytes at a high sampling-rate. If the number stays the same for a
> certain time, you have a gap in between the messages.
>
> Patrick de Boevere
0 Kudos
Message 3 of 5
(4,755 Views)
It should work. I have read serial ports on a windows PC faster than every 10ms.

Are you using Num Bytes at Serial Port, and then reading what's there? Or are you just reading, which would require a timeout?

I check the num bytes at port, then read exactly what's there, then concatenate the new bytes to an un-initialized shift register that holds my raw data. Then I check the raw data to see if I have a whole message, and if I do peal it off & process it.

Hope that helps,
Bill Kemmerer
0 Kudos
Message 4 of 5
(4,755 Views)
Thanks Bill,

I've got it working now... I guess I tried to do too much (i.e. analyzing
the data for checksum errors, etc...) before getting back to looking at the
port again.

Later,
Bill


Kemmerer wrote in message
news:506500000005000000E37E0000-1023576873000@exchange.ni.com...
> It should work. I have read serial ports on a windows PC faster than
> every 10ms.
>
> Are you using Num Bytes at Serial Port, and then reading what's there?
> Or are you just reading, which would require a timeout?
>
> I check the num bytes at port, then read exactly what's there, then
> concatenate the new bytes to an un-initialized shift register that
> holds my raw data. Then I check the raw data to see if I have a whole
> message, and if
I do peal it off & process it.
>
> Hope that helps,
> Bill Kemmerer
0 Kudos
Message 5 of 5
(4,755 Views)