LabVIEW
Silly & basic question - where did my child data go?
He lost me after the "F" word 😁
I'll have a look at this one.
More then often, they get so complicated it takes me more time to use them properly (or at all) then it takes to make a perfectly fitting solution from scratch. I like to have the simplest solution for each situation, not the general solution that fits all problems.
To me making frameworks seems like chasing rainbows. Things are difficult, make a solution. Solution grows. Grows more, and things are difficult again.
I guess it's mostly a matter of taste. Others love frameworks. No judgement...
I like .NET framework though...
Search LabVIEW like a graph!
@PaulOfElora wrote:
What intrigued me was his use of variant attributes as lookup tables/dictionaries, which he uses to select which measurement classes to use for particular tests/steps/HW.
That work from 2018. In LV19 and up we have maps (and sets).
Maps provide the same functionality and performance as variant attributes.
But strongly typed, and more convenient altogether. There are some real time bugs with maps in LV19 though. I doubt they will be there for long.
@PaulOfElora wrote:
Thank you guys Rolf, Carya, Yamaeda and Kyle SO MUCH! I only hope I can repay the kindness & patience y'all have shown me back to the community (OK, once I actually know something). Your words will take about a week to digest and assimilate, maybe. I introduced myself to OOP 2 weeks ago tomorrow, and strangely enough I haven't totally mastered it yet 🤔.
In my Factory scheme - our situation is this: I'm designing an upgrade to a system which they have used for 25 years. Obviously all the existing HW & SW go in the garbage can (well except for the operator GUI, which they like). But for this upgrade/renovation they want a HAL-ish SW structure for future-proofing against obsolescence. They'd gotten burned previously because the HW vendor discontinued the product line just as they'd gotten 2/3 thru a new design using that HW 😫. So here I come. I hear "HAL" and think LVOOP naturally! {only problem was I couldn't spell OOP!}. Anyway, when it's time for the next upgrade (5-10-15 years down the road), someone (probably not me) will need to write new child classes for the new hardware, but if I do it right, they should be able to just "plug them in" to my spiffy parent classes. So it's not a dynamic Factory situation - some ini files will need some new stuff, etc. but hopefully I'm just minimizing the future pain for whoever needs to do the next upgrade. Does this make sense? Thank you all again for your fantastic tutelage! Stay healthy! paul
Jumping in the pool on the deep end with HAL is like doing a MMORPG as your first game project. 😄
This is however useful information, since this means can have Read methods unique to your Analog and Digital inheritance branch (i.e. no method in the root class). So the earlier discussion about code smell and ugly interfaces can be resolved prettier. 🙂
(for some reasone i remembered your name as Elon/Elan)
