12-22-2020 07:04 AM
That'd be the big and serious conversion. The easy one would be to just place the FGV as part of a class. I'm not 100% sure, but I think each instance of an object would have its own FGV. If I'm wrong about that, the data would need to transfer to Object memory instead of the shift register.
Then, for simplicity, you can keep the FGV as a public method and handle everything like now, but it'd be prettier if you split out the actions to methods.
(I've split out methods even with a 'classic' FGV by having it in a library and making wrappers for common functions)
12-22-2020 07:12 AM
So Bob, how exactly do the proud parents replace the nurse-chosen "raw" refnums with names like "Cornelius" or "Rumplestiltskin"?
Also, when you mention an array of these babies, you say "even when they're not identical" - for them to be elements of an array, they have to be identical (or I guess they're different clones, right? Same types) - paul
12-22-2020 07:43 AM
I'll have to do some serious playing about with that idea Yamaeda, thanks as always for your tutoring! paul
12-22-2020 09:00 AM
Here's a thread with a nice, succint illustration of how to do it. I've linked straight to the code snippet msg, but I'd recommend you read the whole thread. And since past threads show that you don't mind digging in deeper, I'd also recommend you follow the links I posted late in that thread -- they lead to a long thread that meanders about with less focus, but I think there's enough interesting stuff there to be worth the effort. Once you get there, start from the beginning.
Essentially, you'll use VI Server to open N reentrant instances and create a set of N references to those distinct instances. Each part of your code that needs its own unique instance needs to keep reusing the same ref from the set. (Note that you may need to and so definitely should have the reentrant FGV in question configured to use "prealloacted clones").
Depending on how your code is structured, you might be able to make each module responsible for obtaining its own single VI Server reference that it keeps using. When I did a similar thing, I needed a single centralized set (which I implemented as a simple array).
-Kevin P
12-22-2020 09:18 AM
Fantastic - you guys have opened a bunch of new doors for me! Thanks for the mentoring! paul
12-22-2020 08:51 PM
@PaulOfElora wrote:
So Bob, how exactly do the proud parents replace the nurse-chosen "raw" refnums with names like "Cornelius" or "Rumplestiltskin"?
Most use a "String" identifier (though other glyphs are possible -- cf the Artist formerly known as Prince ...
Also, when you mention an array of these babies, you say "even when they're not identical" - for them to be elements of an array, they have to be identical (or I guess they're different clones, right? Same types) - paul
Well, strictly speaking, the references need to be "identical" in type, and get saved in an Array, but the things they refer to can be "different clones" (even our identical twins are subtly different, one a "righty", the other a "lefty", for example).
Bob Schor
12-22-2020 09:40 PM
Excellent! Very excited to get this working, thanks much, Kevin - paul
12-22-2020 09:43 PM
Bob - like I said, this opens some new doors for me, I definitely heard the 'click' of the ratchet slowing elevating my LabVIEW brain! I'm going to try this tomorrow night, thanks much, paul
12-26-2020 09:28 PM
Dang, still confused. I tried this simple little ditty and haven't gotten it to work. All I want to is run a bunch of FGV state machines, each with their own unique data. Evident;y, I am barking up the wrong tree with this solution... Anything jump out at you folks? Thanks for the help, paul
12-27-2020 07:45 AM
Your posted code sure seemed to work for me (once I fixed the path to "Little VI.vi" for my download location).
But you did some things different than that illustration I linked earlier.
I don't think you need that more complicated usage of "Start Async Call" and "Wait on Async Call" if you have a reentrant FGV taht's going to execute quickly Just use the simpler "Call By Reference" (where you can wire both inputs and outputs) in place of both.
Once you do this, the call to open the VI ref should designate 0x08 as the number to feed into 'options'. It means "prepare for reentrant call" and is also simpler than the meaning and usage of the other bit-encoded flags you were using.
-Kevin P