LabVIEW
Re-initializing my array with reset button
Solved!
@cbutcher wrote:
Here's my attempt at the ClockVI with some modifications - basically I just removed the loop. Can you check to see if it does what you want? You'll also need this snippet probably 🙂
Edit: Depending on how your measurement works, you might need to right click on the tunnel out of the loop and change the mode to Concatenating.
I think it was a good try but it does not run continuously unless I hold on the start button. For the problem I mention to you, have you figured out how to simplify it?
In your collection of Delete From Array, do you get values (non-zero) out for all of the indicators?
I think you could use either Index Array, or a For loop (possibly with shift register) or both to simplify the code, but first check that it's doing what you want it to. I tried to do the same with some example array I made and it only gave an output for the first two parts.
Although I'm still not a big fan of a For loop that takes 55 minutes to run (!), I think you can fix the specific problem you're talking about by replacing the 2nd cluster input (which you unbundle to Voltage Time Log and L1-L2 Voltage) with a shift register.
Based on your video, and the DAQ video that I also found that you uploaded to youtube (yay for Playing Next...) I saw some of what you're doing with the VI.
I haven't fixed the issue with the toggle not being enabled but I'll try and explain the problem and hopefully you can see the issue. You're really close to having a nice, working State Machine but several of your states take a very long time - usually people make the states take as little time as possible, and go back to themselves if necessary (for example, for 10 minute runs, you could have it start the state and check elapsed time - if elapsed time is 10 minutes, go somewhere else (like the waiting state), otherwise, go back to the same measurement state. Then you can make the loop run every 1000ms or 200ms or something to make it more responsive.
When you start the measurement now, the state machine you have goes into the measurement state, but only the Waiting state allows toggling the visibility. Since it never goes back through the waiting state, it can't toggle. Do you see the issue?
I'm attaching a slightly modified version of your code. I didn't fix any issues, but I added an additional tab control (I don't really like Tab controls, but I think it works for this situation) to your front panel to handle some of the very many visibility changes you were making. Hopefully you see how this has allowed me to tidy the block diagram quite a lot. It only supports 2 states (Load/Temp) in the current form, but you could improve it if needed (perhaps by wiring the state to the case structure).
You previously had two case structures in the Waiting state, both of which only did something when true, plus a 3rd case structure that made one of the other two true. I replaced these with only one case structure, and moved lots of the shared code outside of the case structure. Now, there are far fewer nodes on the block diagram.
Additionally, in several places you used the For loop we discussed to change visibility of controls. This is a good plan, and it's nice to see you've been able to save a lot of space with your local variable "appended array" (I would probably shorten the name, but it's fine). However, you're wiring 11 to the For loop each time, then using Index Array with the 'i' variable. Since you want to go through all of the elements, you can instead remove the 11, place the array local variable outside of the loop, and use auto-indexing. This makes the loop much smaller and saves some space/effort. You could consider making a subVI for this, but it'll only save a small amount of space so it might not be worth it. Up to you.
Good luck reorganising your cases if you want to make it more responsive to changes during measurements. Just remember - you need to go through whichever check you need during the iterations, and it will only read a control once per iteration. If the iterations are long, it won't be responsive. If the iterations don't check the relevant variable, it won't change anything.
p.s. I hope LabVIEW 2016 was OK. I forgot if that was your version or not.
Hi Jarrold,
I look forward to seeing your next iteration!
The Test Types indicator is the tab control I mentioned - it's a little difficult to see on the front panel because I took a "classic" style tab control and then made it transparent, and hid the label and the tabs.
Unlike your existing tab control, which is a control, this one should probably be called a tab indicator! I input a value (I needed to use a conversion to U32 and then coercion, not sure if there's a better way to give the same type to radio buttons and a tab control - they're both effectively an enum) to the tab indicator and it changes which tab is displayed. This makes it just like all of your visibility properties.
Since you had two states with different controls, a tab control seemed the natural fit.
