LabVIEW
Typdef - There must be a better way!
Years ago I made a great little LabVIEW code that uses a typdef to inject calibration and serial number information about my sensors into my save file. This didn't seem like the best way but it worked and I could live with the drawbacks.
Well, I can't anymore. Other people have to use the code and the number of sensors I have available has ballooned.
How it works: I have a little section of my script with 20 copies of the typdef in it.
When I select the drop-down I have a format of "serial# (space) calibration" which I pull apart later when I put it into my TDMS file. Each sensor gets its own values in the file. It works great.
The problem is that with the typdef I can put 20 of the same sensor in and the software doesn't care or notice. It will happily run and record this data... On the one hand, this is good because I'd rather collect the data and sort out the problem later. However, if there is a way to NOT have this problem that would also be great.
Is there a better method to do this than typdef or a way to force the typdefs to recognize the values that are already taken? Honestly, loading in a database every time might be better if that's an option. I could keep it updated in a central location and it would likely be easier to work with than the typdef interface.
To be clear, I'm not saying typdefs are bad! They're great and useful tools, I think I'm just pushing it to do something that it isn't quite meant to do.
LabVIEW file and typdef are attached. I deleted anything that wasn't pertinent and only left in the typdef and TDMS portions.
I'd dump the typedefs and load the sensors from a file.
The way I see it, you have two problems to solve that are unrelated.
1- You need a way to keep track of your sensor information (calibration values, etc)
2- You need a way to ensure that selecting a sensor one time means you can't select it again.
Trying to combine these will be frustrating, so just separate them out. For #1, I'd heartily recommend making a JSON file using the JSONText library to load your sensor data. It will be MUCH easier to keep up with than updating a typedef, it'll be super flexible, and it'll be readable by other programs (should you need to do so later).
For #2, I think I'd write some reusable code (perhaps a QControl if you're feeling like learning something new) that takes an array of references to all of your dropdown boxes (or, a single reference to an array of dropdown boxes). The dropdowns should be rings, not enums, since rings can change at runtime.
When you initialize your control, feed it an array of all possible sensor types. I'd recommend a Set for this. Each time you have a Value Change event, update another Set that includes everything that's been selected already. Now, when you have a MouseDown event, do a boolean difference between the set of "all sensors" and the set of "already used" sensors. Now, the only ones you can select will be the new sensor.
(Note: be sure to leave one option in the dropdown to "none" or similar. That way if someone selects a sensor and decides they don't want one there after all, they can clear the box.)
@skinnert wrote:Is there a better method to do this than typdef or a way to force the typdefs to recognize the values that are already taken? Honestly, loading in a database every time might be better if that's an option. I could keep it updated in a central location and it would likely be easier to work with than the typdef interface.
A database or databases (a DB server (recommended), a DB file or even simple files) sound like a valid solution.
@skinnert wrote:To be clear, I'm not saying typdefs are bad! They're great and useful tools, I think I'm just pushing it to do something that it isn't quite meant to do.
Yes, type defs are useful to define types.
You're using one to store data, which is OK if the data defines the type. This might have been the case when you started, but you've crossed the border. Your "type data" now became just "data", so you need a data solution.
Search LabVIEW like a graph! 
