LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial - auto detect baud rate

Greetings,

 

Based on several posts I've found in the forums, I've cobbled together some simple code to <hopefully> allow our calibration PCs to auto-detect the baud rate of the instrument that gets connected (the COM port will always be known and remain constant).  It's simply a for-loop that cycles through a list of baud values, and during each iteration the instrument gets pinged for a valid response.  Once validated, the serial settings can be configured and the calibrations can be performed automatically.

 

If I use the "Simple Serial" example (pinging at the known baud rate), I get the expected valid response.  If I use my new code that cycles through the baud list, I get mostly no response, except for the occasional gibberish that happens when the baud rate doesn't match the instrument... but I never get a "valid" response when the code executes at the known baud rate of my test instrument (test inst set to 38400, all other inst serial params match the default VISA config serial port settings).

 

A snippet is attached, along with an example of the gibberish with a baud mismatch.  I've been experimenting with flushing and/or clearing the buffer, and time delays, but I can't quite fix the problem.  Depending on the config, I may get a framing error, or a timeout.  The attached snippet doesn't contain the validity test, it just shows the first character received (if any).

 

Any advice is greatly appreciated!

Download All
0 Kudos
Message 1 of 26
(5,565 Views)

The Tunnel Mode for the For Loop is set to "Last Value". You are only seeing the results of 57600 baud rate case. Since the correct baud is 38400, I would expect that the last value to be gibberish.

 

Try changing the tunnel mode to "Indexing". Then you will be able to see all the results from all the cases.

 

Or the alternative is to add a "Conditional Terminal" and exit the For Loop when you receive a valid response.

0 Kudos
Message 2 of 26
(5,547 Views)

I just noticed one other thing. The Simple Serial.vi sends the command with a "\n" Line Feed terminator and you get a valid response. In your FIND COM.vi you use a "\r" terminator.

cr.JPG

 

Try changing the termination character to \n. BTW You don't need to use Concatenate Strings. Just type the \n at the end of the command.

nl.JPG

0 Kudos
Message 3 of 26
(5,539 Views)

@jamiva...

 

Thanks for the replies, let me provide additional info...

a.  The termination char for my data set is \r.  I had changed the Simple Serial default to \r but did not mention that in the OP.

b.  The indicator located above the VISA Close updates each iteration, and I've also monitored using probes, so I can confirm that no "valid" response is being received, even in the correct baud iteration.  The gibberish is sometimes seen during other iterations depending on timing delays and other mods.

c.  The snippet did not include the existing validation test (with conditional exit).  I removed it until I can get a consistent valid inst response.

d.  The concatenate is temporary.  I'm experimenting with different inst commands to see which is the most reliable across the series, and it was easier to split the command and term char until I find the combination that works.

e.  LV2015, Windows 7

f.  I also ran across a post that contained in big bold letters "REMOVE BYTES AT PORT!!!!!!" (among other suggestions  :D).  I forget who the author was, but even following his detailed thread I'm still having problems.

 

I have a working knowledge of serial comms, but not much detail on how LV/VISA handles the nuts and bolts of port configs, especially when cycling through different baud settings.  When an invalid baud rate is used does it corrupt the port/session and prevent it from responding correctly during the next iteration?  Am I not "resetting" the port correctly after the use of an invalid baud?  Any other ideas?

 

Thanks!

0 Kudos
Message 4 of 26
(5,525 Views)

No, an invalid baud rate would not corrupt other attempts.

 

To me it looks like you have a parity/data bits issue.  Do you know whether you have the data bits, stop bits, and parity set correctly?  If you request 8 data bits and no parity, but the device sends 7 data bits and a parity bit, then many of the characters you receive will be gibberish.

 

Look at the incoming data as hex bytes, set the string indicator to hex format.  Compare that to the situation where you know you are getting correct data.

0 Kudos
Message 5 of 26
(5,497 Views)

Could you show us what your code looks like after the changes you've made? Actual code, not just a screenshot.

0 Kudos
Message 6 of 26
(5,464 Views)

When your instrument sends a termination character, using "Bytes at port" is usually wrong.

 

Opening and closing a VISA Session in a loop is ALWAYS wrong.  Open it once, set BAUD inside the loop with a property node, You really don't need to close it (VISA Sessions "Close" mostly automagically depending on LabVIEW.ini settings but, close it once outside the loop.

 

Put the VISA I/O Session wire on a Shift Register!

 

Show the conditional terminal on the For Loop and exit with expected response=OK

 

What is the device on the other end?  Can you link to the manual for that device? (Smiley Sad have you read that manualSmiley Sad?)


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 26
(5,461 Views)

@JÞB  ha scritto:

Put the VISA I/O Session wire on a Shift Register!



Are you sure? I never did it, and got no problem. I always thought the VISA wire was a sort of named reference to the actual software object.

However, I may be wrong.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 8 of 26
(5,456 Views)

@pincpanter wrote:

@JÞB  ha scritto:

Put the VISA I/O Session wire on a Shift Register!



Are you sure? I never did it, and got no problem. I always thought the VISA wire was a sort of named reference to the actual software object.

However, I may be wrong.


Mostly, that is correct!

 

There is a non-default setting in options to close VISA sessions automatically when the caller stack goes "Idle" (this can be annoying.)   And, VISA Sessions magically <Poof> out of existence when callers leave memory - Really annoying sometimes if using a TestStand Sequence where you expect VISA to be persistent through "MAX" or "XMLHell"

 

Treat them like "Named Queues."  Close one ref you close them all to that session.  Change One "Property" the named queue private data changes for that instance.  And, that leads to the source of your poor experience.

 

You open a IO session multiple times to the same "Resource" To Wit ASRL:n and under the hood VISA is revising properties and trying to decide if that is still a session who's properties might just be re-usable (and it needs to get them to DISC in XML format!) LabVIEW does a fairly competent job of keeping up with what VISA expects under an NI VISA Passport.  Yet, have you ever seen this?

 

Small Child: "mom, mom...mom.mom....mommy..."

Exasperated Mother: "What?"

Small Child: "I... I...I Don't remember?"

 

Yeah, do what I said.


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 26
(5,452 Views)

@pincpanter wrote:

@JÞB  ha scritto:

Put the VISA I/O Session wire on a Shift Register!



Are you sure? I never did it, and got no problem. I always thought the VISA wire was a sort of named reference to the actual software object.

However, I may be wrong.


I think the issue here is that, if using a FOR loop, there is always the chance that the FOR loop executes ZERO times.  When this happens, anything going in the left side does NOT come out the right side unless a shift register is used.  In this case, it would be an empty VISA resource.

 

EDIT: I see Jeff has already answered this.  (It doesn't make my observation incorrect, but maybe it doesn't apply here.)

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 10 of 26
(5,446 Views)