Programmatically activating start and stop button in VI

[rlefebvre]

Hello,

I am using LabVIEW 2017, and I'm trying to output various strings to my Mbed microcontroller using the "Mbed Write" block, which is a library created to interface the Mbed and LabVIEW.

With the appropriate code in the Mbed program, the data transfer only works when I press the start button in my VI after starting my Mbed program. Is there any way to programmatically control the VI from something else so I can repeatedly activate the start and stop buttons without physically clicking on them?

I've tried using the Invoke Node block, set to Run VI, but this does not allow me to input parameters. I would like to go through a text file line by line an use those values as my inputs. In the VI shown I am using arrays of doubles; the information in the text file represents those.

I've also tried changing the VI to a sub VI and running it inside a loop, but this seems to change the functionality of the VI and does not work.

Thanks!

[Gregory]

I cannot open your VI (generally it's a good idea to backsave your VI a couple of versions when posting to the forums), but the answer to your question is just to change when your data transfer occurs. If you are pressing the button every 5 seconds for example, you'll want to send data >> wait 5 seconds >> send data >> wait 5 seconds...

When you have clearly defined actions broken up into a different states, the program can often be written in the form of a state machine. So perhaps instead of a "start" button, you have a "run script" button and input the text file path that you want to run, then let your state machine execute until you have reached the last line of your script.

[rlefebvre]

The data transfer only occurs once, when the LabVIEW start button in the VI is pressed and the Mbed program is already running.

With regards to a state machine, I don't think that solves the problem I'm looking at. A for loop that iterates through the text file lines would achieve the same purpose.

When communicating over serial, I've tried sending string data from the Mbed back to LabVIEW, using the Mbed read block, but it just doesn't work. The data is either never sent or sent improperly, and I'm not sure why.

Here is a backsaved version to 14.0. Let me know if this works. I've attached backsaved versions of this and the Mbed read and write VIs.

[GerdW]

Hi riefebvre,

the data transfer only works when I press the start button in my VI after starting my Mbed program.

There is no "start" button in your VI.

Can you describe your problem in other words - or upload the correct VI?

I've also tried changing the VI to a sub VI and running it inside a loop, but this seems to change the functionality of the VI and does not work.

You don't "change" a VI to become a subVI - you simply call it from your MainVI.

When you call the attached VI as subVI it will run until you press the stop button on the frontpanel of your (sub)VI. This is what happens due to THINK DATAFLOW!

Is there any way to programmatically control the VI from something else

What about a state machine as suggested before?

Or a QMH? This way you could send commands into the queue "from the outside"…

How does your VI "know" when/if your "mbed program" is started?

[rlefebvre]

By "start" I mean "run". My mistake.

[GerdW]

Hi rlefebvre,

again: how do you determine the mbed code is running?

What is the condition to "start" your LabVIEW code?

Once you know this condition you can easily use a state machine: wait in "idle" state until that condition is met. Then switch to "transfer data" state…

[rlefebvre]

The VI can't tell if the Mbed code is running. When I tried to send string data (over the USB cable) from the Mbed back to LabVIEW, it didn't work. I think this is because the Mbed Write and Mbed Read VIs don't support reading and writing in the same VI.

If this had worked, I wouldn't be having this problem.

I was selecting the entire while loop, and then going to Edit > Create VI. This is what I meant instead of changing to VI.

[GerdW]

Hi rlefebvre,

I was selecting the entire while loop, and then going to Edit > Create VI. This is what I meant instead of changing to VI.

What's the point in converting the WHOLE content of a VI into a subVI?

Why not simply use the existing VI as subVI of another MainVI???

The VI can't tell if the Mbed code is running.

When the VI can't determine the mbed code is running, then you need to start it manually…

(Usually you try to start a communication between both programs: when the communication is working then both ends of the communication channel are working. Usually this is used as condition for other tasks…)

When I tried to send string data (over the USB cable) from the Mbed back to LabVIEW, it didn't work.

Maybe you should solve this issue first before you try to "start" a VI programmatically… 😄

[rlefebvre]

I will try using the content of the VI as a SubVI in another VI, as you're suggesting! That is very good advice!

For now, I don't need the Mbed to send data back to LabVIEW. There are workarounds for that for this specific project. So that isn't a big concern yet.

Again, I think the VIs given (Mbed read and Mbed write) were not created to facilitate multiple executions of each in the same program. That's the ideal situation, but again, that isn't my biggest concern for my project.

[GerdW]

Hi rlefebvre,

the mbed-VIs doesn't look as they are intended to run in parallel.

They also don't look like they are tested well…

- Each time you call mbed_Read/Write they (try to) open the serial port again.

- Each time they forget to close the port.

(One might argue VISA will handle those two issues in the background, but I don't think a VI should rely on certain capabilities of the runtime libraries to justify bad coding style).

- mbed_Read/Write even allows to stop your whole LabVIEW program, which is bad. Very bad…

- They don't follow LabVIEW styleguide (like connector pattern and VI documentation).

Conclusion: use them to learn how to communicate with your mbde device. Once you understand how they work you should create your own (better) VI handling communication with mbed using the serial port…