12-28-2022 01:11 PM
Good day, fellow programmers.
So, I have inherited a very large, legacy project that relies on heavily outdated LV techniques, or so I suppose. I am very new to LabView but decent with any other form of programming and good practices, and, honestly, I am barely putting up with the LV experience. This project has grown out of proportions and has reached a point of non-escalability, so me and my managers decided to start updating things as they come up, mainly incorporating LVOOP to stuff that spans to other closely related family of products (equally legacy).
For context, this project consists on a bunch of State Machine Pattern vis, accesible with Queues, that are meant to be run asynchronously, with no knowledge of each other whatsoever. They communicate with each other with these small Queue and Dequeue vis, and, at some point it seems, there was meant to be some sort of hierarchy with a Main State Machine on top but was lost with time, and we have these async states machines talking to each other in a ridiculously coupled inferno. As a result, information that spans the whole solution is only accesible via FGVs. These state machines are launched shortly after Splash with a Run VI on a Invoked Node as follows:
That's an example, I stripped some error handling but that's the core of it. As I understand it, the VI is run, its reference destroyed and left in the wild. Input is raw path to the Vi in disk which I find nefarious. Yes, we hope to turn these into Actors some day, but in the meantime, I have to deal with this structure.
Now I am working in one of the first "modernization" tasks, basically a Licencer which I abstracted to a decorator pattern. A client implementation of the stack would look like this:
Each new decorator of the Licencer class holds a DVR for the previous one in the stack, and the last instance is stored (as data) in an FGV (I need to be able to globally retrieve it). On that very same Vi, the Licencer methods works surprisingly well and as expected. But, if I read the FGV in another VI after the above goes Iddle, I get error 1556. I learned just yesterday that references are garbage collected when the top VI goes iddle, and that's actually fine. I can't rely on the client top VI being persistent (i.e one of these Invoked State Machines).
So, I thought of using an Actor, that's somewhat thread safe, inside an FGV holding its enqueuer, which in turn would hold in its properties the Licencer stack initialized with a message after its Launch, all within the different functions of the FGV. I'm sure this would work, but my question is, in this context, is this OK? Am I overthinking it? I've searched in the forums and I usually find the usage of Actors, DVRs and FGVs as exclusive to each other.
Thanks in advanced and I am truly sorry for the long post. I will try to implement the last part in the meantime.