From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
What architecture and good practice should I use for a massive application.
wiebe@CARYA wrote:
@Yamaeda wrote:Only controls and indicators that's a part of the UI should exist, all other data should be kept in shift register. Usually 1 (big-ish) cluster.
Hmm. I sometimes use a hidden control to receive a value signaling event from a dynamically started VI.
But I admit, only because it's convenient, not because it's pretty 🙂.
Oh, yes, i've done that many times, but the correct way to do it would be a user event, right? So this is a case of "Do as i say, not as i do." 🙂
@Yamaeda wrote:
wiebe@CARYA wrote:
@Yamaeda wrote:Only controls and indicators that's a part of the UI should exist, all other data should be kept in shift register. Usually 1 (big-ish) cluster.
Hmm. I sometimes use a hidden control to receive a value signaling event from a dynamically started VI.
But I admit, only because it's convenient, not because it's pretty 🙂.
Oh, yes, i've done that many times, but the correct way to do it would be a user event, right? So this is a case of "Do as i say, not as i do." 🙂
In this situation, I prefer the simplest solution. Adding yet another user event, it feels more 'proper' but I'm not sure if it's better. I also created a few "callback value signaling events" to controls that where not hidden. If you have a few of those, applying it to a hidden control seems more consistent then using something completely different.
At first I thought it was too pragmatic; me being lazy, get to pay for it later. I haven't found a lot of downsides yet. Use in moderation, I guess.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
In this situation, I prefer the simplest solution. Adding yet another user event, it feels more 'proper' but I'm not sure if it's better. I also created a few "callback value signaling events" to controls that where not hidden. If you have a few of those, applying it to a hidden control seems more consistent then using something completely different.
At first I thought it was too pragmatic; me being lazy, get to pay for it later. I haven't found a lot of downsides yet. Use in moderation, I guess.
A part of knowing the rules is to know when to break the rules. 😉
Using Value(signaling) ofc requires a switch to the UI thread so it's 'slow', but as you say, use it in moderation.
@VinnyAstro wrote:
Thanks a lot for your prompt answers, I was not expecting such reactivity 🙂
We're all very opiniated 😊.
Be informed, then take an educated decision. This seems to be what you're doing 👍.
@VinnyAstro wrote:
@Wiebe@Carya wrote:
If you google, use master\slave. It's the used term, not slave\master.[...] Action engines and any architecture are more or less complementary. AE are a way to share data and functionality across the application, and can be used in any architecture.
Actually, yes I know it's not slave/master, but for some reasons, my brain always switch it over 🙄
Cool, I'll then have a deeper look at AEs 🙂
Every LabVIEW programmer needs to learn about AE and how they work.
An action engine can be used to perform actions on an object. OO does exactly that, but by wire.
An AE with an Init, Set and Get function translates perfectly to a class with an Init method, a Set method and a Get method. (Bad example; to much Get\Set methods are usually a sign of weak design.)
There are a few differences:
+ The AE is global, the class is by wire.
+ The AE is more complex (3 functions in one VI), the class is more VIs but simpler.
+ The class can be inherited. The child can change, implement or extend the parent.
A global is never needed, but sometimes convenient. Rarely even appropriate.
I prefer to program by wire. Sometimes the wire is by reference, not by value. But I usually get things working with everything by value and by wire. Of course a class containing control references are by wire\by reference by their nature.
@VinnyAstro wrote:
wiebe@CARYA wrote:
@VinnyAstro wrote:
Thanks a lot for your prompt answers, I was not expecting such reactivity 🙂
We're all very opiniated 😊.
Be informed, then take an educated decision. This seems to be what you're doing 👍.
Indeed haha, but that gives more ideas and possibilities 🙂
I'm trying to build up experience yup. FYI I'm around the CLAD certification, which I miss by 1 point a few years ago at uni (damn file size calculation 🙄) But my objective is to pass the CLD by the end of the year if that's not too ambitious.
You can skip CLAD, it's not required for CLD anymore.
I don't think CLAD knowledge is particularly useful for CLD, and it would save a few bucks.
@VinnyAstro wrote:
wiebe@CARYA wrote:
Every LabVIEW programmer needs to learn about AE and how they work.
An action engine can be used to perform actions on an object. OO does exactly that, but by wire.
An AE with an Init, Set and Get function translates perfectly to a class with an Init method, a Set method and a Get method. (Bad example; to much Get\Set methods are usually a sign of weak design.)
There are a few differences:
+ The AE is global, the class is by wire.
+ The AE is more complex (3 functions in one VI), the class is more VIs but simpler.
+ The class can be inherited. The child can change, implement or extend the parent.
A global is never needed, but sometimes convenient. Rarely even required.
I prefer to program by wire. Sometimes the wire is by reference, not by value. But I usually get things working with everything by value and by wire. Of course a class containing control references are by wire\by reference by their nature.
I also usually prefer wiring stuff because I've hammered to not use global variables and as less as possible local ones. But I have to admit that sometimes it's easier and solves a bit my OCD ^^
I never worked with OO in LV yet (tbh I didn't even know it was possible until a few days ago .....) so that learning will come for later this year 🙂
If you're just started learning LabVIEW, don't be scared by OO in LabVIEW. Especially if you already have OO knowledge.
+ Everyone using OO voluntarily is doing this because it's easier.
+ It's people not using it that think it's more difficult.
It's different, that for sure. Once you're in the proper OO mindset, you gain so much power, you feel crippled when you need to go back.
You used to see the same with C\C++. Teach C, then step up to C++. That's hard. Learning C++ from the start is not more difficult, it's just different. OO is not an addition to a language, it's a major difference in how you analyze, design and program your solutions.
@VinnyAstro wrote:
I've programmed a bit in C++ (and matlab, I'm in the "that's a language too" team 😛 ) so I have some experience in OO already.
Don't we all know that feeling all too well, telling people that G is a real language. 🙂
/Y
