Rapid Block Mode LabVIEW PS4224

Post your LabVIEW discussions here
BSI
Newbie
Posts: 0
Joined: Wed May 12, 2010 3:15 pm
Location: Canada

Re: Rapid Block Mode LabVIEW PS4224

Post by BSI »

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.

Robin
Advanced User
Advanced User
Posts: 558
Joined: Fri Sep 19, 2008 10:17 am

Re: Rapid Block Mode LabVIEW PS4224

Post by Robin »

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.

BSI
Newbie
Posts: 0
Joined: Wed May 12, 2010 3:15 pm
Location: Canada

Re: Rapid Block Mode LabVIEW PS4224

Post by BSI »

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.

User avatar
ekawaldi
Newbie
Posts: 0
Joined: Sat Jun 26, 2010 9:19 pm

Rapid Block Mode LabVIEW PS4224 to PS5203

Post by ekawaldi »

Thank you Mr Robin, your Rapid Block mode for 4000 series, I can changed to 5000 series.



Eka

User avatar
ekawaldi
Newbie
Posts: 0
Joined: Sat Jun 26, 2010 9:19 pm

Rapid Block Mode LabVIEW PS4224 to PS5203

Post by ekawaldi »

Dear Mr Robin,


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.


Best Regard,


ekawaldi
Attachments
PS5000_rapid_block_8.0.zip
(98.89 KiB) Downloaded 489 times

Robin
Advanced User
Advanced User
Posts: 558
Joined: Fri Sep 19, 2008 10:17 am

Re: Rapid Block Mode LabVIEW PS4224

Post by Robin »

Hi

The 4000 example works for two channels, so it should be straightforward to get both channels working for the 5000.

What exactly are you having problems with?

Robin

Peyman
Newbie
Posts: 0
Joined: Sun Oct 03, 2010 5:40 pm

Re: Rapid Block Mode LabVIEW PS4224

Post by Peyman »

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,

/p

Chris
Site Admin
Site Admin
Posts: 169
Joined: Tue Aug 17, 2010 9:00 am
Location: St. Neots

Re: Rapid Block Mode LabVIEW PS4224

Post by Chris »

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.

msagues
Newbie
Posts: 0
Joined: Fri Feb 24, 2012 7:44 pm

Re: Rapid Block Mode LabVIEW PS4224

Post by msagues »

Hello Chris!

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".

Thanks in advance for your time,

Mikel

ThomasH
Newbie
Posts: 0
Joined: Thu Nov 15, 2012 10:09 pm

Re: Rapid Block Mode LabVIEW PS4224

Post by ThomasH »

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

Hitesh

Re: Rapid Block Mode LabVIEW PS4224

Post by Hitesh »

Hi ThomasH,

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.
Initialising 3D array and extracting sub-array to for ps3000aSetDataBuffer function.
The ps3000aGetValuesBlk function is placed outside of the for-loop as shown below:
Calling ps3000aGetValuesBlk outside of loop.
Calling ps3000aGetValuesBlk outside of loop.
Hope this helps.

ThomasH
Newbie
Posts: 0
Joined: Thu Nov 15, 2012 10:09 pm

Re: Rapid Block Mode LabVIEW PS4224

Post by ThomasH »

Hi Hitesh,

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.

Thanks,
Thomas
Attachments
THPicoScope3000aGetRapidBlock.vi
(37.6 KiB) Downloaded 503 times

Hitesh

Re: Rapid Block Mode LabVIEW PS4224

Post by Hitesh »

Hi Thomas,

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?

Thanks,
Attachments
PicoScope3000aGetRapidBlockBulk.vi
Modified PicoScope3000aGetRapidBlock vi file
(39.09 KiB) Downloaded 516 times

ThomasH
Newbie
Posts: 0
Joined: Thu Nov 15, 2012 10:09 pm

Re: Rapid Block Mode LabVIEW PS4224

Post by ThomasH »

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?

Thanks for your help,
Thomas
Attachments
GetData.vi
(24.06 KiB) Downloaded 553 times

Hitesh

Re: Rapid Block Mode LabVIEW PS4224

Post by Hitesh »

Hi ThomasH,

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:

Code: Select all

Segments               Samples
255                        16294
256                        16294
257                        15782
511                        8102
512                        8102
513                        7590
1023                      4006
1024                      4006
1025                      3494
2047                      1958
2048                      1958
2049                      1446
4095                      934
4096                      934
4097                      422
8191                      422
8192                      422
8193                      422
10000                    166
16384                    166


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.

Best wishes,

Post Reply