Linx - error cluster wired to STOP button of while loop is a requirement?

[KennyL]

Hi all,

I got kindly directed by mario_c to this arduino/labview forum, which is great. I have a question that I posted on the labview forums, but this arduino forum is the right place to be.

I'll post/paste details about my situation below:

I'm using Labview with Linx with Arduino MEGA 2560, and managed to run an example VI (thanks to 'samkristoff') that demonstrates an "analogread" function (ie. a simple analog to digital conversion), which displays results of the A/D conversion on the front panel.

However, I notice that the indicator display only works (ie. shows values....numbers) when the error cluster wire is connected to the STOP button of the 'while' loop. I notice that if I remove (disconnect) the error cluster wire from the STOP button, this would then lead to blank display (no numbers popping up while the VI is running).

Until yesterday, I didn't even know that it was possible to connect 'error cluster' wires to STOP buttons of 'while' loops. So I have been a bit out of touch. The nice thing is that the example VI file does work. But I'm just trying to understand the reason for blank display (blank indicator on the front panel when the VI is running) for cases where the error cluster wire is not connected to the STOP button.

The first attached VI named 'LINX - Analog Read 1 Channel' is the original one (which works properly).

The other one ('untitled 4') is the one with the error cluster wire not connected to the stop button, which results in blank display (when running).

If anyone uses Linx with Arduino, then could you please let me know if it is actually necessary to have the error cluster wire connected to the STOP button in order to make things work properly?

Thanks very much in advance!

[KennyL]

Hi all. I kept experimenting with the VI to try understand what conditions prevent 'analogread' values from getting through to the indicator display.

It looks like the observed behaviour might be linked to system initialisation and final system state (when the VI is manually stopped).

The VI has a while loop. I now find that the reason for blank display (or even display remaining with a value of '0') is related to the preset behaviour of the stop button, or a boolean constant wired to the stop button of the while loop.

If a boolean 'FALSE' block is wired to the STOP button only (with nothing else wired to the stop button), the analogread value CAN get through, and the VI can work....... but it will only work for this first time. If the VI is manually stopped (eg. using the general VI abort button at the very top of the labview screen), then it is noticed that analogread values will no longer get through to the indicator display (when the VI is run again).

And, for a different case...... if a true/false button (2-state button) is wired to the STOP button (of the while loop), and if the true/false button is pre-configured to (for example) a 'latch when released' operation, then the VI will work properly (every time it is run) if this true/false button is used to stop the VI. This is probably because using the true/false button to stop the VI allows the while loop to do the rest of its thing ----- such as to properly close serial communications. It is also noticed that if the VI is aborted through usage of the regular stop button at the very top of the labview window - then we will get values of 'zero' on the indicator display the very next time the VI is run.

Other consequences of not stopping the while loop 'properly' (which allows serial communications to close properly) can be serial communication timeout issues.

So --- the error cluster does not need to be wired to the STOP button. The behaviour that I was seeing earlier was likely due to the 'while loop' not being able to formally close serial communications (which can be done with a true/false button placed within the while loop). This means --- for situations like this --- don't use the regular labview 'abort' (stop) button. Use our own 2-level true/false button for stopping the while loop instead. I haven't got a full understanding of what's happening ---- but just decided to write what I saw, and write what I think - in case somebody else encounters the same question or situations.