07-28-2016 09:27 AM
The problem is.. when i press stop, the program does not stop!!
07-28-2016 09:41 AM
Have you waited ten seconds for the next Read to complete? There does not appear to be anything in your VI that would prevent it from stopping. Dataflow will not let it stop until the VISA Read completes or times out. The Byte to Double subVI is missing but that seems unlikely to be the problem.
Lynn
07-28-2016 09:56 AM
Hi,
If i hold down the stop button for ten seconds (it pops back out on its own accord before this time).. then yes the program does indeed stop.. so this is the problem. How can i get around this ? Furthermore, i get the time out error message when the progam does finally stop!
Thanks,
Richard.
07-28-2016 10:13 AM
Richard,
You need to learn how the LabVIEW dataflow paradigm works.
Within your while loop anything which does not depend on anything else may run in parallel. So the Stop button and all the other code are parallel. This effectively means that the Stop button will be read at the very beginning of each iteration. Because the mechanical action for the Stop button is set to Latch When Released, it will pop back out as soon as it is read. But the rest of the code, particularly the VISA Read will take about 10 seconds. The while loop will not decide whether to stop or not until everything inside has completed. So, even though the Stop button may have been read seconds ago, the loop will not stop until after the Read. Holding the button down should not make any difference. Once it has been read the value will remain on the wire going to the loop termination terminal until the next iteration.
How can you get around it? You need to make everything else in the loop take less time. But shortening the timeout on the VISA Read may cause problems with getting your data since the device only sends data once every 10 seconds. There are ways to work around that but they can get complicated and the details depend on how the data coming on the serial port is formatted and how you will handle partial messages.
Lynn
07-28-2016 10:28 AM
Thanks again for your reply,
I will continue tomorrow. Should i be going down a producer/ consumer route ?
Thanks,
Richard.
07-28-2016 10:36 AM
A producer/consumer architecture might be useful in decoding the partial messages.
Lynn
07-28-2016 09:27 PM
Since you are apparently dealing with binary data instead of ASCII, you want to turn off the termination character. I also recommend using the Bytes At Port to detect if a message has started. If it hasn't, wait for something like 100ms. This will make your stop button more responsive and avoid those timeout issues. And since it looks like you are expecting 10 bytes in a message, just read the 10 bytes.
07-28-2016 10:31 PM
You can also use 'Enable Event' with event type being your Serial TermChar and then 'Wait for Event' in your while loop with a small timeout.
So, you will read the available bytes only when your event is generated that would prevent unnecessary polling.
Runjhun
07-28-2016 10:34 PM
@RJ_15 wrote:So, you will read the available bytes only when your event is generated that would prevent unnecessary polling.
That is still technically polling (wait for event, timed out, try again, timed out, etc.) and I have found it to add unneccessary complication.
07-29-2016 03:10 AM
Thanks everyone for their input in this.. Im learning lots and really appreciate it.
Crossrulz thanks very much for taking the time to make that program. Perfect thankyou!!