How do I start the 4070 recording in LV, then continue other functions?

[lockheed_eng]

Hello,

I am trying to start recording a signal with the 4070's digitizer, then I need to go change my electronic loads.  I am using LV 7.1 and I can't figure out how to get the 4070 to continue recording while I tell the loads to perform a function.  The 4070 finishes recording before it moves on to the next frame in LV where I tell the loads to change.

[Dennis_Knutson]

Since you mention frames, I'm assuming that you are using a sequence structure. The very nature of a sequence structure requires all of the code in one frame to start and finish before the next frame in the sequence can start. If you want code to execute in parallel, don't use a sequence. There's few occassions where a sequence structure is required at all anyway. You can use parallel while loops - one for the 4070 and one for the loads. You can set a notifier in the first loop to synchronize the second loop.

[lockheed_eng]

That seems so simple it's embarrassing!  I'll try that, thanks!

[lockheed_eng]

Ok, I understand, but how do I assure that the DMM STARTS before the load command starts if they're all in the same 'frame' or open diagram?  If I wire the 'error out' and 'error in' types, won't that be the same affect as if I were using frames and cause the DMM to finish before it moves to the next VI?

[Dennis_Knutson]

Here's a simple example with an occurrence instead of a notifier. The top loop will set the occurence at the same time that the DMM VI is started. The bottom loop will not run the VISA write until the occurrence is set. You can also add a small delay before the VISA Write if necessary.

[lockheed_eng]

Thanks so much for your help.  I have implemented the loops as you described, but I still cannot get them to operate correctly.  The 2nd loop starts when it is supposed to, but the LOADS VI doesn't finish implementing until the DMM stops acquiring the full length of the signal, so it doesn't ever capture the change in the load.  It's like the processor devotes full attention to the DMM acquisition and won't allow the (GPIB) loads to execute it's command until it's finished with the DMM.

[Dennis_Knutson]

It would help if I could see the VI you've written. Are you running the DMM in a loop to capture a series of points or are you doing a single acquisition? Is there a trigger option for the DMM you can use to have it wait until you detect a change in voltage?

[lockheed_eng]

The entire VI sub-structure is pretty complicated for me to include it in the forum or even an email.  It has a lot of overhead for driver error checking and handling and handshaking.  The first jpg I've included here is of the DMM function when it gets down past all the overhead.  If you imagine the first jpg inserted into the VI labeled "digitizer shell" of the second jpg, then you can figure out what it's doing.  The 'loads shell' is nothing more than a GPIB Write command with handshaking and error checking overhead. 

Basically, I've got the DMM set up for waveform acquisition, which may be the entire problem.

I have not yet used a trigger for the DMM - that was what I was anticipating my next step would be to try.

[lockheed_eng]

Oh - I just realized that the jpgs show you that I wired the occurrence for the Loads to start first, which was not what I had asked about before, I had done it the way you said originally, but when it didn't work, I tried moving the occurrence in order to try to get the DMM to acquire after I started changing the loads so that maybe the loads would finish before the DMM did. 

[Dennis_Knutson]

The sequence hides a lot of code and I'm not able to view the jpg files with a lot of success. If you are setting the DMM for a single reading, then there's a good chance it's acquiring a signal before the load can change. You might want to put it in a loop for x amount of time to give the load time to change after it's commanded to do so.