I would like some help in determining the proper structure/implementation

[doyles]

I would like some help in determining the proper structure/implementation for the following scenario:

• I have ~10 steel rods that have been equipped with a strain gauge.  The most I would have is ~30 steel rods.
• Each setup has had a 10 point calibration done.
• These steel rod/strain gauge setups are assigned a calibration number.
• The data would be grouped for each steel rod and identified by the calibration number. 
• I would like to use that calibration data to determine the Young’s Modulus for each steel rod and store that within the specific rod’s information.
• I want the user to be able to add new steel rods dynamically and the Young’s Modulus calculated and stored with it.
• There are two different types of rods.
• The cross-sectional area of the rod needs to be stored and that value is constant based on the rod type (so there are two different area values).
• After a rod’s calibration data is entered the first time, the data should be static so it doesn’t need to be re-entered.
• The user would enter the cal#, the 10 point calibration data, and the rod type.
• The user will only see the steel rod cal# on the FP.
• I am using a queue-based producer/consumer with event structure for the front panel interface.  So I’m thinking whenever a rod cal# was added I would call a subvi where the calibration data can be entered and then the Young’s Modulus could be calculated and stored.  An option to edit/review existing cal data should be available.
• LabVIEW 2010, Win 7.

My initial idea was:

• Rod Arr – array of clusters:
  • Rod Info - cluster:
    • Calibration number – string
    • Rod Scale cluster:
      • mV/V – double array
      • force – double array
  • Young’s Modulus – double
  • Rod type – enum
  • Cross-sectional area – double

I have not implemented this because I’m not sure how to implement that AND keep the data after it’s been entered.  And all of the bundling/unbundling anytime I want to access/edit any rod information can be BD consuming.  I thought a lookup table might work.  When I looked on the forums for a lookup table I was pointed in the direction of arrays/clusters.

So I have two questions:

What would be the best structure for the steel rod data?

What would be the best data type for the calibration# that the user can edit (enum, ring, ?)?

[Mark_Yedinak]

You should consider using LVOOP for your dsign. Create a rod class. This class would contain the basic methods and data for any rod type. Create specific child classes for each rod type you have. Use dynamic dispatch so that it would be easy to add new rod types to your system. Using dynamic dispatch would allow you to add new types of rods without having to touch your code. Specific data for each actual rod you have can be stored either in configuration files or in a database. This would depend on your requirements.

A producer/consumer for the generall application design is good. If you need to monitor/process data from the rods continually I would spawn a process for each rod by calling the "rod processing" VI dynamically.

[doyles]

I searched for "look up table" versus "lookup table" and got a few more relevant hits.  The idea of using a spreadsheet is plausible.  But as I started to fill out an Excel sheet just to see how it would look it reminded me of a config file in a way.  So I'm currently looking at using keyed sections in an ini file to store this information.

[MarkMoss]

I would make a couple of small change to your proposed data layout (highlighted in blue):

• Rod Arr – array of clusters:
• Rod Info - cluster:
• Calibration number – string
• Array of Rod Scale cluster:
• mV/V – double
• force – double
• Young’s Modulus – double
• Rod type – enum
• Cross-sectional area – double

For the calibration data, I would have an array of clusters rather than a cluster of arrays.  IMHO, this makes it easier to index through the calibration points, and makes it less likely you will ever have a situation where you don't have the same number of mV/V and force points.  I'd also move the Young's modulus, type, and area info into the Rod Info cluster.

I prefer to store this type of configuration in the system registry, but that is more complicated and far from universal in the LabVIEW world.  A simpler way would be to simply pass the entire array to the "write to binary file" function.  If you do this, however, you might want to add a version number, otherwise it will be very difficult to maintain backwards compatibility if you ever need to change the data structure.

As far as the control type, it depends on what the user is entering.  If the user is mostly entering calibration numbers already in the system, I would use a (system) combo box.  This allows the user to select an existing calibration number from the menu, but also to enter a new calibration number if they need to.  If the user will almost always enter new calibration numbers, then I would use a standard string control.  Either way, you'll probably want to validate the format of the number the user enters.

Mark Moss
Electrical Validation Engineer

GHSP

[doyles]

Thanks Mark.  I am very unfamiliar with LVOOP.  I don't even know how to create a class in LV yet!  I would need some serious help in getting that up and going as you can see.  I am interested in it and have that on my someday task list.

As you mentioned I would need the data stored in a config file either way so I'm going to pursue that avenue at the moment on my own time (I also have "create keyed section config file vis" on my task list as well). 

However, if you have some good LVOOP guides/tutorials to read or would be willing to guide me on this implenation of LVOOP, I would certainly be glad to start learning now...

One note is the rod info isn't the main part of the test program.  It's a fairly small part actually.  The rod info will provide the specific steel rod related constants (area, Young's Modulus, etc) that are necessary for the calculations done on the acquired strain gauge data.  I hope that is somewhat clear.

[doyles]

Thanks MarkMoss,

That actually was a typo: the YM, rod type, and area would all be in the rod info cluster.  I don't think it's possible to do it the way I had it initially typed, actually, since the array can only hold one data type - and that would be the Rod Info cluster.

I agree the array of clusters would be better.

However, the idea was to move away from that array/cluster structure altogether - unless it was bore out to be an overall best solution.

Each test rod will have it's own calibration data.  The 10 point calibrations are currently all done at the same load (force) values, but I can't guarantee that any future calibrated test rods will have those exact test points.  So the load values need to be editable as well, I would think.

For the cal# control, I'll certainly keep in mind the combo box. I was thinking text ring, but I'll look at both.

[doyles]

I implemented a config file setup using the MGI write/read anything vi's.  I used the array/cluster structure tweaked by MM above.  That worked pretty well.  But my concern immediately was the ability to change the typedef later on - how much work would it be to make any changes for both the config files and the code.

I've also been looking at the LVOOP stuff.  And I understand why Mark Y suggested using LVOOP with a class for the rod.  But, being so new to this, I don't really know the best way to implement the class.  What would be a good way to set the class?  Mark Y, you said I should I should use dynamic dispacthing for rod types.  The cross-sectional area is dependent on the rod type, so that and the actual rod type would be the inherited piece for the child classes to override?  And all of the other data would be a part of the parent class?

Thanks for any further help,

Scott

[Patricia B]

Hello,

Perhaps some sample code would aid in helping you with using LV OOP. Below is a link to an example from our NI Community page that uses a Car example class. I am also going to list some other articles that you may find of some use while implementing your design.

LabVIEW Object-Oriented Programming: The Decisions Behind the Design

http://zone.ni.com/devzone/cda/tut/p/id/3574

LabVIEW Object Oriented Programming - Car example

https://decibel.ni.com/content/docs/DOC-12496

Applying Common Object-Oriented (OO) Design Patterns to LabVIEW

https://decibel.ni.com/content/docs/DOC-2875

Best, 

Patricia B.