LabVIEW
Index array of a cluster
Solved!
Ouch! Who wrote that code? This needs to be rewritten from scratch, because it is full of glaring programming mistakes.
Sorry, I cannot help you at this time.
@nyc_(is_out_of_here) wrote:
Can't even open the VI.
It's for the best.
This is not a text based language, you don't need to init variables. Even if you did you don't need to re-init them every iteration. Also the wires are the variables, not the controls.
Never seen a 7 point font on a front panel before.
Using a while loop as a for loop.
Okay so you have no way of stopping your program, you have a false wired to stop, so your program either runs for all eternity, or you stop your program like you stop your car, by crashing it into a tree.
In case 4 of 8 in the top level sequence, you have two while loops, and the stop from one goes to the stop of the other, this means the second while loop will never execute more than once. Just remove it, it does nothing for you.
You are missing seeral VIs, they weren't attached.
Many wires go backwards.
It is generally bad practice to use sequence structures. Stacked are hated even more than flat, and sequence variables are hated the most of all. Try not to use them it makes debugging code very difficult.
What good is the sequence structure in side the case 6 of the sequence structure? It does nothing for you.
Lots of locals, when shift registers could be used, like the Total Repairs.
Reading a local variable multiple times in a while and for loops when it doesn't change.
Use an event structure, it help perform actions on events like control value changes. It can also handle things like when the user tries to close the window, which yours currently doesn't handle.
I'm not trying to rip you apart, but these are major red flags. You'll want to go through some free training. If you have any specific questions feel free to ask them. I tried going back to understand if you have any remaining questions and it is unclear to me. Do take Altenbach's advice on searching the array of clusters.
@Hooovahh wrote:
It's for the best.
I already listed some of the same points earlier, but there are many more.
@Hooovahh wrote:
I'm not trying to rip you apart, but these are major red flags. You'll want to go through some free training. If you have any specific questions feel free to ask them. I tried going back to understand if you have any remaining questions and it is unclear to me.
I strongly agree with this recommendation. Obviously you are coming from a text based programming background and try to do a 1:1 translation into LabVIEW. Stop progamming now! Continuing to program at this point will only cement really bad habits and will make them much more difficult to un-learn later. Do some courses and tutorials, look at the examples and design templates that ship with LabVIEW. Learn about dataflow. Once you pass the CLAD example exams, you can go back to coding.
All of our code sucked at one point, sorry if we seem harsh. First here is some free training, that you've probably seen, or not had time for.
6 Hour LabVIEW Introduction
Self Paced training for students
Self Paced training beginner to advanced, SSP Required
LabVIEW Wiki on Training
I'd like to make a few comments, you say the program is not to stop. I think we are confusing what stop means here. Is the program supposed to exit? Is there a time when the program should not be running on the computer? Someone can say "Outlook should always be running". That doesn't mean you shouldn't be allowed to close it. Same with this application. You actually are telling LabVIEW that this program should not be allowed to stop running and exit based on what you coded. A better strategy is to detect when a close is requested, using the event structure and perform closing operations. Like turn off DAQ, close log files or other various tasks.
This all sounds very unpleasant. Your boss is wrong, and I would thoroughly enjoy telling him that. Windows programs should be able to exit, with the only exception I can think, is if it is the only program running. If there is no Explorer.exe, then I can see why your program should not be allowed to exit but in any other case, this flies in the face of standard Windows application styles.
What other standard Windows practices can we ignore? Why should the left mouse button be used for selection? Lets switch the right and left mouse buttons, or use those buttons for scrolling, and the middle mouse button for selection. This is the level of crazy that some bosses go to, when they don't know what they are asking for, and are not the expert in the field where they are making decisions. A good boss knows when to rely on the people he hired, to do their job. And as a software developer that would be things like the design, and architecture choice. I'm glad I'm not in your shoes.
@NewerProductionDeveloper wrote:
Our Business Unit Leader doesn't want the programs to close "AT ALL." He has asked when I compile the program to remove ANY exit options. He had me set it up where the only way to close is CTRL+ALT+DEL.
I agree with you on stopping it at a certain point, but my boss' boss said no. lol
I agree there should not be a stop button on the front panel, that's unusual for a typical program. Instead, you can monitor a "windows close" event, i.e. when the operator clicks the [x] in the upper right corner. At this point you can throw a confirmation dialog, initialte a defined shutdown sequence, or even ignore the close action and tell the user that something is not in a state that allows safe closing of the program at this time.
There should always be some safe defined way to close a program and there are valid reasons to do so, e.g. for computer maintenance, software updates, troubleshooting memory leaks, etc.
