rtsi timing issues with PXI-6733

[Chad_M._Carr]

Hello,

I have a hardware timed RT PID loop which for the last few years used a PXI-6052E for both the analog inputs and output, using RTSI0 to pass the AI scan start signal to the AO clock.   I have now added a PXI-6733 8 channel AO card to the system, with the intention of having several control loops running simultaneously, but have run into some "interesting" results trying to synchronize the AO updates to the AI scan clock coming from the 6052.

The baseline program I am using to perform checkouts is the example code "Real-Time PID Contol.vi" provided with LabVIEW; the only modification I made was to add a second "device number" control so the AI and AO functions take place on the separate cards.

Putting the 6733 card in and trying to run it with the AI scan start signal on RTSI0 did not work; no DAC updates occurred.  Likewise, none of the other RTSI lines performed either.  As a sanity  check I externally cabled PFI7 from the 6052 to the 6733, and lo, that did work. 

The "interesting" discovery was that, after configuring for PFI7, if I then reconfigured for RTSI 3 (or 5), it works just fine!  Rebooting the machine clears that; neither 3 nor 5 work, unless I first configure for PFI7.

I've (obviously) had none of these issues using a single 6052.   Using a second 6052 as the AO while leaving the original as AI works just like one would expect, with any of the various RTSI and PFI lines working well, which leads me to believe there are some "undocumented features" of the 6733 I need some help understanding.

Any thoughts will be greatly appriciated; likewise, if anyone can point me to some documentation that explains some of the intricacies of RTSI/clock/trigger/etc (such as why "RTSI connection" doesn't work, but "RTSI pin, low to high" does) I would be forever grateful.

Thank you,

Chad

[Ryan_V[DE]]

Chad,

It sounds like you are reconfiguring your system and possibly developing some new code to run it. Would upgrading to NI-DAQmx be an option? DAQmx is our latest data acquisition driver, and it greatly simplifies single-point and multi-device synchronization. Furthermore, Traditional NI-DAQ (Legacy) is no longer being developed, so if something like this turns out to be a bug, it will not likely get fixed in Traditional NI-DAQ, but will in NI-DAQmx. DAQmx requires at least LabVIEW 7.0, and is compatible with both of your devices. I would highly recommend this option if you can upgrade.

As for your existing code, I cannot immediately see what could be causing this problem. Just to make sure, you are switching both the Route Signal signal name as well as the AO Clock Config clock source? If you are switching one but not the other, then switching them back later on, I could certainly see how this behavior would occur. Just to make sure that the loop is running, could you check the iteration count of the loop while your application is not working correctly? Finally, could you post your code in order for me to make sure that everything else is working correctly? I know that this is a shipping example, but it is possible to save changes in the examples, and no one would know any better.

Regards,

[Chad_M._Carr]

Ryan,

Thank you for your response, below are answers to your questions.

Upgrading to DAQmx is a rather painful process, as we have over 130 MB of coding spread across about 600 vis for this application.  While I realize traditional DAQ is no longer supported, it is a bit of a sore point for me to hear "try DAQmx", as I've found (on other projects) at least as many issues with that driver set as I have with traditional DAQ, so it is far from a panacea. 

For the other, code related questions, it's probably easiest to answer them in reverse order:  As I mentioned, I've been running a (slightly modified) version of the example code "Real-Time PID Contol.vi" that ships with Labivew to perform these checkouts, so posting my specific code is unnecessary.  The only modification I made to the example vi was to add a second control so the AI and AO task ID's went to the separate cards, and it recreates all the same symptoms I see in our other code, and works just fine with a single 6052E (setting both AI and AO to the same device number).

The loop is running, as I do see changes to the displayed AI channels.

And finally, I did verify that I am changing both the routing from the 6052 (using the route signal vi) and the routing to the 6733 clock (AO clock config).  It did almost seem like there was something odd going on with the routing, and I've been playing a bit with resetting the boards prior to sending the commands, just to see what that affects. 

The only other peculiarity I've seen since my original post is that occasionally the 6733 does see the update pulses, but with a huge (several second) delay from the time the value changes on a probe going into the "AO single update".  I have the loop rate set at 1000 Hz, so that is several thousand iterations before it sees (or at least responds to) the update clock!  Between that and the fact the system works fine using PFI7 is making me think maybe the RSTI lines in the chassis are being lugged down somehow, so I'm also pulling another chassis over, so I can see if perhaps these effects are peculiar to the 1052 chassis I'm using.

Let me know if you have any thoughts, and I'll post any discoveries I make with the new chassis.

Thanks again,

Chad

[Chad_M._Carr]

Ryan,

Found the problem.  Or, at least narrowed it down quite a ways.  The problem disappears if I completely populate the PXI chassis with cards.  So, there is some issue with the RTSI bus on my PXI-1052, or the 6052E isn't driving it well, or ???  At least it's not a code issue; time to give my rep a call and get this chassis looked at!

Thanks again for your time,

Chad

[Ryan_V[DE]]

Chad,

Glad to hear that you narrowed down the problem. Did you try both 6052s driving the RTSI line? If so, then I think you are correct assuming that this is a problem with the chassis. Please let us know if you have any more questions.

Regards,