09-26-2018 01:49 PM
@RTSLVUI always wondered about that. Does it matter and why?
One of Knights or RolfK are better suited to answer that. It may be due to how the OS handles UI events, that is, there is only 1 UI thread that the structures have share, just guessing here. I just remember reading it here multiple times that multiple events structures are no good, unless you are really careful, and really good.
Could that explain why my tab control is sometimes one click behind the radio buttons?
Did not see any Tab control in your VI.
What if you need the value of that control in more than one event case? Should I use locals or place the terminal outside the structure and wire it in?
Use a shift register and a clustersaurous to pass values around your while loop, so every event has the most updated value. In your event for Value Change, change the value in your cluster, that way when another event needs that value it has it. (The JKI State machine does this)
mcduff
09-26-2018 02:43 PM - edited 09-26-2018 02:56 PM
Oh yeah the Oscilloscope is part of a larger program. I just culled out the Oscilloscope parts to post them, so the Tab Control and Radio Buttons were left behind...
This is my first application using Event Structures for more than a safe shutdown on a panel close event. As I have said before quite frankly I never really understood how to use them, and barely do now.
In the examples I looked at the Event Structure in my mind broke the data flow paradigm as to me it looks like just a bunch of code fragments instead of a cohesive program that I could look at and follow without running, and in many ways they still do.
My application has multiple loops that run independently all but one with Event Structures in them.
09-26-2018 02:53 PM
Ok mc duff and all. Yes. It matters where you stuff the boolean terminal. Sometimes you want a latching Action
Of course latchers unlatch when you read them.... so its really convenient to have the terminal somewhere in a section of code that will execute when the control latches... like the event case that handles the controls value change event. Now stop blushing.
09-26-2018 03:12 PM
Now let's look at your sig line again.. .
Time /division is fairly meaningless with NI Scope. There is no display to have divisions of
Sample rate is the digitizers acquisition rate. Putting a soft front panel on the thing assumes you want time ascending on an x axis of a chart or graph with 50 minor divisions... Not an assumption that always makes sense. So, the driver correctly leaves those implementation details to the developer.
2% of full scale is the accuracy of a normal human eyeball. =+/- 1minor division And the reason scopes with displays are usually 8bit adcs. NI Scope removed the inherent inaccuracies caused by human users.
09-27-2018 09:18 AM
@JÞB wrote:
Time /division is fairly meaningless with NI Scope. There is no display to have divisions of
Sample rate is the digitizers acquisition rate. Putting a soft front panel on the thing assumes you want time ascending on an x axis of a chart or graph with 50 minor divisions... Not an assumption that always makes sense. So, the driver correctly leaves those implementation details to the developer.
I get what you are saying and I would accept that IF this device was marketed as as USB Digitizer or USB-DAQ, not a USB Oscilloscope.
Every single Oscilloscope I have ever used had a control for Time/Div
I have a USB oscilloscope from a much cheaper manufacturer than National Instruments and in the LabVIEW vis that came with it have a Time/Div input on the Horizontal vi.
09-27-2018 10:12 AM
The product includes a soft front panel emulating a traditional o scope. But the gizmos should be marketed clearly as 2 components a digitizer and a software product. Neither is useful alone (unless you want a simulation then NI Scope is fine without hardware)