From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial - auto detect baud rate

@Mancho00...

 

Doh!  Fixing that...

 

a. With various baud rates in each case = first iteration (9600) yields gibberish and a framing error (-1073807253), each subsequent iteration (14400-57600) yields no data and a timeout error (-1073807339), even at the correct 38400 baud.

 

b. With 38400 in each case = no errors, but valid data only on the third & fifth iterations.  1/2/4th lap yield no response (but again no error).  I bumped both Wait times up to 500, no change.

 

GUJ

 

0 Kudos
Message 21 of 26
(596 Views)

@arteitle  ha scritto:

It could be that the instrument is receiving some garbage characters when you send the command at the wrong baud rates, so when the command is sent at the correct rate without the extra \n before it, the instrument is interpreting the garbage plus the command as an invalid command and ignoring it. The extra \n before the command has the effect of clearing the instrument's receive buffer of the garbage it had received, so the command can be interpreted correctly.


arteitle's remark above may be the key: try prepending a \r to the actual command, to force the instrument to clear its input buffer. If this still does not work, maybe it's better to write the full command two times, with a delay; try first with a very long time, let's say some seconds, just to experiment. I guess the right delay (if needed) should be much less, 1 second maximum (unless the instrument's firmware is so badly written).

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 22 of 26
(578 Views)

@GiantUncleJohn wrote:

Thanks for the continuing support.  Here is some additional info...

a. The inst is built by us, the firmware coder sits in the office next to me so I can confirm knowledge of the manual and what the data format is.



That bit of information tells you where you need to go to ask questions; whoever is the person within "us" that knows about the firmware for that device?  Ask your colleague who knows the firmware what would happen if it receives gibberish before receiving a valid command.  Also if there are any special timing requirements you might need to follow before sending consecutive commands.

0 Kudos
Message 23 of 26
(561 Views)

@RavensFan...

@Paolo (and probably others) nailed it with the comment on potentially badly written firmware.  Indeed, the "us" coders were looking into it while I was banging away externally with LV.  The problems that I'm seeing are apparently stemming from the fact that this particular board will accommodate multiple protocols, and that the firmware isn't quite as robust as it needs to be to handle errant messages.  So, when the baud rates are mismatched, the board misinterprets the gibberish and gets lost.

 

I'm going to use a third party device to validate the code suggestions everyone has provided so far, then I'll try again after the firmware updates.

 

I greatly appreciate the collective effort, it was another learning experience for me.  It speaks volumes that you take time to assist us less-experienced LV users.

 

-J

Message 24 of 26
(552 Views)

@GiantUncleJohn  ha scritto:

a. The inst is built by us, the firmware coder sits in the office next to me so I can confirm knowledge of the manual and what the data format is.


To be honest, I missed the first part of this statement (read too quickly!).

So, you are in the ideal situation where you can ask the protocol developer which is the right way to solve the problem.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 25 of 26
(539 Views)

@GiantUncleJohn wrote:

@RavensFan...

@Paolo (and probably others) nailed it with the comment on potentially badly written firmware.  Indeed, the "us" coders were looking into it while I was banging away externally with LV.  The problems that I'm seeing are apparently stemming from the fact that this particular board will accommodate multiple protocols, and that the firmware isn't quite as robust as it needs to be to handle errant messages.  So, when the baud rates are mismatched, the board misinterprets the gibberish and gets lost.

 

I'm going to use a third party device to validate the code suggestions everyone has provided so far, then I'll try again after the firmware updates.

 

I greatly appreciate the collective effort, it was another learning experience for me.  It speaks volumes that you take time to assist us less-experienced LV users.

 

-J


We each have "been there done that"

It stinks when you are there!  Post back when you get some time to help others.


"Should be" isn't "Is" -Jay
0 Kudos
Message 26 of 26
(517 Views)