Pause and Killswitch suggestions

[LarsUlrich]

Here is what I have got so far, I think I am on the right track.

I consolidated your suggestions into 6 states:

Initialize

Idle (pause/change amplitude)

Start Sweep

Step Frequency

Output OFF

Stop

The "start sweep" case has a similar enque element as the shown "step frequency" case, just without the case structure to see if it is at the end.

The "idle" case is activated by a pause button (in the producer loop) and uses the shift registers for the amplitude to pass in a new amplitude

The only thing I am a little unsure about right now is how I wired in the enqueue element into the "step frequency" (and the hidden "start sweep") case.  Though I haven't tested it, I am not entirely sure that the pause button will pause the sweep (it seems like it will though).

[JÞB]

You are on the right track!

A few tweaks are needed- go ahead and attach your vi as a png (or snippet) the jpeg's only show one state- snippets and attachments let us dig!

Nice work!

[LarsUlrich]

I cleaned it up a bit, and even consolidated it down even more to 4 states.  Images of the whole thing are attached.

There is also a function that I cannot remember the name of (I made a crappy image from memory in paint of what it looks like and how you wire it).  It stores the value of the control in memory and either it only sends the data forward if it is different or it sends a true value if it is different, I forget.  I would like to put it into the idle state so it is not sending the amplitude to the device over and over again.

[LarsUlrich]

Hmmm, I've started to try and run it with the device, but it doesn't go into the sweep.  I must have something wired wrong, maybe the queue elements?

[LarsUlrich]

Woops never mind.  I had the wrong gpib cable plugged into the instrument, lol.

It is working real well, the only thing I need to fix right now is the "stop" function.  It is currently stopping the program before running the "output off" state.

[RavensFan]

Don't release the queue after your producer event loop ends.  Right now you press stop, the Stop button event queues up output off, the True boolean stops your event structure loop, then the Release queue kills the queue most likely before the Output Off state runs.

Don't rely on the error on a queue to stop the consumer loop.  But a True boolean in the Output Off case to be the trigger that stops your consumer loop.  And put the Release Queue after the consumer loop.

Now the stop button up top will queue up the Output Off case then stop the producer.  The queue remains intact.  When the Output Off element of the queue runs, then it will stop the consumer loop.  Once the consumer loop stops, then the queue will be released.

[LarsUlrich]

Ok so my program is currently working fine, but as it is it is not very sophisticated or robust.  It only handles the bare minimum of what it needs to do and there are plenty of improvements that I can make to it.

First on the list:

When we actually use this program, there is a large list of sweeps that it will have to preform.  Right now the user will run a sweep, and when that sweep is done he will re-enter new information to the front panel and start it again for the next range.  However, I know all of that information ahead of time, and would like to program it to run through multiple times.

The attached image shows 1 of the 3 lists of data that will feed through and highlights the problem, it is about indexing and sending the correct data at the correct time.  If I simply enable indexing (in the spot the arrow points to in the image) then it will not send the correct data at the correct time.  It will cycle through the "start frequencies" every time that bottom loop iterates, which is way too often.

The obvious solution (that I see) is to make a comically large for loop around the entire thing, and index the arrays through it.  That way the "stop" button wouldn't so much as stop the whole thing but just move on to the next set.  However, this would mean the only way to stop the program would be to run all the way through or to break it, which is probably not the best solution.

[LarsUlrich]

My bad, forgot the attachment.

[LarsUlrich]

The other way I might be able to do this is by putting all of the data in the producer loop and linking an event to a button press.  Then I would only have to find a way to, at the push of a button, take the next set of starting points in the series and pass it through to the consumer loop.

[RavensFan]

What you do is create a shift register that keeps track of what step you are on.  When you want a step, you use the index from the shift register to pick out that element of the array.

When you want to take the next set of frequencies, increment the value going into the shift register by one.