LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Overwrite byte array

Solved!
Go to solution

The problem is.. when i press stop, the program does not stop!!

0 Kudos
Message 11 of 20
(2,991 Views)

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

0 Kudos
Message 12 of 20
(2,987 Views)

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.

0 Kudos
Message 13 of 20
(2,984 Views)

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

0 Kudos
Message 14 of 20
(2,981 Views)

Thanks again for your reply,

 

I will continue tomorrow. Should i be going down a producer/ consumer route ?

 

Thanks,

 

Richard.

0 Kudos
Message 15 of 20
(2,979 Views)

A producer/consumer architecture might be useful in decoding the partial messages.

 

Lynn

0 Kudos
Message 16 of 20
(2,975 Views)
Solution
Accepted by topic author lvrichard

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 17 of 20
(2,961 Views)

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

0 Kudos
Message 18 of 20
(2,959 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 19 of 20
(2,957 Views)

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!!

0 Kudos
Message 20 of 20
(2,942 Views)