LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

monitoring of serial port-timed

I am trying to monitor a serial port to catch a certain amount of data that comes through the serial port every second.  I know the data is in bytes between 159 and 172 through the port.  I check the bytes at port and trigger a read when it hits around 155 bytes and 99.9% of the time it works great but every once in a while it does not work properly and messes up my parser.  I don't want to rely on timing as with different computers it may act differently.  Does anyone have a better way to capture this 100% everytime????

 

This data comes out without a write command so I am at the mercy of the hardware.

 

Thanks

 

 

0 Kudos
Message 1 of 12
(1,341 Views)

@bktower wrote:

I am trying to monitor a serial port to catch a certain amount of data that comes through the serial port every second.  I know the data is in bytes between 159 and 172 through the port.  I check the bytes at port and trigger a read when it hits around 155 bytes and 99.9% of the time it works great but every once in a while it does not work properly and messes up my parser.  I don't want to rely on timing as with different computers it may act differently.  Does anyone have a better way to capture this 100% everytime????

 

This data comes out without a write command so I am at the mercy of the hardware.

 

Thanks

 

 


Without code to look at, we will be limited to very general advice.

 

That being said, read the communications specifics - usually in the manual.  There's usually a start and/or stop byte that you can use to sync with.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 12
(1,333 Views)

Just a bit more info...When I run the sw for a several hours it works fine but this may need to run more than 24 hours or more to capture data and that is when I see the issues.  I'm just looking for a fool proof way to gaurantee I capture everything.

0 Kudos
Message 3 of 12
(1,332 Views)

I'll try to get something uploaded and look into the start/stop byte info...

 

Thanks

0 Kudos
Message 4 of 12
(1,328 Views)

Like I said... general answers without code.  I can't help much more without looking at it.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 12
(1,327 Views)

Where is the data coming from?  An instrument?  What model?  A microcontroller that somebody in your company developed?  What is the communication format protocol?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 12
(1,319 Views)

In general ...

 

Usually a termination character can help. Devices that transmit them are more reliable than those that are ambiguous.

 

And if the device does not behave or hiccups once in awhile you have to first catch and then handle those exceptions.

My exp is only testing can reveal these. In extreme cases I just poll until the exact number of characters are in the buffer,.

 

Once a communications hangup is detected it can usually be handled.

 

Be aware however that the hiccup could be the result of not communicating with it properly in the first place! Getting solid info on how to query and write to the device is crucial otherwise you are left with trial and error.

 

Perhaps either sending a lf to the instrument or purging the buffers and trying another poll.

In some cases the external instrument may need to be reset by a method other than serial (like a power cycle relay).

 

If you want 100% reliability you have to think about exactly what is going wrong intermittently and why (with your current serial scheme.)  Is it really the instrument that is losing sync with your code or is it something in your code that is not reliable? Are you quering it too quickly perhaps?

 

IF you believe your scheme is the best it can be (based on limited or no data from mfgr or a hardware that cannot be written to first and your best shot at making it work ) then you will have to write some methods that can handle the intermittent exceptions, should they occur.

 

 

 

 

 

 

0 Kudos
Message 7 of 12
(1,296 Views)

Are you reading the "bytes at port" value? Read it from a reference to your VISA session

BytesAtPort.png

0 Kudos
Message 8 of 12
(1,288 Views)

@Dirtboy wrote:

Are you reading the "bytes at port" value? Read it from a reference to your VISA session

BytesAtPort.png


That is often not the best thing to do.  It really depends on the instrument and whatever communication scheme it has.  Very rarely will I make a system that actually uses the Bytes at Port.  90% of my applications just need the termination character.  The other 10% I have to search for the sync character and do whatever other processing is needed to decode the full command block.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 9 of 12
(1,277 Views)

crossrulz

 

Is there any way you can provide a quick snippet?

0 Kudos
Message 10 of 12
(1,247 Views)