03-07-2009 06:43 PM
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
Solved! Go to Solution.
03-07-2009 07:39 PM
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.
03-07-2009 07:54 PM
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.
03-08-2009 09:52 AM
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.
03-08-2009 02:19 PM - edited 03-08-2009 02:20 PM
dannyjhu wrote:...or should it be moved outside of the while loop and use shift registers?
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...
04-28-2009 06:10 PM
04-28-2009 08:18 PM
04-28-2009 10:39 PM
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.
04-29-2009 01:25 AM
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.
04-29-2009 09:53 AM
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.