LabVIEW
Cluster as a carrier of parameters. Bad?
@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.
Search LabVIEW like a graph!
@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.
@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). 😉
@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.
