07-10-2017 11:04 AM - edited 07-10-2017 11:25 AM
The output "Actual values" of the VI that I got from the company that produced my lab equipment was for example: 24,12V;12,23A;123W , so I cut off the rest of array and i got only current value. That was a tricky part, but I got it somehow.
07-11-2017 07:54 AM
So I just want to share my working prototype. I used your advices with controls/indicators, i wrote everything with flat sequence structure so it looks very nice now. Also I add some style features that are not necessary.
Thank you guys one more time!
Have a great time!
07-11-2017 08:07 AM
I'd still recommend getting rid of all the indicators that have unlabelled terminals and are hidden on the front panel. You can't see them and the VI doesn't have them on the connector panel, thus there is no reason to have them.
07-11-2017 08:34 AM - edited 07-11-2017 08:35 AM
@vladosaurus wrote:
So I just want to share my working prototype. I used your advices with controls/indicators, i wrote everything with flat sequence structure so it looks very nice now. Also I add some style features that are not necessary.
Thank you guys one more time!
Have a great time!
Upon cursory inspection, the flat sequence structure seems unnecessary, also. (With a few minor modifications to ensure proper data flow.) Flat sequences are almost never needed to ensure dataflow - and some purists will tell you even in those rare instances, a flat sequence is just a convenience and not a necessity. Creating artificial dataflow dependencies hinders LabVIEW in much the same way as artificially controlling which thread executes next in an operating system hinders the operating system. When possible, let LabVIEW (and the operating system in the example) do their own thing the way they want to do it.
07-11-2017 10:57 AM
I can tell you worked really hard cleaning this up and making the code look nice, but I just want to suggest a step further you could go if you want to have really good code. It's very best practice to have your code fit on a single screen. You can do this by creating subVIs from sections of code that all do one function, and also by changing this from a long sequence to a state machine. By using a state machine architecture, you'll be able to separate each step into a state and your program will move from one state to the next and will be able to stop in the middle if needed, which is a feature that I think you would benefit a lot from.
Here is an example of how you could start changing your code to a state machine. I've just put in the first few steps of your code so you can get the idea:
(this is a snippet, so you can just drag it straight onto your code)