LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Cluster as a carrier of parameters. Bad?

"Put the array in the cluster".   I thought a array/variable needed to be in a single unique control on a frontpanel to act as a memory storage. However, a cluster is also a FP control and has a "memory" and perhaps have better performance? 

 

When I have a graph showing some curves on the FP at high speed I can see that CPU load are rather high. If I hide the graph with a window the CPU goes down. It is normal. I though hidden arrays located at the FP behaved in the same way. They are hidden for the operator and therefor updates on the array don't eat much CPU. That was my belif.

I must make some tests. I like to work with cluster. It is a very nice way of keeping things together. 

0 Kudos
Message 11 of 20
(3,511 Views)

Well, now.  Using a control or indicator as data storage is a terrible idea.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 12 of 20
(3,495 Views)

Bill. Now we coming somewhere!  Please advice. How would you read in a 2D-array from a file and read/update it and now and then save it to a file (for safety)?

0 Kudos
Message 13 of 20
(3,488 Views)

@TakeANap wrote:

Bill. Now we coming somewhere!  Please advice. How would you read in a 2D-array from a file and read/update it and now and then save it to a file (for safety)?


I'd make a class with a 2D array in it's private data. Give it a From File, To File, Read and Update method. Actually, the read isn't a very strong method. I'd prefer a Update Graph method, and let the class update the graph.

 

The graph could be a class as well. I have this in my application, where I have 12 different kinds of data, and about 8 different graphs to display the data.

 

I would avoid by reference and\or global data at almost every cost. I'd probably prefer global data over by reference data. By reference is terrible to debug, as the reference closes when the top level VI stops. Global or by value data is much easier to work with.

0 Kudos
Message 14 of 20
(3,476 Views)

Thanks for that. I have now something to check during this long weekend.

I had a LV-application that was delivered from a LV-app.supplier once. THey used classes and "class" was llb:s with functions and methods. There was several classes dealing with different things like monitor, sampling, storage etc. The appl. was made in LV7.0 and the application was really a big one. I saw that they started the project in UML...

 

I think I must read a little more about classes. I read an article about it and to use OO needs much studies.  

The class you talking about, can this kind of array be implemented in a "normal" application?

 

0 Kudos
Message 15 of 20
(3,464 Views)

@TakeANap wrote:

Thanks for that. I have now something to check during this long weekend.

I had a LV-application that was delivered from a LV-app.supplier once. THey used classes and "class" was llb:s with functions and methods. There was several classes dealing with different things like monitor, sampling, storage etc. The appl. was made in LV7.0 and the application was really a big one. I saw that they started the project in UML...


That sounds decent... IIRC, LabVOOP wasn't introduced until LV8, and matured around LV12.

 

So they either used a toolkit (Endevo, IIRC) or DIYed something.

 

It's likely that they used by reference classes which is, AFAIC, not a good idea. Some really like it though.

 


@TakeANap wrote:

I think I must read a little more about classes. I read an article about it and to use OO needs much studies.  


If you have access to NIs course, I'd at least glance through it. Although it stops when things get interesting, it's is good.

 


@TakeANap wrote:

The class you talking about, can this kind of array be implemented in a "normal" application?


Absolutely.

 

In this respect it really is a glorified cluster.

The 'problems' arise once you get used to the possibilities. For this class we're only dealing with encapsulation, which can actually feel like a limitation (which it is). But there's also inheritance (for implementation, enhancement and specialization), polymorphism, containment, etc..

 

You might find the 'old stuff' frustrating once you're used to this power. Not really a problem, but the price of progress, I guess.

0 Kudos
Message 16 of 20
(3,456 Views)

I remember I wrote the spec and sent it to Endevo, Sweden. Later, they sent the two computers and a huge invoice. That was back in 2007.  The equipment still working. Last year I was there updated the system with new computers and also installed LV-2013. Still same application. 🙂

 

0 Kudos
Message 17 of 20
(3,405 Views)

@TakeANap wrote:

I remember I wrote the spec and sent it to Endevo, Sweden. Later, they sent the two computers and a huge invoice. That was back in 2007.  The equipment still working. Last year I was there updated the system with new computers and also installed LV-2013. Still same application. 🙂

 


Then it's most probably GOOP, which is now on github as it was bought by NI. Endevo split up and some of the makers of GOOP made G# that ADDQ supplies (available on VIPM). 😉

 

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 18 of 20
(3,397 Views)

@TakeANap wrote:

"Put the array in the cluster".   I thought a array/variable needed to be in a single unique control on a frontpanel to act as a memory storage. However, a cluster is also a FP control and has a "memory" and perhaps have better performance? 

 

When I have a graph showing some curves on the FP at high speed I can see that CPU load are rather high. If I hide the graph with a window the CPU goes down. It is normal. I though hidden arrays located at the FP behaved in the same way. They are hidden for the operator and therefor updates on the array don't eat much CPU. That was my belif.

I must make some tests. I like to work with cluster. It is a very nice way of keeping things together. 


Hmm, you make an interesting point. One of the reasons sub vi's are fast is that their front panel is never shown. I'd still consider it bad design though. 🙂 Data should be in shift registers (or class memories). These shift registers can be of any type including clusters.

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 19 of 20
(3,395 Views)

Yes. It was GOOP.  The lowest VI:s was password protected (I have the password. 🙂  

I liked the structure. It was clean. I was a little afraid of changing too much but I made lots of extra code around the core of the application. 

0 Kudos
Message 20 of 20
(3,379 Views)