A subVI don't want to work, but just casually and only if used in the main VI

[PaulanTony]

Hello everyone,
I'm here to show you my problem, since I've already tried everthing I read and I and my and my friends had in mind.

I'm doing a Measurement Station with LabVIEW for a University course: the purpose is to control two boards ST NUCLEO F401RE while one, which we'll call from now the Attacker, puts a PWM on the JP6 jumper of the other board, which we'll call the Victim (properly modded).

Now, this VI has to do the following things:
- choose random parameters to make a PWM signal

- transmit these parameters to the Attacker and prepare it to start the Signal

- start on the Victim a AES crittography program

- start on the Attacker the PWM signal while the Victim is encrypting

- control in the end it the encryption has been disturbed by the PWM signal

All these things are made with 5 SubVIs into the main VI: 1 for the parameters, 1 for the arming, 1 for the encryption start, 1 for the start of the attack and 1 for the rest of the AES program. All of this is put in a case structure, which is put into a for loop to make a spreadsheet.

Now, I made all of this, I made the Front Panel, I made the SubVI, and each thing stand-alone works; but if I made all work on the main VI, I have always the same problem: the Victim SubVI (or, to be more precise, the Victim 1 SubVI, since I had to split it to make it work while starting another SubVI with a result got in the middle of this) doesn't work.I used the probe to understand what happens, and basically I don't now how and why, the VISA Read don't wanna work. If I use the Victim SubVI standalone, it works perfectly. The strange thing is that even if I open the SubVI from the main one and use it standalone still doesn't work.

I supposed that the problem was that there were two subVI with different COM input in the same case, but even separating them doesn't work.
I tried to remake into the main VI what the Victim 1 SubVI does, supposing the problem was the excess of SubVIs... but nothing.

The only thing that I got making all these tries, other than frustration, is that the VI may work once in a while, but after this good attempt nothing more.

As you can see, for this I've also filled the VI with VISA Clear and VISA Close when I needed to clean all. I've also used VISA Flush, but still nothing.

My supposition now is that the program is just too heavy to make these things, and this weirds me out because it's a professor's request. Sure, probably there's another way to do these things, but I really don't understand what is so heavy and why nothing shows me it: I've tried to delete some SubVI as I said, and nothing changed.

I hope someone is able to help me, and thank you in advance.

P.S. : Sorry for my eventually bad english.

[altenbach]

You will get better help if you do a "save for previous" (e.g. 2020 or below) and attach again. Not many have LabVIEW 2025 installed.

[PaulanTony]

You're right, I'm sorry, I didn't think about it.
Here it is. 
I also added a LabVIEW VI i modified and used into a subVI for Random Numbers generation and a CSV Dataset file for save the spreadsheet.
Have a good day.

[altenbach]

You need to start with some basic tutorials.

Let's look at "measurement station", which I assume is your toplevel VI:

• There is no toplevel loop. Are you using "continuous run?
• You have five(!) code islands that all run in parallel or random order.
• There is blatant overuse of value property nodes (ad local variables)
• Why are most of your front panels and diagram maximized to the screen, even if the code is small? Super annoying!
• The use of Stop(abort) is rarely needed
• Your subVI max random has a nonzero chance to never return, depending on the inputs and since it does not show the panel, the inputs can never change once called. 

Can you describe How you use the program and the exact sequence what the program should do? What the default inputs are, what you expect to happen, and what happens instead. The words "don't work" is way too vague.

I have the feeling that the entire thing could be rewritten with 20% of the code.

[PaulanTony]

Thanks for the answer.
I admit I didn't look for basic tutorials, since I did just what has been told at my course.

I'm going to explain to you what the sequence should be:

1. After the turn on, the machine picks the inputs given by the user into the "Values selection" section and give them to the Max random subVI. The max random subVI check that the range are right and use them to output 4 random numbers: these will be the Number of Glitch, the Delay, the ARR and the CCR that the Attacker will receive to make a PWM signal. The subVI can signal if the max ranges are right or wrong and shows the values picked randomly into the ranges. When the numbers are generated correctly, is also signaled that the Attacker is in Idle (it's needed figuratively to say that it's doing nothing).
2. The values generated by the max random subVI are used as input into the Armed subVI: this subVI communicate with the Attacker, sending it the values generated, checking if it received them correctly and putting it in a "Armed" condition, ready to receive the Attack trigger (this one will be sent directly by the Victim to it from a pin on the board). After the Attacker is armed, is signaled that the Victim is in Idle (i.e. it's just doing nothing).
3. After arming the Attacker, it's the Victim turn: it receives the start signal for a AES crittography firmware. The Victim 1 subVI basically just starts the encryption and verifies that the encryption started. The encryption started correctly is signaled by a LED and the turing on of the LED starts other subVIs. Obvoiusly, when the encryption starts and the Encrypt LED is turned on, the Idle LED is turned off.
4. The Victim 1 subVI start the Attack subVI: in this subVI, is just verified if the attack is starting. Basically, the encryption on the Victim turns on a pin on the board, and this turned on pin is connected to the Attacker, which use this switching value as a trigger to start the PWM signal. When the PWM is started by this pin by the Victim, also report to the VI that the attack is started, and report also the end of the PWM. The Attack subVI just read this, and shows it by controlling a LED on the front panel. The PWM has to disturb the Victim only during the encryption, and that's why the attack is triggered by the Victim.
5. The Victim 1 subVI starts also the Victim 2 subVI: this VI just follows the rest of the AES crittography. It checks the end of the encryption, the start and the end of the decryption, then reads and shows the original, encrypted and decrypted message and, comparing original and decrypted ones, verifiies if the encryption was successful or not. 
6. Last thing into the case structure, it just turn off the Attack LED (I don't turn it off from the Attack subVI because I need to see when it turns on and the subVI result are shown just at the end of it, so putting the turn off into it will result as a never turning on).
7. Outside the case structure, another little case structure check the errors: if some LED error turns on, the measurement station save into the spreadsheet just zero, otherwise it saves the PWM values and the result of the attack (0 if the PWM didn't disturb the encryption, 1 if it managed to do it). 
8. At the end of every attempt, i.e. at the end of the while loop, these values are put in a Build Array, because I need to create a 2D array, and at every attempt a row is built. The stop of the while loop also turns off the Crittography LED (same speech for Attack LED).
9. When the entire loop structure ends, the values are saved and showed into the Final Table.
10. Outside all of this, just two case structures used to stop and reset the measurement station. These start only when the switcher is turned off ot the Reset button is pressed.

What doesn't work is the Victim 1 subVI: when it starts, it just doesn't read anything from the victim, so the subVI goes in timeout and anything works. All the Attacker' subVIs work perfectly, but even the Victim ones when are used stand-alone; but into this main VI just don't; and I still didn't figure out why.

Answering the other things you said:

• My toplevel loop is made choosing the number of attempts that the VI has to do. I can also make it run continously, but It's not my purpose, since I have to create a spreadsheet, and can't be infinite (nor I can make it run so long without make the VI save prevoiusly the values, or it will just fill the RAM).
• My overuse of property nodes and local variables is caused by these choices and by the generic instructions were given to me; mainly because I needed that some of these values as switch value for something else.
• My reset button is instead used just to clean and turn off all the LED in once, instead of turning them off and cleaning all manually everytime.
• My max random subVI don't have problems: I give it as input a max range, and the Random generators give in output some random number following the specifications given.I also put it in a case structure, as you can see, to make it stop if the values should be wrong. Until now I never experienced a non-return session, also because as I tried to structure it I've tried to make it work only with specific conditions.

I hope all this message helps to understand more what the machine has to do, or at least what I (and my professor) want it does.

Thanks a lot, have a good day.

[altenbach]

Maybe I have time to look at it later, but

• If your right-click a local variable, you can set it to "read". No need for expensive value property nodes. Typically, the wire is the variable, though.
• There is an execute option to "clear indicators when called", so you don't ever need that "hard reset"
• Entering user parameters in edit mode is clumsy. The VI should be a state machine with an idle state where you enter values at runtime.
• Where do you call victim 1?
• etc.etc
• ...

[PaulanTony]

Hi, in the last version I updated here I've replaced Victim 1 subVI with a VISA Write and a VISA Read, which is basically the same thing (Victim 1 is made with a case structure with this thing + just a first case that check the turn on of the case and an error case). It should have benn called into the case 4 of the Case structure into the While loop.
The result is the same, i.e. still doesn't work.

[altenbach]

---

@PaulanTony wrote:

The result is the same, i.e. still doesn't work.

---

There are dozens of way to "work", and billions of ways to "not work". You need to narrow it down for us.

[PaulanTony]

As I said, the behaviour is the same: the VISA Read doesn't work, the VI has a timeout and the results are none.

[PaulanTony]

No one can help me?