LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Help with Multimeter Data Acquisition

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.)

Download All
0 Kudos
Message 1 of 8
(3,512 Views)

Here are some more of the sub-vi's I've used.

Download All
0 Kudos
Message 2 of 8
(3,510 Views)

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 ~

0 Kudos
Message 3 of 8
(3,464 Views)
Your state machine should be designed in such a way that it should not go to cases which you are not going to use...

1.Use cluster with shift register to have ...data highway ...use bundle and unbundle data to add or process data...
2.connect the cluster data directly from one end to other.. if you are not doing anything with data..
3.Try to avoid using of use default if unwired.. because your processed data will be lost and remains only default values...
0 Kudos
Message 4 of 8
(3,440 Views)

@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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 8
(3,381 Views)

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!)

0 Kudos
Message 6 of 8
(3,306 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 8
(3,299 Views)

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!

0 Kudos
Message 8 of 8
(3,281 Views)