CAR ID 208056 (SampleClockTimebase property incorrectly supported by cDAQ)

[mdelsol]

Hi,

NI-DAQmx 9.2.1 Readme says that CAR ID 208056 (SampleClockTimebase property incorrectly supported by cDAQ) is being fixed.

As I have problems exporting SampleClockTimebase from NI9237 to NI9234 using 2 different tasks with NI-DAQmx 9.1.1 I would like to know if the fixed issue solves my problem.

So please where can I find more information about the fixed issue? I searched in the web without any success.

If someone knows more about it explanation will be appreciated.

Thanks in advance.

Marc.

[Brooks_C]

Hello Marc,

The CAR that you have referenced actually referred to the fact that we were unintentionally allowing users to export the SampleClockTimebase signal to an external PFI line.  When we disabled this routing, it had unintended affects on same-chassis task synchronization for modules that utilize the SampleClockTimebase signal for synchronization.

I have submitted CAR #246651 to our R&D group so that this behavior can be investigated.

I am going to try a couple of things to see if I can identify a work around.  Does the first post in your previous thread accurately describe your desired application?  (NI 9237 & NI 9234 synchroniz​ation different rate cDAQ-9178)

Best Regards,

[mdelsol]

Hi,

Thanks Broks for your explanation and interest.

I did some test before updating my system to NI-DAQmx 9.2.1 and found some improvements that previously didn’t work, but main problem persists. With NI-DAQmx 9.2.1 it’s possible to synchronize 2 independent tasks of NI9234 & NI9237 using the internal 100 kHz Time base, with version NI-DAQmx 9.0.2 was impossible, always appeared error -200284 (see attached VI named: 9234-9237_100kHzTimebase_error-200284 (NI-DAQmx921 solves error).vi)

Is this behaviour related to the CAR #208056?

Months ago I tried something similar using counters and freqout, but didn’t work. I’ll do more tests with this new version.

If I understood well the new CAR that you submitted refers to my problem is that right? If so thanks so much, as I think that according all the manuals it should be possible to do it. In fact when they are together in one task the 2 modules share they time base, but if we want to use 2 different rates 2 tasks must be used.

Any way please can you check attached VI to verify that I’m not missing something… maybe cDAQ works different…

Yes my first post in the mentioned thread explains my intention, but frequencies may be confusing. Main thing is to synchronize 2 tasks with different rates using NI9234 or NI9237 time base. If you have any doubts don't hesitate to contact me. See attached vi’s.

Regards,

Marc.

[Brooks_C]

Hello Marc,

While I do not have the perfect solution, I have identified a couple potential work arounds for this issue.  In addition to these work arounds, I am working directly with our development team to make sure that we get accurate CARs filed address these issues in the future.  For this purpose, I've generalize the problem to be "Multi-rate Synchronization of Delta Sigma Modules in a cDAQ-9178 Chassis."

First of all, the most direct (easiest to implement) method of achieving multi-rate synchronization would be to put all of the modules in the same task and decimate some channels in software.  The obvious disadvantage of this is that this limits you to rates that are integer divisors of the fastest rate.  The less obvious disadvantage is that since the decimation is done in software, the effective Nyquist frequency is the rate at which the data was acquired and there may be aliases between the Nyquist rate at which it was acquired and the lower, decimated, Nyquist rate.

The method that I chose to implement involves using one of the cDAQ-9178's internal counters to generate the sample clock timebase that is shared between all of the tasks.  This counter may divide down the cDAQ-9178's Timebase (80 MHz) by integer multiples--this means that you cannot provide a timebase clock at the exact rate of either our 50 kHz or 51.2 kHz modules so the rates will be off from what either module does on their own.  Additionally, while testing this solution, I ran into similar routing issues with the synchronization pulse (which I will be filing CARs for as well) so I used a second counter to send the sync pulse to both modules.

I would like to stress that I view the attached example code as a work around and not an ideal solution.  I believe that what you tried initially should work and that is what my CARs will reflect.  I tried to add comments on the block diagram for all of the critical portions of code so that you can generalize it to your application.  Please let me know if you have any questions, its my hope that with a little bit of modification we can get something that will work for you, for now.

Best Regards,

[mdelsol]

Hello Brooks,

Thanks again for you effort and I'm glad to see that finally NI is doing something to solve this issue, any way I think that until no final solution is found NI should include some comments or references on the Delta Sigma Modules manuals to prevent people from wasting their time trying to do something that is not possible yet.  

Using the counters in not a good solution for me, as one of the new chassis advantages is that has 4 counters and I had other plans for them.

As I don't need this DAQ system to be working until the end of this year, do you think that next DAQmx release could already solve the problem?

just asking to avoid expending more time searching for an alternative solution.

Please I need you to attach your work around example again in LV2009 or LV8.6 to work on it as I don't have 2010 version.

Sorry but I couldn't answering before.

Regards,

Marc.

[crimolvic]

Hi there,

I'm trying to synchronize a 9234, 9219, 9235 and 9237 devices on a 9178 cDAQ chassis. Each device must acquire at different rates. I was trying a solution similar to the exposed in thes thread and one referenced herein (i.e. export the MasterTimebase from either the 9235 or 9237 and using it as the MasterTimebase from the other devices); however, without success.

Searching in the forum I came to this thread.

Considering that some time has passed from the last post, do you have any news regarding this issue?

Greetings,

Cristián

[RCampbell]

Hi Cristián,

What kind of errors or problems are you running into?

On the 9178 chassis, there are only three analog input timing engines.  This means you can only have 3 different analog input tasks running at different rates.  For your application, it will not be possible to have all four modules running at different rates.  You can have 3 separate tasks, but one of those tasks will have to contain two of your modules.

Synchronizing the 9234, 9235, and 9237 is fairly easy.  You can share the oversample clock from the 9234 with the other two modules by using the DAQmx Timing:Sample Clock: Timebase Source attribute.  I chose the 9234 as the master timebase here because DAQmx normally chooses the fastest available timebase when synchronizing multiple delta-sigma modules in a single task.  See the attached VI (LV 2009) for an example of how to synchronize three separate tasks with delta-sigma modules.

For the 9219, your best option is to place the 9219 in the same task as one of the three other modules.  Since the 9219 can only sample data at 2-100Hz, depending on the timing mode being used, the channel data will contain repeated samples.  The 9219 will attempt to sample data at the fastest rate possible given the chosen timing mode.

I hope this helps solve your problem.

Best Regards,

[crimolvic]

Hello Ryan and thanks for your reply,

one of the problems I was running into was the non-ability to handle more than three different tasks at a time. Thanks for the hint in this regard. It would, however, be nice to be able to handle more than three tasks with different input types (e.g. acceleration, current, temperature, strain gage) and different sampling rates. It is possible to do this by, maybe, using some sort of timing device installed on the chassis, which provides additional timing engines?

Another question. I am letting the 9235 out of the application. I am using the TimebaseClock of the 9234 as the source for the TimebaseClock of the other two devices (see vi attached, LV2010). Then, I am using the StartTrigger for the slave devices. As I understand this should function; however, I am getting the error -201088 when the TimeBase rate and source are imported into the 9237 (i.e. on the "error out 2" indicator). Do you have any hint?

Greetings,

Cristián

[RCampbell]

Hi Cristián,

What version of NI-DAQmx are you using?  A bug was fixed in NI-DAQmx 9.3 that will allow the method I suggested to work.

[crimolvic]

ok, that can solve the issue. I am using DAQmx 9.1.5 (supplied with the hardware).

I'll let you know if the problem is solved. Thanks again for the support.

Regarding the other question. It is possible to "add" timing engines through a device or something similiar?

Regards,

Cristián