Scope5122, How to change MinRecordLength without changing SampleRate?

[HaD]

Hello,

Im trying to change record length withou affecting the sample rate. the reason is TClk documantation syas that if you dont change the clokcing than the synchronizatio nwill remain and i will not have to do TClk process again.

And i need to change the record length without touching the clocks. but when i do it in propery nodes i see that it affect the sample rate (it want to conserve the Record Time duration...)

Message Edited by HaD on 10-29-2009 10:35 AM

[Jordan F]

Hi,

You are correct in that you do not need to call the niTCLK Synchronize.vi if you are just changing the record length.  However, if you make any changes to the sample rate,  trigger, reference position, and so on, you need to call the Synchronize VI again.  A good example of this is the niScope EX Multi-Device Configured Acquisition (TClk) example program (NI Example Finder).  With this example you can change the record length for each acquisition without affecting the sample rate.  You can change the record length with the Configure Horizontal Timing VI (the property node should work also).

I would like to get some more information from you to verify this behavior you are currently seeing if the above does not help out.  Do you have a piece of code that I could review to learn more about your application?  Also, why is it needed to change the record length for each acquisition?   

[HaD]

The problem is that after i change the record length, i see that the sample rate is also changing. its like that it want to save the record time length constant.

[Jordan F]

Hi, 

I understand that you would like to change the record length but not the sampling rate but for me to help you out I would like you to provide some more information or try out my suggestion.  That being said, did you try the running the niSCOPE EX Multi-Device Configured Acquisition.vi in the NI Example finder?  You can change the record length independent of the sample rate which will increase/decrease your total acquisition time for each record acquired.  Could you attach the program you are currently working with so I can recreate and find the cause of this behavior?  Also, our digitizers need a free running clock that has to meet the duty cycle/jitter specifications so the device will not change the clock rate unless the task is stopped and started again.  If the clock rate was changing that much than the device would throw a hardware clocking error I would assume.  

It would be very helpful if you could provide the code you are working with or try out the example I referenced to recreate this behavior.