06-25-2015 08:35 AM
Hello community, and bear with me because the incoming vi is an unworking trainwreck.
I have just been assigned to work with LabVIEW in my job position with no previous knowledge of it. My task seems relitively simple: create an interface which will allow a user to establish communication with a multimeter, choose how often to sample for a chosen amount of time (with various measurement options such as voltage, current, resistance, etc. ,) and then save the data to an excel spread sheet. The idea is that it will be malleable enough to work with any instrument given to it afterwards (i.e. non-multimeters).
I asked a co-worker, who has a little more experience than I do, and he suggested to start with a 40-case state-machine (40 because is gives a lot of space to work with and allows you to expand whenever you think of something to add.) I've also utilized a couple of sub-vi's to experiment with.
My current issue is that, because of the shift register, the vi will not run as not every state makes use of the data being passed. As well, I believe my sampling methods may be incorrect, especially as I have yet to figure out a way to implement the "Has the time allotted passed yet? If yes, take a sample. If no, keep waiting" idea properly.
I also feel like this may not be the best approach for the task I have been assigned, but it is what I have to begin with and make my way through LabVIEW. Learning is fun!
I'd appreciate any help that can be made of this mess. I am working with LabVIEW 2001, and the instrument (which had its own functions palette) is an hp 34401A multimeter.
(I'll post the other sub-vi's I've used in a comment.)
06-25-2015 08:36 AM
Here are some more of the sub-vi's I've used.
06-26-2015 01:54 PM
A few things to note:
1. You can always add case to a case structure by right-clicking on the case structure's border and selecting 'Add Case After' or 'Add Case Before'.
2. Every output tunnel in each case in a case structure needs a value. So, each tunnel must either have a wire wired to it (it is common to see wires go straight through a case if that data is not being used in that case) or you can right-click and select 'Use Default If Unwired' which will assign the default value for that data type to the output tunnel.
'Case Structure'
http://zone.ni.com/reference/en-XX/help/371361K-01/glang/case_structure/
Hope this helps!
~ Q ~
06-26-2015 10:50 PM
06-27-2015 12:31 PM - edited 06-27-2015 12:34 PM
@StudentWithLasers wrote:
Hello community, and bear with me because the incoming vi is an unworking trainwreck.
I asked a co-worker, who has a little more experience than I do, and he suggested to start with a 40-case state-machine (40 because is gives a lot of space to work with and allows you to expand whenever you think of something to add.)
I would steer clear of this person who suggested using a 40 state case state machine because they don't have a solid grasp of LabVIEW themselves. If I were you, I'd take my chances with this forum where you can have several people to confuse you rather than just one. 😉
If you use an enum (preferrably typdef'd, but why is beyond the scope of my post) you can right-click on the border of the case structure and choose "Add case for every value" it will automatically populate the case structure with a case for every value. Furthermore, if you choose "Remove default case" every time you add something to the enum, the VI will break (broken arrow), forcing you to add a case for every item that you added in the enum. I've only rarely used a default case because if I had more than one state that required the same stuff to happen, I'd just call the same state! Or if the states needed to be named differently for the developer's sanity, I'd simply make that case respond to the appropriate multiple values. I'd much prefer the VI to break when I add something to the enum and take care of duplicate states manually than have a default case and wonder why my VI was behaving strangely when it ran after I added some new items to the enum. (Sometimes it will still behave strangely, but at least I will know it's because of something stupid I did in the code and not because it's executing the default case.)
Oh, heck, this got so involved that I may as well talk about typdef'd enums anyway. Ideally, you typedef this enum because that way all copies of the enum get updated every time you add a new value to the typdef. That way you don't have to hunt around your application to find all the instances and update them manually. AND, of course, if you followed the above paragraph recommendations, all the VI's that had cases that depended on updated typdef would break, allowing you to easily go to that VI and add the appropriate cases.
06-29-2015 07:22 AM
Thanks for all the insight and suggestions, everyone. They were very helpful!
Unfortunately, the project got scrapped anyway. (But I will continue to ubild for my own profit!)
06-29-2015 07:32 AM
StudentWithLasers wrote:
I asked a co-worker, who has a little more experience than I do, and he suggested to start with a 40-case state-machine (40 because is gives a lot of space to work with and allows you to expand whenever you think of something to add.)
Adding to Bilko's comments....The point of a state machine is that it is already expandable. You just add cases when you need them. Having extra cases that do nothing does nothing but confuse people I wonder if your coworker was talking about a sequence structure (which you should avoid). Or Bilko probably stumbled upon it: your coworker does not use Type Defined enums.
06-29-2015 11:19 AM
You are correct in assuming that he does not use type-def enums; the example I gave above was his template to me and I simply added the sub-vi's.
Quite confusing to a newbie!