RT Global Variables and Loop Speed

[IanDeaville(ZF)]

Ben,

Yes, the wrapper VI construct around a more generic AE is a good idea. 

I made a small test VI, with large double arrays being passed either directly through a shift register, or from a separate wire.  The direct method was marginally quicker, but I suspect that for my app that is not significant. 

Thanks for all the help.  I have nearly finished converting all the ordinary globals & network shared vars into shiny new FGV's.  I hope it's quicker...

Ian

[Ben]

---

@IanDeaville(TRW) wrote:

Ben,

Yes, the wrapper VI construct around a more generic AE is a good idea. 

I made a small test VI, with large double arrays being passed either directly through a shift register, or from a separate wire.  The direct method was marginally quicker, but I suspect that for my app that is not significant. 

Thanks for all the help.  I have nearly finished converting all the ordinary globals & network shared vars into shiny new FGV's.  I hope it's quicker...

Ian

---

Oh baby!

You just earned mega-Kudos in my book for that post.

Just make sure your read-mod-write operations are encapsulated into singe operations. If you have trouble post images so we can advise.

Thank you!

Ben

[IanDeaville(ZF)]

Ben,

When I say "nearly finished implementing", I really mean n""nearly finished creating all the new FGV's, now to edit loads of sub-VI's"

Here are a couple of examples, in the attached zip to reduce screen wastage:

BNC & Acc Inputs.  The machine has some BNC & accelermoeter signals.  These are not used much, so I grouped them together.

Writing will need to be quick, so the data is dumped in as arrays.  The Action can be "Write All", "Write BNC" or "Write Acc", as well as "Read", allowing some flexibility. 

DigOut.  Digital outputs - you guessed.  These could be written to randomly by different parts of different VI's, but all will be sent together to the hardware.  Also some will be read by name by other bits of other VI's, so I maintain a cluster and an array of the data.  I added a second ring element (ring, not Enum as I will explain) to select the name of the individual element to change.  The names I made the same as the order of items in the array and cluster.  The default value of the Element name ring is "Unselected" = -1.  (negative values are not available in Enum, this is why I selected a Ring, and set the first item to -1)  This is caught by the inner case, which mimics the Read case in doing nothing. 

Let me know if I've done anything obviously wrong.  I did look into datatypes for some of the definitions, but my head is already hurting, and there's only so much re-architecting I can do on the fly...

Thanks,

Ian

[IanDeaville(ZF)]

Well, the main VI is now significantly faster, with both timed loops operating well within their alloted time.  Processor load is much reduced. 

However the test operating VI's are still slow.  Even in their initial waiting state (before hitting the Start button, while just waiting) it is taking too long to process.  I made all sub-VI's into subroutines, and the only other stuff going on is some local variable & property node reads.  Are these causing slow-down of my RT timed loops? 

I seem to have fixed communication between VI's, but passing values between loops of a single VI, and between UI and loop, seem to still be slow.  Should I use more FGV VI's for this, or is there an internal method?  I'll try more FGV's an see what happens.

Secondly I am not sure about re-entry & cloning options.  Allowing reentrant operation should prevent one VI from blocking another.  Which is the best clone option to select to ensure that the same data is shared between all calling VI's?

Thanks,

Ian

[IanDeaville(ZF)]

Well, with another FGV to manage data between the lop & UI within a test VI, all is very fast now.  And I can absolutely confirm that FGV's should NOT use re-entrant mode.  The data written in one place is not read in another.  Re-entrant mode is probaly Ok for a pure processing VI where nothing is stored internally, but not FGV's.