The C code uses API calls that are different from the ones in the original LabVIEW example. Do you have a LabVIEW example of Rapid Block Mode?
thx.
Laurent
PS: do you have a skype # please. This is very inefficient to advance on this by posts. Thx. You can email it directly. Thx.
The rapid block Labview example is posted on this thread. As mentioned, it uses multiple calls to ps4000GetValueBlock. The C example uses a single call to ps4000GetValueBlock. Both ways are valid and achieve the same result.
As per earlier conversation, the LabVIEW example you mention uses multiple API calls. This may be valid but it is not what we want to achieve. It is expected that multiple calls will generate more overhead both in the call and in the data stream resulting in more time for data transmission from the digitizer to the PC than a single call. I am not proficient in C enough to decipher the details of the code. What I can see is that the functions calls in the C code are different from the ones in the LabVIEW example that uses the "API Call-2" version of "API Call". It seems to me that since it is a LabVIEW thread, support should be made with LabVIEW solutions.
Thx.
I am succes convert rapid block 4224 to 5203 with convertion dll and wrap file. But I have a problem, I cannot recive 2 CH1, only ch1 was found. Could you give me information to resive all the chanel in the same time.
Hi Robin,
I am just following up your comments to capture trigger times in rapid block mode for PS4000?
Is this correct that PS4000 is not capable to capture the
elapsed time between each trigger event (or resulting block/waveform) in rapid block mode? if so, what does "ps4000GetValuesTriggerChannelTimeOffsetBulk64" do?
according to the manual this function is designed to capture the time each trigger for each individual waveform occurred. is this correct?
I got confused,
The ps4000GetValuesTriggerChannelTimeOffsetBulk64 function is used to calculate the deviation of the trigger time from the sample time, in order to eradicate jitter.
The way of achieving what you need to do would be to use a system timer such as GetTickCount in the CallBack function, to get the tick count on the first and last trigger, then calculate the elapsed time from there.
I have just made this same question in another post, but just in case you may recieve it faster replying here, there it goes again...
I am having some similar problem to the one described here.
I am working with a PicoScope PS 5203, so that the API I am using is "PS5000", but I guess it should work in a similar way to the PS4000.
I want to retrieve the time offset between trigger times and the first sample in its memory segment (Rapid Block Mode). My aim is to reduce the effect of the jitter, which is a mayor problem in our application.
To do this I am using the function "ps5000GetValuesTriggerTimeOffsetBulk64". The function seems to work fine, but all I get in response in the "times" field are zeros.
An important thing: I am using AN EXTERNAL TRIGGER signal. Is there any problem with this?
I see in the description of "ps5000GetTriggerTimeOffset" that this does not work with the external trigger, and I am starting to think that the same condition may apply to "ps5000GetValuesTriggerTimeOffsetBulk64".
Sorry to revive an old thread, but this one is close to the problem I am having.
I am using a PS3404A to capture 8000 segments in LabView. Using ps3000aGetValues takes one minute
to transfer 2Msamples. ps3000aGetValuesBulk should be able to do it in one second, but I couldn't make it work.
As was pointed out the example in the thread calls GetValuesBulk once for every segment which defeats the purpose.
When I try the Bulk mode, only one segment gets transfered. The problem seems to be that I don't have a proper
way to set the buffers. SetDataBuffer always asks me about a specific segment number.
I tried to set the buffers by initializing SetDataBuffer for all segments in a loop, but then it wouldn't transfer any segments at all. Even if it had worked, this doesn't seem like the right way to do it, since it requires to talk
to the PS 8000 times for each channel to get all data.
PS4000 has a SetDataBufferBulk routine, which sounds like what would be needed. However, even that one asks
for a specific waveform or segment number. ps3000 doesn't even have a SetDataBufferBulk routine.
Any help is greatly appreciated.
Thomas
The problem is occuring because the memory required for the buffers is not preallocated correctly in the for-loop so the driver doesn't quite know where to write to when the ps3000aGetValuesBulk function is called.
The solution is to create and initialise a 3D-array (nCaptures x numChannels x samples) from which you can then extract the sub-array representing the appropriate waveform buffer using the segment and channel combination as indices and pass that to the ps3000aSetDataBuffer function (a portion of the vi is shown below):
Initialising 3D array and extracting sub-array to for ps3000aSetDataBuffer function.
The ps3000aGetValuesBlk function is placed outside of the for-loop as shown below:
Thank you for your response. I tried to modify the vi as you proposed (see attachment),
but the transfered data are all zero.
It is possible that I did the ps3000aGetValuesBulk incorrectly. Since it is not part of the llb file, I had
to create it from scratch.
Did you test your vi, and if so would you be willing to post it here.
Please find the vi attached below - I did test mine with a sine, ramp and square wave input (2Vpp), timebases 64 and 127 and I found it to work.
Try swapping the vi and see if it works for you. I've had a look including checking the parameters of the function call and couldn't see anything immediately obvious. Are you using the dll from the latest SDK?
Hi Hitesh,
I finally got GetValuesBulk to work (see attached vi).
The biggest problem was that auto-indexing of the buffers at the SetDataBuffer for-loop didn't preserve the pointers
to the physical memory locations and GetValuesBulk didn't know where to write the data. I got around it by using the
NewDataValueReferenceFunction (available since LV 9.0) to keep track of the pointers.
Even then, it is very important to keep LV from creating extra copies of the data. Therefore, no indicators, branching
into multiple wires or such.
With this modification the program worked ok, but crashed at more than 80 segments.
GetValuesBulk in your example vi didn't follow the syntax given in the programmer's manual. After changing the
overflow parameter to an array of signed short, even 10,000 segments worked without problems.
Transferring 2Msamples in 8,000 segments now takes a few seconds instead of an entire minute.
One final question: for 1000 segments I get the full 4Msamples (1 channel, PS3404A). At 8,000 segments it is down
to 3.4Msamples and at 10,000 segments I can only use 166 samples/segment. What's up with that?
Thank you for the updated vi. I've tested it here and it appears to capture the data.
I noticed in further testing that the overflow variable should be an array for the ps3000aGetValuesBulk function (it was an error when I was making the transition from using the ps3000aGetValues) so thank you for spotting that.
I've run some tests here using our C console application with regards to the number of samples (shared between channels) and found the following:
As you can see, there appears to be some sort of transition at the point after you reach a number of segments that is a power of 2 (256, 512, 1024 etc.). As the number of segments increases, the driver seems to limit the the number of samples available per segment when you contrast the 256 and 257 segment values with the 10000 and 16384 segment values. It's possibly due to the way that the memory block is structured in the device.