controlling the sec/div as in a osilloscope

[DFGray]

Your code is functioning as expected.  Your sec/div control is read and executed once, at the beginning of the code execution. It needs to be in a loop.

To do what you would like to do will require another level of design.  You currently have a data acquisition loop.  You will also need a user interface (UI) loop and a way to communicate from the UI loop to the acquisition loop.  You will also need the change the data acquisition loop from a simple loop to a state machine so you can handle on-the-fly configuration changes.  Consider what happens when the sec/div value is changed:

1. The horizontal range on the graph changes
2. The data acquistion parameters change to accommodate the new horizontal range
3. The data acquisition runs again
4. The data acquisition displays to the graph

In LabVIEW, this is accomplished by have a UI loop to handle UI initiated changes, and a data acquisition loop to handle the acquisition.  The UI loop contains an event structure.  When the sec/div control changes value, the event structure fires and runs code to change the graph range.  It also sends a message to the data acquisition loop to change the acquistion parameters and then resume taking data (hence the need for a state machine).

An example of this type of programming using the sound card can be found here.  This example is more complex than you need, but look at the earlier versions of the code for examples of UI loop and acquisition loop interacting.

You can place your sec/div inside your data acquisition loop and run its code at every data acquisition.  But this will probably result in performance issues.  Using two loops separates the performance of the UI from the performance of the data acquisition.

Check out producer/consumer loops in the LabVIEW help, then dive into the example linked to above.  Let us know when you have further questions.

[laskar01]

Hi DFGray and all listeners.

I've looked up producer and consumer design patterns, and I would like to know if I should use a statemachine or a queuing system and if so how many states or queues do I need?

Attached is a specification for a Bodeplotter that I've come up with.

Please read it and come up with a suggestion to me. Remember that I am a beginner. The most "advanced" thing that I've done is posted prevoious in this thread.

Kindest regards,

Lasse

[DFGray]

Were I designing this, I would use a synchronous, event driven task handler for UI things and a queue driven state machine / task handler for the data acquisition.  Both use queues (different queues) for providing messages/states.

An example of both of these are given in my Xylophone project, although it has a third, display loop, as well.  The use of LabVIEW classes is not necessary to make this work.

The key for the data acquistion is that it must handle both states (could be simply on/off, as in the Xylophone Tuner example) and commands, since the action will be different depending on the state.  For example, changing the output level of your signal will change the generation values while generating, but probably do nothing but set a new level value if you are not generating.  You can choose to implement these state differences in the UI or the data acquisition loop.  I have done both and both work equally well.  The Xylophone example does this in the acquisition loop.