LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial - auto detect baud rate

You'd generally be fine with a VISA reference not on a shift register.  Where you need a shift register would be a situation where you'd have a state machine and the reference number might change during the loop such as when you close and reopen the VISA reference.

 

The other reason for a shift register is for a situation where it goes through a For Loop, but there is a chance that the For Loop runs zero times.  A shift register passes the value before the loop to after the loop.  Regular tunnels will send out an invalid reference since the For Loop didn't run and the wire that passed the reference from the input tunnel to the output tunnel didn't execute.

0 Kudos
Message 11 of 26
(1,390 Views)

@Jeff: Most likely, I am not exploiting all VISA magical power. All my applications feature a single acquisition loop distributing data to other code parts using Notifiers or Queues depending on the needs.

 

@Bill: you are right, but my remark was not about this issue

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 12 of 26
(1,386 Views)

@pincpanter wrote:

@Jeff: Most likely, I am not exploiting all VISA magical power. All my applications feature a single acquisition loop distributing data to other code parts using Notifiers or Queues depending on the needs.

 

@Bill: you are right, but my remark was not about this issue


VISA isn't magic.  But I "THINK" you got my point.

 

@ which Bill?  Raven' Fan (Sir "Bill") offered some points on when you gotta use a Shift Register for a VISA I/O Session. Like, Where you need a shift register would be a situation where you'd have a state machine and the reference number might change during the loop such as when you close and reopen the VISA reference.

And, just use a SR on ref's in a For Loop anyway... Thank me laterSmiley LOL

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 13 of 26
(1,372 Views)

The OP never mentioned what instrument he was using, so I used one I had laying around. I modified the OP's code and got it to work. It's not bug free (i.e., if there is NO correct Baud, it uses the last value as being correct).

 

my BaudRate tester.png

 

However, I ran into a problem and it could be the same one the OP is having. The *IDN? command doesn't work as expected.

 

If I go into NI MAX, *IDN?\n works just fine. If I use that exact same command in the vi, nothing happens/no response from the instrument. Thru trial and error, I needed to prepend a LF to the command to get it to work:  \n*IDN?\n. Another variation that also works is *IDN?\n;*IDN?\n. You would think it would respond twice to the double command but no, only one response.

 

I do remember reading a post a while ago where their command only worked if it was sent twice. Can't find that post. I never changed any default serial settings. Is there some rogue setting that needs to be reset?. NOTE: this unit works perfectly with GPIB and Ethernet.


Bottom line for the OP is to verify that his command will work. Try testing it using ONLY the correct baud rate. Once you verify a valid response, only then add the wrong bauds to the list.

 

EDIT: Just realized that you don't need the last VISA Configure Serial Port. It's redundant. It's already set to that Baud when it exits the For Loop. I attached a VI ver2014.

Message 14 of 26
(1,361 Views)

@jamiva wrote:

The OP never mentioned what instrument he was using, so I used one I had laying around. I modified the OP's code and got it to work. It's not bug free (i.e., if there is NO correct Baud, it uses the last value as being correct).

 

my BaudRate tester.png

 

However, I ran into a problem and it could be the same one the OP is having. The *IDN? command doesn't work as expected.

 

If I go into NI MAX, *IDN?\n works just fine. If I use that exact same command in the vi, nothing happens/no response from the instrument. Thru trial and error, I needed to prepend a LF to the command to get it to work:  \n*IDN?\n. Another variation that also works is *IDN?\n;*IDN?\n. You would think it would respond twice to the double command but no, only one response.

 

I do remember reading a post a while ago where their command only worked if it was sent twice. Can't find that post. I never changed any default serial settings. Is there some rogue setting that needs to be reset?. NOTE: this unit works perfectly with GPIB and Ethernet.


Bottom line for the OP is to verify that his command will work. Try testing it using ONLY the correct baud rate. Once you verify a valid response, only then add the wrong bauds to the list.

 

EDIT: Just realized that you don't need the last VISA Configure Serial Port. It's redundant. It's already set to that Baud when it exits the For Loop. I attached a VI ver2014.


That leading "\n" is most likely kicking your a(Ess Ess)  the device is responding too both term characters.

 

Otherwise, not bad!


"Should be" isn't "Is" -Jay
0 Kudos
Message 15 of 26
(1,353 Views)

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.

0 Kudos
Message 16 of 26
(1,346 Views)

@arteitle wrote:

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.


No. It still had the same issue if I just set it and left it at the correct baud rate. Always needed that extra \n.

 

As a follow-up, I found that post from last year  Re: serial write and read only reads if command is written 3 times. Yamaeda seemed to think it was a serial port/driver issue with the chipset of the USB-Serial adapter. That may or may not be the case here. I don't have any laptops with built in serial ports, so I plugged my laptop into a docking station. I have no idea how the docking station's serial ports are configured. Do they use similar chipsets?

 

Not really looking for an answer. All the serial and GPIB adapters I use have been working rock solid for years. I'll just make a mental note to never use that docking station for any future test/development systems.

0 Kudos
Message 17 of 26
(1,336 Views)

@jamiva wrote:

@arteitle wrote:

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.


No. It still had the same issue if I just set it and left it at the correct baud rate. Always needed that extra \n.

 

As a follow-up, I found that post from last year  Re: serial write and read only reads if command is written 3 times. Yamaeda seemed to think it was a serial port/driver issue with the chipset of the USB-Serial adapter. That may or may not be the case here. I don't have any laptops with built in serial ports, so I plugged my laptop into a docking station. I have no idea how the docking station's serial ports are configured. Do they use similar chipsets?

 

Not really looking for an answer. All the serial and GPIB adapters I use have been working rock solid for years. I'll just make a mental note to never use that docking station for any future test/development systems.


Since you have never responded to question about "What is the device?"  We cannot help with the specifics.  If you wish to troubleshoot the "General Case" more power to ya!  

 

Help can be available... did you want help?  or are you just venting?


"Should be" isn't "Is" -Jay
0 Kudos
Message 18 of 26
(1,326 Views)

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.

b.  I can confirm that the other serial parameters are correct (data bits = 8, parity = none, stop bits = 1, no control)

c.  As a reminder, I have no problems using LV's Simple Serial.vi (with term char set to "\r") when sending the "GS,0,D\r" ping at 38400 baud.  Also no problem using Tera Term in same config.

d.  I've updated the snippet based on the previous suggestions, let me know if I've misunderstood something.  I removed the VISA Clear and Flush Buffer, and I added a Clear Errors to wipe the slate clean during each iteration.  If I put various baud rates in the case structure, each iteration gives me no output but I do get a timeout error (-1073807339).  If I put 38400 in every case (i.e., the correct baud in each iteration), each iteration gives me valid data but also the same timeout error.  All of the errors are generated at the VISA Read.

e.  The test bench PC, cables, etc that are being used are all rock solid and have been reliable for years, the only *new* stuff is this code snippet.

 

Thanks for your time

0 Kudos
Message 19 of 26
(1,323 Views)

You have the wrong termination character set in the serial port config.  You set it to 10, which is \n.  You need to set it to 13 (0xD)

Message 20 of 26
(1,310 Views)