Sub-Panel with Run async or Run VI invoke node?

[VinnyAstro]

---

@rwunderl  a écrit :

---

@VinnyAstro wrote:

However I do keep in mind the idea with multiple tabs/subs which I suppose you dynamically hide and un-hide depending on user request?

---

No, all of the SubPanels [that have modules loaded into them] are always Visible=True. They are only "hidden" by virtue of the Tab control itself. I have shells that include the shell module itself as a child module hosting other related modules, so the system is nestable. This does not seem to cause much heartburn in the UI thread.

---

What I meant was having a certain amount of tabs (one for each motor) already existing with one subpanel per tab and their loaded module in it ("on" it?), but all >tabs< are hidden except one. on a click of a button ("add motor")  a new tab is shown allowing the user to connect and control a new one.

Still unsure what you mean by using shells, but while reading messages this morning, something poped in my mind and I think it could be interesting, I'll try to create something and show it here later if that's ok (technically not the subject though)

---

@rwunderl  a écrit :

---

Yes, this is exactly what this system does. When you open the VI reference, you can specify that the reference is for reentrant run. You could also just have a PPL per module (even if it's the same source code) to avoid having multiple running modules rely on the same PPL file. If there are 7 of the same power supply, you would have 7 PPL files (built from the same source code) in the deployed folder, and you'd call each individually.

---

---

Sorry, "PPL"? 
My first thoughts on having a modular system (being able to add more motors) was to do some scripting (which I've never done before) actively adding pieces of code to create new CAN communications files ... but definitely having the code pre-loadded and "hidden" from the user seems to be the best. (Is it even possible to have some scripting done at runtime on an .exe? )

---

@rwunderl  a écrit : I hope the comments help you in some way to decide on an architecture.

---

Yes, very much!

[VinnyAstro]

---

@Mark_Yedinak  a écrit :

If you will be using subpanels I highly recommend that you look at the MGI Panel Manager toolkit. It takes care of all the panel management stuff for you. No need to re-invent the wheel. In our design we didn't use tab controls for our design. We mimicked them using other subpanels. Although our system is message based so it is easier to communicate between the various modules. Anyway, by loading a subpanel that replaces the tabs, we can have different number of tabs visible depending on which subpanel is loaded or what we are currently displaying. you can also use an array of picture controls which essentially gives you an infinite numbers of tabs. You simply load the correct images for your tab set and the user can scroll through them if there are more than what is visible on the screen. though I don't recommend that you have so many that scrolling is required. It just gives an option for a variable number of "tabs" at run time.

---

Ah thanks! I will check it out. I suppose it is available on VIPM?

[rwunderl]

---

@VinnyAstro wrote:

---

---

@rwunderl  a écrit :

---

... You could also just have a PPL per module (even if it's the same source code) to avoid having multiple running modules rely on the same PPL file. If there are 7 of the same power supply, you would have 7 PPL files (built from the same source code) in the deployed folder, and you'd call each individually.

---

---

Sorry, "PPL"?

A Packed Project Library (PPL) in LabVIEW is somewhat akin to a DLL in Windows programming. It is pre-compiled code, and therefore can execute "faster" than code in a development environment. This also means that users of your code cannot change your source. You can in fact make the block diagram of code in a PPL visible, which is extremely helpful as you can probe wires *in a running executable* using this technique.

Any VIs in a project library can be built into a PPL using a Packed Project Library type of Build Specification. Generally, you'd dynamically run your module's top-level VI from the PPL. Note that PPLs are very limited as to what they can contain. As the Help states, "A packed library contains only LabVIEW files. By default, LabVIEW saves non-LabVIEW files to the same destination directory as the packed library." This can be confusing or frustrating for shared resources that are not native LabVIEW files.

The modules for the system I am talking about use shared variables to connect to the outside world. Therefore, they do not need to subscribe to any queues or events or anything. They just come online and do their job using the shared variable API to read and write variables. The system is quite modular.

You can also share code that's not a "module" with others using PPLs. Perhaps you have some awesome new array-building functionality you'd like to share with your team? Build it into a PPL and share away! Make all of the API calls Public scope, and that's all anyone will be able to access from the outside. Just an example.

Hope it helps.

[Mark_Yedinak]

---

@rwunderl wrote:

---

s, this is exactly what this system does. When you open the VI reference, you can specify that the reference is for reentrant run. You could also just have a PPL per module (even if it's the same source code) to avoid having multiple running modules rely on the same PPL file. If there are 7 of the same power supply, you would have 7 PPL files (built from the same source code) in the deployed folder, and you'd call each individually.

---

 Don't do that. That is a terrible idea. Use a single PPLs and dynamic loading with reentrancy. Making copies to support multiple modules is a very kludgy way to implement the system and not very flexible.

[rwunderl]

I would agree with you except for the R&D environment this software runs in benefits from a maximum amount of flexibility. If you call the same PPL reentrantly, you *must* use the same exact code. However, if you need to test a bug fix with one instance that may not apply to the others, you can't.

This may sound strange, but let me give you an example: there's a group of 4 high-voltage power supplies that are the same model from the same manufacturer (and thus the modules have the same source code). One of the supplies got replaced with a newer version of the exact same model. It turns out that they changed the comm spec in a subtle way in the meantime. Now I have to come up with a new way to reinitialize the supply after an arc without bringing the rest of the machine down (don't want to turn off the other 3 supplies and cause hours of downtime). So I try a bug fix by deploying only the PPL for the supply in question and reload only that module.

Now if the fix can be safely applied to all of the supplies, I can rebuild and deploy them all (each PPL is a different Build Specification). Otherwise, I would branch the fixed module out to a new module that actually is different than the others or maybe come up with a configuration setting to select which supply is being used. Meanwhile the separate PPLs mean that if the software is restarted, everything will still be in the new, partially-updated state.

I know this is an edge case, and does not excuse kludgy architectures in general. I'm only saying that the suboptimal way this system was implemented has indeed come in handy a few times.

[James_W]

You're looking to put your coms functions into a class that can be tweaked and overridden depending on the PSU they have connected to then.
(Class functions are by default shared clone re-entrant, but you can get around the number launched by changing the re-entrancy settings of the calling VIs).
I battled that sort of thing for years as PSUs were changed under me until I made an effort at understanding LVOOP.
- it's well worth the trouble for all the headache up front.
(You can then support different build specs as different classes instead of different PPLs)

[Mark_Yedinak]

---

@James_W wrote:

You're looking to put your coms functions into a class that can be tweaked and overridden depending on the PSU they have connected to then.
(Class functions are by default shared clone re-entrant, but you can get around the number launched by changing the re-entrancy settings of the calling VIs).
I battled that sort of thing for years as PSUs were changed under me until I made an effort at understanding LVOOP.
- it's well worth the trouble for all the headache up front.
(You can then support different build specs as different classes instead of different PPLs)

---

This is definitely the right approach.

[VinnyAstro]

---

@Mark_Yedinak  a écrit :

---

@rwunderl wrote:

---

s, this is exactly what this system does. When you open the VI reference, you can specify that the reference is for reentrant run. You could also just have a PPL per module (even if it's the same source code) to avoid having multiple running modules rely on the same PPL file. If there are 7 of the same power supply, you would have 7 PPL files (built from the same source code) in the deployed folder, and you'd call each individually.

---

 Don't do that. That is a terrible idea. Use a single PPLs and dynamic loading with reentrancy. Making copies to support multiple modules is a very kludgy way to implement the system and not very flexible.

---

This is actually how I understood things... I guess 😅

Having one PPL for my motor control module, 1 for the coms etc.

And then in my main I just call it multiple times using Async Call and Collect/Forget and probably store the references in an array, something like this (Snippet might not work, I've based it on the LV example "Asychronous call And Collect (Using option 0x40)"): 

Here I am calling my "Module" (which is the example VI target) 4 times as this would be the typical maximum number of motors I would control)

BUT, the thing is, after seeing their example, they open the reference once then call async multiple times and then pass that reference along... but how do one deal then with the VI, if some user interaction is required and there is only one reference? Same with the collect, how can they relate the data from the Collect to the data that has been input in the Call?

I'm a bit confused here.

@rwunderl  a écrit :
You can also share code that's not a "module" with others using PPLs. Perhaps you have some awesome new array-building functionality you'd like to share with your team? Build it into a PPL and share away! Make all of the API calls Public scope, and that's all anyone will be able to access from the outside. Just an example.

---

---

Ah yes, I actually used PPLs before 🙈 And I even have some plans for my company about this 🙂 For some reason the abbreviation didn't stick to my head...

@Mark_Yedinak  a écrit :

---

@James_W wrote:

You're looking to put your coms functions into a class that can be tweaked and overridden depending on the PSU they have connected to then.
(Class functions are by default shared clone re-entrant, but you can get around the number launched by changing the re-entrancy settings of the calling VIs).
I battled that sort of thing for years as PSUs were changed under me until I made an effort at understanding LVOOP.
- it's well worth the trouble for all the headache up front.
(You can then support different build specs as different classes instead of different PPLs)

---

This is definitely the right approach.

---

I will train on LVOOP as part of company training program normally. Worst case I'll take some time on other projects 🙂

[drjdpowell]

---

@VinnyAstro wrote:

My question is: 

Should I start these modules via the "Run asynchronously" method or by using the "Run VI" method?
I am using the NI QMH template for now (I really want to start using the DQMH one day, but I still need to learn labview OOP first...), so I don't need to "wait on async data" from these modules at any time (except maybe when closing the app) as they will communicate with each others via messages.

What would you do in term of performances and easiness of integration?

---

I would suggest you look into using one of the various frameworks, like the DQMH, rather than try and build your own design from scratch.  You have already brought up Sub Panels, Open VI ref with async calls, PPLs, and threads, each of which is reasonably complicated to understand one at a time, let alone all at once.  This is why people make frameworks: to solve these complex problems once and make them simple.

In addition to DQMH, you might look at my Messenger Library (in particular the YouTube instructional videos).

If you do want to do Async Calls, note that it is very common for people to get confused by the 0x40 "clone pool" option on "Open VI ref".  People think that is what is needed for doing multiple references to multiple clones, when really it is a special single-reference-for-multiple-clones use case.  

[VinnyAstro]

---

@drjdpowell  a écrit : I would suggest you look into using one of the various frameworks, like the DQMH, rather than try and build your own design from scratch.  You have already brought up Sub Panels, Open VI ref with async calls, PPLs, and threads, each of which is reasonably complicated to understand one at a time, let alone all at once.  This is why people make frameworks: to solve these complex problems once and make them simple.

In addition to DQMH, you might look at my Messenger Library (in particular the YouTube instructional videos).

I do want to get into DQMH at some point.

But 1. I feel that learning my way up (and understanding more basic functions) is better at first; 2. I still need to learn OOP first and I'd like to do it properly and not rush it, and for now I don't have time 🙂

---

@drjdpowell  a écrit :

If you do want to do Async Calls, note that it is very common for people to get confused by the 0x40 "clone pool" option on "Open VI ref".  People think that is what is needed for doing multiple references to multiple clones, when really it is a special single-reference-for-multiple-clones use case.  

---

Sorry, I actually don't get your explanation here, could you reformulate that?