My LabView program will not start

[vladosaurus]

Hi everyone,
I made a pretty complex program for battery measurments, where I control a several lab machines.
BUT...
The thing is that a program works fine when I start it, but the problem is that it can not start without "Highlight execution". When I turn the animation on, it works well and without it happens nothing. I want to build .exe file so I made a button "Start" in a front panel, but it didnt help. It runs only with simulation.
Does anyone have an Idea how to fix it or what could be a problem? 🙂

Have a great day!

[RavensFan]

I'm not sure how much help you expect with debugging your "pretty complex program" when there is no code for us to look at.

Let me ask, did you use local variables in your program?

Whenever I hear someone say that something works with highlight execution and doesn't at regular speed, frequently the problem is that they used/abused local variables and set up race conditions where the code is being executed in an order that they didn't intend.  For example, a local variable of an indicator is read before its terminal had a chance to be written to elsewhere in the code.

[Norbert_B]

Post your code.

Highlight execution does two things:

a) Slow down execution

b) serializing execution

Both points will disguise race conditions which can have any effect on your application (like giving incorrect values up to crashes).

Without seeing the code, we cannot help in identifying if there is a race condition.

[vladosaurus]

So this is just a prototype, I am not a professional as you guys but I am doing my best 🙂
I had also a problem with for-loop so I made it with copy-paste way.. you will see

Thanks for answering and help!

[RavensFan]

The first four problems I see.

1.  You don't have any wait in the first loop checking on the OK button.  That is known as a burner loop as it is burning up CPU resources checking on the status of the OK button.  Even putting a wait function in there with a 0 millisecond wait will allow LabVIEW a chance to yield the CPU to other processes.

2.  You have several while loops where you are checking the value agains "0,5".   I assume that means 0.5 as in one-half?  The problem is you are comparing strings and not numbers.  So you are checking to see if a string is alphabetically before "0comma5" and not whether the value that the string represents is greater than 0.5.

3.  You have a large amount of serialized code where you have 60 second waits in between.  Once you start this VI running, it will take a long time to finish.  You should look at a state machine architecture where there is a Wait state in between to allow a chance to detect that the user wants to end the program early and react to it.

4.  Why do you have so many hidden controls and indicators?  The controls are all empty so I have no idea what kind of commands you are trying to send to your device.

Also, good LabVIEW coding practices, you should make sure the labels are visible on all the terminals on your block diagram so you can identify what control or indicator is being written to or read.

The good thing is that my first thought you had local variables causing a race condition does not seem to be occurring in the VI.

[Norbert_B]

Adding to Ravens feedback:

• Your controls for set values (Voltage and Capacity) are outside your frame. That means that the value will either be 0 or the value the controls had when you last executed the VI. This is most likely not what you thought would happen
• You have no idea if there was an error (because e.g. communication to serial happened too fast). If the instrument driver VIs are written properly, they will do NOTHING when an error is passed to them
• Stopping highlight execution fastens code execution. I assume that your serial device is too slow to get all the communciation with "normal speed"

[vladosaurus]

My controls for set values (Voltage and Capacity) are outside the frame, yes, but it was a try to fix the problem. It wouldnt work even if they were inside the frame.

Serialized code where it waits 60 second in between is necessary for the process, this program should generate an Auxiliary file for Texas Instrument microchip. Maybe I supposed to do it with for-loop but I am not sure if it would make any difference. I dont use other commands because I dont actually need them, for Example, when I turn the Input on, it doesnt expect any "Value" from me, and if didnt make the control it would throw me an error.

[RavensFan]

What do you mean by "it throws an error" if there is no control?  Is it during run-time which is technically what "throw an error" would mean?  Or during development, where you have a Compile error because a subVI requires an input an it doesn't have it?

If it requires an input, shouldn't it have some meaningful value?  Sending an empty command does not make sense.  And you should make it a constant rather than a hidden control

I think you need to take a step back and get rid of most of the code.  Create your VI so it just does the first one or two steps and see if you can get that to work.  Only then should you build on it.  And when you do, look up state machine architecture.

And what about my comment regarding comparing strings?

[vladosaurus]

It means that I had to use them all (to initialise them) even if I dont actually need them. I got an error if I didnt create an indicator/control at all, its probably my bad because I left it as hidden control.. (I thougt that I just have to do it  )
My idea was to check the current value in every loop, and when the current drops at lower than 0,5 Amper (what means that BMS turned the battery down) then the program can continue, maybe you have right but it has worked the way I wrote it..

[RavensFan]

If you got a string and was able to successfully compare that to a string "0,5" then you were really lucky if it worked the way you wanted.  You should be comparing numbers, not strings.