By Ryan Vallieu
I have seemingly found an issue with the shipping example code for Nested Malleable VIs. Another user has verified that he saw the same behavior in 2019.
I am working through the examples and the presentation from NIWeek 2019. In running the Lesson 2b code (C:\Program Files (x86)\National Instruments\LabVIEW 2019\examples\Malleable VIs\Nested Malleable VIs) I found the Equals.vi in the class was not being leveraged and the search failed. When I went to my LabVIEW 2018 machine and ran the Lesson 2b.vi the code worked to find the element by correctly leveraging the in-class Equals.vi.
One difference I see is that in the 2018 example the Equal.vi is in the example folder with the code, and in 2019 the Equal.vi has been moved to VI.lib - otherwise the code looks to be the same. The Equals.vi code looks identical, and the calling VIM look identical. I posted on the LabVIEW NI.com forum here:
I am trying to determine what may have broken or changed between the implementation in 2018 and 2019, visually the code looks the same.
I currently have a project that I am refactoring. There is a lot of coupling that is not sitting well with me due to typedefs belonging to a class, then getting bundled into another class which is then fired off as event data.
Effectively, I have class A with a public typedef, then class B contains ClassA.typedef and then class B gets fired off in an event to class C to be handled. Class C now has a dependency on class A which is causing a lot of coupling I don't want.
For my real world example I query a bunch of data from our MES, which results in a bunch of typedef controls on the connector panes of those VIs. Those typedefs belong to the MES class. I then want to bundle all that data into a TestConfig class and send that via an event to our Tester class. But, now our tester has a dependency on the MES.
I see a few ways to handle this. First is move the typedefs currently in the MES class, to the TestConfig class. The MES VIs will now have the typedefs from the TestConfig class on their connector panes, but at least the dependency is the correct "direction." Or, I can move the typedefs out of classes all together, but then I am not sure the best way to organize them. Looking for how others have handled these sorts of dependencies.
I am programming with LabVIEW for around 2 years and was recently stumbled upon LVOOP.
I am required to write a communication protocol to work with a micro-controller, which later will be also used for ATP and debug purposes.
I want to build the program "correctly" from the beginning so it will be maintainable and flexible to additions and changes.
My natural way of building a program would have been a queued state machine, with several loops, each loop is in charge of a different module (one for GUI obviously), but as I stated in the beginning, I want to use LVOOP.
Does anyone have a LVOOP project I can use as reference? I've searched online and found some nice examples, but they are small and teach you the basic stuff.
For me it's important to see the how to use the project tree wisely, where to place the classes, see the managing loop and to learn as much as possible before I create one of my own.
Thanks in advance,
By ted Francis
I am new to LVOOP and have jsut started writing my first LVOOP program which I have attached.
I would appreciate greatly help with the question I have
Thank you in advance
This vi will perform two tasks
1.Generating Report data sheet for metrology
2. updating the scales in a MAX .nce file
1. Metrology will input calibration information into the tables on the tabs
Metrology will then click "Update Tables" then "Create Report ( create report section of code is not yet written
Update Tables will write all information entered in the tabs to class varaibles and will also delete current Max informatiomn
2. Metrology will click "Load NCE Scale"
vi will prompt for nce file to load and then once file is selected, display existing scales for two channels (Current Motor 1 and
Current Motor 2)
Metrology will then click "Update Scales" the program will replace the existing scales with those entered in Step 5.14 and 5.15
from the tables on the tab
Question 1. Steps 5.14 and 5.15 are needed by both classes ( Table Variable and MAX) - what is the best way to share this information
CAT0000032 Class Version.zip
I was browing through the actor framework discussions on the NI site yesterday and I came across a statement by AQ.
Never inherit a concrete class from another concrete class
I had to think about that for a second. The more I think about it, the more I realise that all of the LVOOP software I have been writing more or less adheres to this idea. But I had never seen it stated so succinctly before. Now that may just be down to me being a bit slow and all, but in the muddy and murky world of "correct" in OOP-land, this seems to be a pretty good rult to hold on to.
Are there others which can help wannabe plebs like me grasp the correct notions a bit better? How about only ever calling concrete methods from within the owning class, never from without? I'm learning for a long time now, but somehow, my expectations of LVOOP and the reality always seem a little disconnected. AQs statement above helped crystallise out some things which, up to that point, had been a bit nebulous in my mind. Well, I say I'm learning..... I'm certainly using my brain to investigate the subject, whether or not I'm actually LEARNING is a matter for discussion... The older I get, the less sure I am that I've actually properly grasped something. The old grey cells just seem to get more sceptical with time. Maybe that in itself is learning...