LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial commands does not work with string constant

Solved!
Go to solution

I have a simple serial device I have been using.  The device does not require any handshake.  Just simply send a command to the device and the device responds.  I have modified the labview example for simple serial communication and that works when I enter the string command and click the button to send the command to the device.  But when I tried putting the same serial communication example in a simple state machine where I replace the string control on the front panel with a string constant on the block diagram the serial device does not respond.  Where did I go wrong with the string constant and state machine?

 

Thank you

Danny
Download All
0 Kudos
Message 1 of 11
(4,397 Views)
Solution
Accepted by dannyjhu

The string control that works is in \-codes display, while the diagram constant is in normal display. Once you switch the diagram constant to \-codes, you'll see that it is actually "/1ZR\\r\\n". Switch it to \-codes, re-enter the desired text, and see if things improve.

 

 

 

Message 2 of 11
(4,390 Views)

I additions, there are a few other things you should improve:

 

In both programs, you configure (and later destroy) the visa session from scratch with every iteration of the loop even if you actually don't write anything (case is false). That's a huge waste of resources. Typically, you would configure the serial session once before the loop, use it (e.g. write) inside the loop, and close it after the main loop at the end of the program.

 

In the "Serial ok" program, you do this millions of times per second because there is no delay (small wait statement) in the while loop. You are burning 100% CPU for no reason at all.

 

Even better, use an event structure that only spins the loop when you need to send data or stop the program.

 

In the "serial does not work" program, an event structure would again be more reasonable.

 

Why is there a sequence structure in the "Prime" case? Does it really matter in which order the two frames execute? Since both execute in a blink, order should not matter.

Message 3 of 11
(4,387 Views)

Altenbech,

 

Thank you for the help. I rewrote the "serial does not work" to move the the visa configuration and Visa close out of the case structure.  Is this the  preferred way or should it be moved outside of the while loop and use shift registers?  I had the flat sequence in there thinking it would act as a delay to allow the serial device to complete the command before another command could be sent. Since the serial device does not send back a handshake when the command is completed I need to include a delay of a second or two. What is the best way to do this?  

 

 I have not used an event structure before but if it makes more sense to use an event structure than a case structure now is a good time to switch.  Could you give me an example to get me started? 

 

Thanks again for your help.

Danny
0 Kudos
Message 4 of 11
(4,364 Views)

dannyjhu wrote:

...or should it be moved outside of the while loop and use shift registers?


  • You should move it all the way outside the loop. Since the content does not change a shift register is not really needed but does not hurt either. (you should use a shift register in the case of FOR loops, to keep the the resource valid even in a case of zero iterations.)
  • Why are you wiring the string constant to the case selector? Since it is never "True", you'll never send a command!

 

Here's how things could look. (you might also want to stop on error).

 


dannyjhu wrote:

I had the flat sequence in there thinking it would act as a delay to allow the serial device to complete the command before another command could be sent. Since the serial device does not send back a handshake when the command is completed I need to include a delay of a second or two. What is the best way to do this?  


Well, you had a dialog popup in the second frame, so the case cannot complete until it is OK'd. without the sequence, the popup and serial command execute in parallel, but the case will not complete until both complete. The delay is given by how long you wait to press that button ;). Should be long enough.


dannyjhu wrote:

I have not used an event structure before but if it makes more sense to use an event structure than a case structure now is a good time to switch.  Could you give me an example to get me started? 


Maybe later...

Message Edited by altenbach on 03-08-2009 12:20 PM
Message 5 of 11
(4,351 Views)
That didn't seem to work for me.  In the basic serial write and read, all I need to do is send a 'GOK\r\n' to get my controller to turn on and a 'S\r\n' to turn it off again.  For some reason, constant strings don't work even when I use '\-codes display' and enter everything in properly.  What's wrong with my code?
0 Kudos
Message 6 of 11
(4,156 Views)
Ok.  I've tried using NI Spy to compare the serial commands traveling to the board using "Basic Serial Write and Read" and my code.  They are identical except for the flow control, which is "OFF" for the "BAsic Serial Write and Read."  It appears that the commands are going to the board with my code, but nothing is happening.  The only time it works is when I use "Basic Serial Write and Read." 
0 Kudos
Message 7 of 11
(4,131 Views)

Why are you sending the S\r\n command as part of your series of Read/Writes above, but also potentially sending when the timer as elapsed at the bottom?  If the timer has elapsed, it is possible that you send the S\r\n command before your GOK\r\n command.  There is no dataflow dependency that would control what goes first.  And I don't understand why you have a separate path for the S\r\n since it is already occurring above.  And when it occurrs above, you wait and receive some data back.  I think your commands are stepping on each other.

 

Even if what you did is truly what you want, there is no need to have two VISA closes outside the loop since both are closing the same VISA reference that got branched inside the loop.

 

PS rather than using hidden controls on your front panel for setting the serial settings, right click on them on the block diagram and select Change to Constant.  Now it is possible to see what they are.  And since you hid them, apparently you don't want any user to be able to change them before running the VI anyway.

0 Kudos
Message 8 of 11
(4,120 Views)

Well, I simplified the data flow greatly and it still doesn't work with constant strings being passed, but the same commands still work with "Basic Serial Write and Read."  Do you have any other suggestions?  The delay between 'Go' and 'Stop' is plenty long enough.

 

Thanks.  

0 Kudos
Message 9 of 11
(4,107 Views)

There is no logical explanation for that unless you are sending something different that you don't realize with the example vs. your VI.

 

Try running NI-SPY while running your VI and then the Serial example.  That will show you if anything different is going out of the port.  Put some probes on the error wires to see if any of the VISA functions are returning errors that you are not seeing.

0 Kudos
Message 10 of 11
(4,090 Views)