FGV design & shift register execution speed

[SectorEffector]

Hallo 

I'm looking for feedback about this design for a Functional Global Variable using the variant data typ and different Typdef Clusters to write and read data.

Please take a look at code below and the attached VI.

I'm looking for 1 place to store and call all the variables for an "large" application.

The example shows only 2 different typdefs, but I would want to use up to 15 of different shapes and sizes.

I also would like to store and call an 1000x1000 DBL 2D-Array with this FGV.

I'm aware that if this FGV gets called a lot from all over the programm, execution speed of the programm could drop due to sequential execution.

I have 2 questions:

1. How fast is this? I have no reference about if 15 typdef clusters and a 1000x1000 array is a walk in the park or heavy tasking for a FGV.

This is because I do not know how LabVIEW handels shift-registers in the background. Does it update every register every iteration, or only if the data changed?

I hope I can communicate what my problem is here, maybe you guys have an example of an really large FGV data cluster. 

2. Overall is this good programming practise? What are your thoughts, comments or recommendations? I'm thankfull for every feedback.

Thank you and kudos will be given! 

[mikeporter]

What you show would work, but I would personally have some concerns about scalability. Given the quantity of data that you will be storing, a better solution might be to use a data value reference to store the data. But be aware that one issue you will have with this approach is that a DVR can't be named so you have to come up with a way of getting the reference everywhere that it needs to go to.

Next, using a DVR will make storage more efficient, but won't really address the fundamental problem of sequential access to the same data, or to put it another way: Do you really want to have 15 pieces of unrelated data in the same data store? The answer should be: probably not.

Better to have each typedef in its own FGV, DVR or whatever. That way the locations in the code that only need typedef 1 aren't waiting in line behind all the places that need typedefs 2 - 15.

One final thought, the choice between FGV and DVR isn't necessarily an either/or proposition. Store the data in a DVR to take advantage of its efficiency, but use a FGV to hold the reference to the DVR and make it available throughout your program.

Mike...

[TiTou]

I would first ask if it makes sens to put all 15 clusters in one FGV, what's in those clusters? Parameters that you need to access throughout the applications? at what rate each cluster can have iis value modified when the app runs? Maybe you could split the FGV into 3,4,5 or even 15 FGVs, I mean It think it's only good to put together things of the same sort, this will avoid slowing everything down if only one FGV is called often during your process.

I haven't benchmarked the "to variant" and "variant to data" primitives but I would avoid them if possible, and the suggestion above can help you get ride of them.

Hope this helps

[Yamaeda]

1. It's fast enough. 🙂

2. Why convert to clusters? Why not an array of variants that'll store everything and convert stuff back outside.

Then you could use a simple Enum for method (get, set, init) and a list/enum/number for which element you wish to store.

So it you have an Enum of Typedef1 .. 9 the enum will also be the index of the variant stored.

/Y

[crossrulz]

If all you are doing is a Read and Write, then you might as well use an actual global variable.  I see nothing in there that contains critical sections of code where you need to protect the data.

If you want to keep what you currently have, look into using Variant Attributes.  You can keep a variant in the shift registers and add/read to/from the variable using a string lookup.

[SectorEffector]

Hello,

Thank you for your replies! 

I changed the code with your feedback. 

The converting to and from the varient type was unnecessary, so I removed it. 

Using an array for the varients is a great idea and makes the code cleaner.

I still want to use the FGV for scalability purposes.

I'm still looking for the best way to store and access the 1000x1000 DBL 2D-Array.

Please give me feedback and again thank you for all your replies!

[TiTou]

Scalable, ok.

Maintainable & debuggable,well... as long as you don't need an easy way to have a look at the data in your clusters for debugging purpose then it's fine.

Maybe you want to have a look at the Variant probe 

[johnsold]

You have not described the overall architecture of your main program.  That might have an impact on the way to handle you mega-element array.

If the array is only accessed from one loop, use a shift register. If the data must be accessible from parallel loops, then the FGV or DVR may be better choices.

Lynn

[Yamaeda]

---

@Heinen wrote:

The converting to and from the varient type was unnecessary, so I removed it. 

Using an array for the varients is a great idea and makes the code cleaner.

I still want to use the FGV for scalability purposes.

I'm still looking for the best way to store and access the 1000x1000 DBL 2D-Array.

Please give me feedback and again thank you for all your replies!

---

Technically you can store a 2D array as a variant, but i'm not sure how it will affect performance. Why not simply make a 2D-array FGV?

/Y