I am adding the Pico 4000 series scope driver to our company's scope software. We previously had the 3000 scope working. After making some changes, I got the scope working for untriggered data correctly. When activating some triggers the program and scope hang.

I believe the program is waiting for the callback from the scope but never gets it. The program will not close until I unplug and plug in the USB cable.

Another thing to note is the triggering works correctly for one block sample. The crash happens when I enter in a loop where it keeps getting samples and displaying them. This same loop works fine with no triggers set.

Actually, I did make some progress since my last post. I believe the problem is with calling the ps4000Stop. According to the spec we should not call this function between samples. However, this seems to work differently with or without triggering and I am not sure why. Like I said previously, we originally had the 3000 series scope working with this code. So the code originally called the stop between each sample. Our original code had two states. One state it called the functions to setup the scope channel, triggers, etc and call runblock. The second state would check to see if data is ready, stop the run and get the values, then switch to the first state. I took out the stop state and instead of having the second state call the first, I reset my bool value for ready and called runblock and kept it on the first state for the next getvalue.

The problem is this method freezes when I have it set to not having a trigger but with the trigger it works fine. I add the stop back in and basically follow the same algorithm as the old scope and no trigger works fine but setting up the trigger hangs. I would expect the scope to work the same with or with the trigger, but that is not what I am seeing. I set up some if statements to work around the problem and it is getting messy. Messy, and still does not work right. The scope now hangs when I switch the trigger modes.

Here is some code. If you need more to get the idea of what is going on then let me know. One thing to note. GetData will be called over and over. The state will be set back to init if we change triggers or channel settings. I think this is where it is hanging the most, when it is set back to init to change all the settings. But the otherwise, the hangs appear to be random. Sometime I switch trigger modes with no problems, other times it hangs.

I have been thinking about this some more and I have a couple questions.

Between samples we are not suppose to call ps4000stop. How about if we are about to switch triggering or channel properties? Also, if we are not to call stop before doing this, then what will happen if we switch settings while it is in the middle of a block run?

If this could cause a problem, then is there any way to determine if the scope is in the middle of a run or is it up to us to keep track of that?

Actually, I think I may have just fixed it. The problem was that when an error occured I durring the Init I reran the Init block again. There was no call to Stop; however, It looks like the scope does not like resetting everything up before taking a sample. I took out the line to reset the state to Init and I have not had any hangs since. Other changes I made are: No matter what the trigger mode I do not rerun the init, and before I run the init I make sure there is no block running. I don't know if these changes make a difference, but they don't hurt.

I am going have to test this longer to make sure the issue is totally gone, since it was pretty random. However, it is looking good so far.

That is for sure. The Scope was locking right up. However, it also looks like we should not set up the channels and triggers twice without sampling between. This appears to be what my trouble was. My Init state was set to init state again before collecting data and which caused the problem.

if (nReady < 0) // Error
{
m_nState = INIT;
m_pDocument = NULL;
}

I after setting up the scope it never started a block, it just went back into setting up the scope again.

I have another question related to this issue. If a trigger is setup with a range that it never hits. Is there a way to abort if we can't call ps4000Stop between the runblock and the callback. In this case we would have started the runblock but the callback would never be called so we can't call ps4000Stop. How can we abort in this case?

If you want to abort waiting for a trigger, you should call ps4000Stop. You can then call RunBlock again. After calling ps4000Stop, the driver will call the callback function with, I believe, a status of PICO_CANCELLED.