LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is your tolerance for placing things into clusters?


@Hooovahh wrote:
I have many clusters.  Generally each Actor has a BFC cluster that grows as the temporary data that that Actor needs grows.  That Actors cluster isn't shared with anyone it wouldn't make sense to.  It contains some private things, some temporary things, and maybe some things that can be shared.  When I want that data to be available I can share it through global means to the rest of the application, or send it privatly through a message.

 

Why would I want all of this data available everywhere?  I only share what that Actor should share.  If I have a cluster with a file reference in it, it would be crazy to share that with the rest of the application so I don't.  There doesn't need to be explicit rules saying what should be private, instead there are ways to share only what should be public.  Only my File I/O Actor will have that reference and there is no need to put that into a class because only that Actor has that data, and that Actor can do whatever it wants with that data.  Also very flexable, very clean code, easy to read, and minimal wires.  🙂  As a result the project contains less files too.


You bring good points...  First...  I should mention that the "Superclass" contains the inheritance.  It's not some giant cluster with everything.  It's actually a cluster of classes.  Maybe not the proper approach...  Maybe it's a God Object..  Maybe I need a refresher course for the Advanced Architect or whatever it is called nowdays..    In short, the data is available everywhere because the hooks for it is available.  The downside...  it's tighlty coupled.  That I don't like...

As a matter of fact, I aam having this very conversation with a customer..    So I like the sharing of ideas within this thread.  In some situations, LVOOP is the way to go... In others, it is not.  I do not know what is the defining line between the two..  And it's almost like the search for the Holy Grail...  What is the fine line between the two.  For my customer, I think the way they are headed, they may as well stay away from LVOOP as there might not be any worthwhile benefit.  I don't know yet...  I have not seen the particular implementation...

 

Nonetheless... if planned properly, you do not need such a Superclass..  The reason for going that route was because the customer was not able to define any proper requirements, so scaling was to be expected and scaling in multiple directions.  I had done a similar large project in the past where the objects were decoupled from the GUI, the wrapper and the test engine. I discovered there was a lot of duplication.  It wasn't intentional, it is just the way it morphed itself.  I should mention that these projects have between 3 to 5 deveopers working on them.  Not always at the same time..  The final coding solution may stray away from the original intent, especially when non-LVOOP programmers enter the arena. 

 

 

 

Message 21 of 26
(1,047 Views)

@Ray.R wrote:

LOL!  You guys are funny. 

 

I never thought of that... The loading is a little slow.  Mostly because of the PC.  On a good machine, I don't see much delay in loading the project.  The execution is smooth...


Joking aside, what times are we talking about? In my 4k project it's about a minute, even the compiled .exe takes lots of time. Way to much for a 30 meg file in my mind, i wonder what is the cause and what's happening "under the hood".

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 22 of 26
(1,021 Views)

@Yamaeda wrote:

@Ray.R wrote:

LOL!  You guys are funny. 

 

I never thought of that... The loading is a little slow.  Mostly because of the PC.  On a good machine, I don't see much delay in loading the project.  The execution is smooth...


Joking aside, what times are we talking about? In my 4k project it's about a minute, even the compiled .exe takes lots of time. Way to much for a 30 meg file in my mind, i wonder what is the cause and what's happening "under the hood".

/Y


This is what splash screens are for.  Also, You can often "Smart Load" with some dynamic loading tricks that a forum search will reveal.Smiley Wink 


"Should be" isn't "Is" -Jay
0 Kudos
Message 23 of 26
(1,016 Views)

@JÞB wrote:

This is what splash screens are for.  Also, You can often "Smart Load" with some dynamic loading tricks that a forum search will reveal.Smiley Wink 


Yup, this is what I do.  Dynamically load each Actor into memory with a progress bar showing which actor is being loaded.  This simply opens VI references to the core which also loads all dependencies needed.  Here I added a cancel button too so the starf the application can stop.  Then once all actors are loaded load the top level Main VI and run it.  Way too many complaints from users that it doesn't come up when you double click the shortcut.  They were happy once they have some way of seeing feedback.

0 Kudos
Message 24 of 26
(1,004 Views)

Yes, those techniques alliviate the pain, but doesn't really change the facts. 🙂

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 25 of 26
(988 Views)

 

What takes the longest time is for LabVIEW to load.  The project itself may take a minute, but I never timed it. 

The PC I have is a slow laptop.  Everyone has a laptop.  Don't ask...

 

 

0 Kudos
Message 26 of 26
(969 Views)