Change Analog Outputs Dynamically

[tbob]

I'm glad to hear that you are making such an effort.  There is a way to do it.  If you absolutely need three loops, use the queue with a command to stop the third loop rather than let it run continuously.  Also, in your bottom loop, you stop on error.  Although this works and is acceptable, I prefer to stop the loop with a command obtained from the queue.  In the Stop event, write a Quit command to the queue.  In your other loops, stop the loop when the quit command is received.  This is just my preference.  Its not right or wrong to do it either way.

[BlissDismissed]

Hi, and sorry for the long delay. I have had to work on some other projects, and also had some of the requirements for the program changed on me.

I've consolidated my events to one structure, and have my two loops one acquiring/sending out daq info, and the other processing and feedback control.

The altered the program now acquires data from two channels of an accelerometer and not the 2-LVTD sensors. However in doing so I've run into a few issues. 

1. If the program stops via the stop button, the daq read doesn't respond properly on the next run. I thought I had taken care of the issue by eliminating the redundant event structures. That removed the original problem which occurred in the waveform start. The waveform start button works great now, but the other start does not. I know it was mentioned to just have one start and one stop, but I want to be able to control when a waveform outputs.

3. Calibrate event doesn't get called

 If program stops with stop button, the daq read doesn't respond properly on the next run3. calibrate event doesn't get called

2. My calibration event doesn't get called. I looked and it with the highlight execution but I'm not sure where its hanging up. It was working before and I don't think I made any alterations to it.

3. I created a stop state to finish instead of stopping on an error like before. But, I feel that it still always has an error when it finishes. Maybe thats whats causing the problems in subsequent runs?

In case it helps my goal for the program is:

1. Send a signal to bottom plate to have a certain oscillating amplitude

2. Read acceleration data

3. Actively change top plate movement as quickly and possible to keep acceleration peeks within a certain tolerance

Thanks again for any help someone can offer. I've attached the updated vi.

-Arthur J. 

[tbob]

In your top loop, why do you have an inner loop around the event structure?  You inner loop keeps running until the stop is pressed.  Then the outer loop finishes.  I would eliminate the inner loop.  Maybe I'm missing it, but I don't see where you are enqueing the state enum in the top loop.  The bottom loop will never be able to dequeue if nothing is enqueued.  Instead of sending the enum to a shift register, you need to enqueue it for use in the bottom loop.

So get rid o f the inner loop and put an enqueue after the event structure.  Pass the enum output of the event to the enqueue.

[BlissDismissed]

Hey I was just having one additional issue that maybe someone could shed some light on. 

I'm not sure why, but when I run the program all the buttons function properly, and I click stop, and the vi finishes. Now if I go to run it again, the start for my data acquisition doesn't work. When I ran it in highlight execution the error for data being overwritten comes up from the daqmx read of the taskout event. But, I think that is only happening since it runs much slower in highlight execution.

Is it something with how I'm clearing the task of the daqmx, or a conflicting command? I've looked at it quite a bit, but found myself stumped.

Thanks for any help,

Arthur J. 

[BlissDismissed]

Oh, and sorry. To answer your previous question about the internal loop around the event structure. The reason I thought about doing that was because not all the events require new waveforms. I thought it would be a waste of time/memory to re-run the 4 waveform generations for every event that is triggered. Instead I have the inner while loop stopped from an event that requires a new waveform to be generated.

Does that make sense? I'm open to any other methods to perform that though,  

Thanks,

Arthur J.

[tbob]

Your architecture seems a bit funny.  If you press the start button, the start state does not get queued until the Every N Samples event fires.  Same for the calibrate button.  Is this what you intended?

You have many Value property nodes.  Property nodes are notoriously slower than local variables.  It seems as if you intend to change some control values while the program is running.  You would be better off using local variables instead.  If you don't intend to change the control values, use wires instead.

Your block diagram is huge.  You could simplify it by creating subvi's.  Make your code more modular by taking individual tasks, like the code inside State 1, and making it into a subvi.  This would result in a much smaller block diagram that can easily fit on one screen.  This would make it easier to read.  Your DAQmx code at various places could be made into a subvi.  Also your waveform generation code in the producer loop.  Modular code is easier to read, easier to maintain, and easier to troubleshoot.

[BlissDismissed]

For the start button I thought that would be necessary. But, I guess for the calibration I'm not sure.

I thought that since the state1 is doing calculations on the data coming from the daq read, if you called that state from the start button, it wouldn't have anything in the queue to work with until the task out trigger occured. But that may be just me not having a good understanding of the process flow labview has and not thinking about it correctly.  

Thank you for pointing that out. I looked at it again and there were several places I could just shift register the counts and I dont think I even need a local variable for it 

I started to make it a little more modular and created a few subvi's. It does clean it up a bit. 

Thanks,

Arthur J.