Two points. To George; fine for low throughput, but don't expect to update XY graphs by reference.
To J Adam Crain; This sounds suspiciously like you want VIs buried deeply in the heirarchy to respond to events on the front panel without any direct linkage. Interesting tricks like this make it an absolute pig for someone else to go in the code and fix any future problems, since you can no longer trace the bits of code that may respond to front panel input. I have a project from perhaps a year ago where, as an experiment, I abstracted all the little indicators to sub VIs, accessing via arrays of references embedded in the big cluster I usually pass round and round as my equivalent of a global. Aside from the XY graph updating far too slowly this way and having to be done conventionally, it works pretty well and it lets me do things like updating a batch of indicators inside a for loop from an array of values, even though the indicators themselves aren't arrays. However, going back to it to refresh my memory before typing this mail was not easy. It's not clear where displays are being updated from and you have to dig into the code. Loading the arrays of different classes of indicator into globals may work better if you can search for them, but it may be no better than the cluster in that you can search for references to the global object but not to references to individual elements within that object. One thing I should have done- I've arranged all my unused terminal nodes prettily off to one side with a comment that they're all controlled via references. Grouping them together with comments as to which sub VIs they're being controlled by would have been rather useful. J Adam Crain wrote: > George, > > I use this technique frequently for large control systems where > multiple threads update their corresponding front panel data. I have > even toyed with > the idea of allowing the threads to detect their own events (instead > of the launching thread detecting and messaging) with the dynamic > events introduced in 7.0. I've tried to show some colleagues the > merit of such a design but have been met with some resistance, so it > would be interesting to see what others think. I'm not sure that I > understand what race conditions you are refering to. my threads just > use the globally stored control references to update status > information. > > J Adam Crain > Goodman Lab > UNC-CH Dept Physics and Astronomy > > >> Subject: Good Programming Practice? >> From: "George Gatling (Contractor)" <[EMAIL PROTECTED]> >> Date: Thu, 19 Feb 2004 14:40:54 -0500 >> >> I have explored several ways to modify front panel data in labview, >> and >> many of them seem to complicated or too flat (huge toplevel >> diagrams). Now >> I am toying with a new idea... On the top level vi I load >> references to >> all of the indicators and controls into a global and then read/write >> to >> them via their reference lower down in the hierarchy. If there are >> possible race conditions I build a wrapper vi to protect >> read/modify/write >> cycles (one per front panel object). I realize all of this is >> running in >> the UI thread because I am using refnums, but it would be anyway >> because >> all of this is about the front panel. Now... what are the downsides? >> >> >> George Gatling >> Applied Technology Division, SFA Inc. >> Space Physics Simulation Chamber >> US Naval Research Laboratory >> 202-404-5405 (phone) >> 202-767-3553 (fax) >> >> If trees could scream, would we be so cavalier about cutting them >> down? >> We might, if they screamed all the time, for no good reason. --Jack >> Handy -- Dr. Craig Graham, Software Engineer Advanced Analysis and Integration Limited, UK. http://www.aail.co.uk/
