Leaderboard

At best, the Events are a bit like an occurrence, not a replacement for polling, just a good hint at what might be a good time to poll. The problem as AQ hints at, is that it can be tricky to catch all of the ways that a user can change the scale range. For example, what if I paste a new value, and then make another window active and then return to the FP. The new value is entered via this process without a key press or mouse click. Polling is a robust method to catch these changes. And since I started using LV long before the days of the Event Structure I will pass along a tip from the old days: a simple way to throttle the polling loop is to use the "Wait for Front Panel Activity" function with a long timeout (500 msec). Keeps it responsive when necessary, and out of your way when nothing is happening. In many instances I do not display the Marker values for a slider, and I actually use separate controls to set the range. This makes it very easy to detect the value change.

I assume that you are using LV2010. (From your profile) We just recently upgraded to LV2011, and it a lot more stable. We had a lot of problems where LV would become very flaky when editing classes. (particularly if you tried to click faster then LV could finish loading screens, or had a lot of windows open. I never tried too hard to isolate the problems) Of course, there may be limitations, but if it is possible, I recommend upgrading.

Much more difficult than using a pic as a serial pass-through to just chop the break Not to mention <$10

I'm not quite sure what you mean by "where to keep the class wires." Are you using the instruments in the tests and simulation at the same time? There's nothing particularly difficult with writing auto reconnect code, though it isn't something I'd put directly in the instrument class. Just give the class a way to report the connection has been dropped and let the calling vis be responsible for monitoring the connection and reestablishing it when you want. There are two basic ways you can handle connection monitoring: Inline or as a parallel process. Inline--meaning the connection is checked as part of retrieving a data point--is easier to implement, but if a connection is dropped you won't know it until you try to get a data point. Doing the reconnect operations directly in your data processing loops may cause unacceptable delays depending on the project specifics. Parallel process connection monitoring is just a separate loop dedicated to the instrument that periodically checks to see if the connection is still valid even if you're not actively collecting data. When it discovers the connection has been dropped it will attempt to reestablish it. That way the reconnection process doesn't cause your data processing loop to hang. You might be able to use a by-ref class if the instrument's device driver supports it. Personally I prefer to stick with by-val classes and just route all data exchanges with the instrument through that loop.