LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

MAX configuration bug/corruption?

Hello,

Was wondering if anyone else has run into this strange issue.  In essence, we believe that MAX either has a bug of some type, or we have somehow corrupted our MAX configuration over time and lots of tweaking.

We have an SCXI based system with about 85 channels, five 1125's, a couple digital cards and an analog output module further down the 1001 chassis.  Four of the 1125 cards have the 1338 current input terminal block, one of them has a 1313.   DAQ 7.5, LabVIEW 7.1.xx (whatever the latest patch was).

A couple channels on the 1313 are giving us problems, but only intermittently.  Sometimes they work, sometimes they rail at the max value specified in MAX.  We have verified the voltage that we are expecting is indeed correct by hooking a voltmeter up parallel.  We have pored over the entire system for possible ground loops, that is not the issue.  We have switched the transducers to empty channels on the same terminal block, same result.  Every single LabVIEW call to a DAQmx function, in any way, has errors propogated out....LabVIEW thinks everything is just great, no errors or warnings reported.
Here's the odd part.  Once the problem shows up, always a voltage that is much higher than we expect, if we test the channel from the virtual channel interface of MAX, it will continue to fail/show the same voltage we saw in LabVIEW.  However, if we remove the scale, save the channel, then reapply the scale, save the channel, it fixes the issue (until of course it decides to rear its ugly head again).  Moreover, if we use the "Test Panels" interface of the 1125 card itself (as opposed to testing the virtual channel itself), and look at the physical channel without the scale being applied, a call or two here will fix the problem.

My code runs the same each time....there is no possibility for race conditions in my initialization of DAQ, everything is strictly done in the same order each time.  No errors reported at all.  Sometimes it shows up, sometimes it doesn't.  As far as I know, once the problem shows up, the only way to fix it is to do the aforementioned black magic in MAX, or to simply shut LabVIEW and MAX down altogether (sometimes will work), or reboot (always seems to work).

Questions: 
1.  Does a MAX configuration ever become corrupt?  We've been changing channels, scales, etc, over and over again on lots of channels for over a year.  We’ve also exported and imported configurations at least 50 times.  If MAX can indeed become corrupt, then it might be worth our time to just reset the configuration and manually input all of the channels and scales over again, as opposed to importing our saved configurations.  But I'm reluctant to do that on a whim, as we have quite a few lengthy tables being applied, would take at least a full day, not to mention being confident that everything is applied correctly.  Oh, and yes, we have deleted the problem channels and recreated them, no help.

I'm also considering scrapping MAX altogether and just hardcoding all of this into LabVIEW, but again I'm not sure that would fix the problem, and this would take at least a couple days.

2.  Anyone else run across this?

3.  Why would removing and re-applying a scale fix the problem?  This suggests to me that MAX does indeed exhibit a configuration bug in our system.

4.  If there is a known issue with this version of MAX/DAQ, would moving to the very latest DAQ help out?

5.  Could this behavior be exhibited because of a damaged 1125 or 1313?  (Unlikely, unless we happen to have two sets of 1125's and 1313's that are damaged in precisely the same way).

One thing I noticed:  The 1313 front end is a 100:1 attenuator on each channel that you can either use or bypass.  It does seem consistent with the data we're seeing that somehow maybe on occasional runs that attenuator is being bypassed or not configured correctly while the 1125 thinks it is attenuated, resulting in a post-gain voltage far too great for the 1125 to handle gracefully.   Since MAX hides all of this info from you, it is tough to tell for sure. 

Thanks in advance, we've been chasing this issue for some time now, am starting to consider a job shoveling gravel instead.

-Ben

0 Kudos
Message 1 of 4
(3,049 Views)
I meant to post this in the signal conditioning forum, don't know why it's here.  Could the mods please move it?
0 Kudos
Message 2 of 4
(3,034 Views)
Hi Ben,

You're definitely right.  The issue that you are dealing with is very 'unique'.

It sounds like your prognosis after question 5 is most likely the correct prognosis.  I think that the best solution at the moment would be to upgrade to Uninstall MAX and upgrade to DAQmx 8.0

I know that will be a bit of a pain, but it's usually the best thing to do when dealing with really weird cases like this one.  If you still notice the problems, then you might want to split up your system, and try using the 1313 on a different module and see if the problem follows the module or the terminal block.

Regards,

Message Edited by Otis [DE] on 03-13-2006 03:07 PM

0 Kudos
Message 3 of 4
(3,019 Views)

I have been dealing with the same issue with a SCXI-1313 terminal block on an SCXI-1125 module.  Rebooting rarely works for me.  I am going to try removing the scale, save the channel, and re-apply the scale.  Some of the people I work with have looked at the set-up and decided that the SCXI-1313 terminal block is faulty.  However, if I change the 1125 configuration in MAX to have a 1328 terminal block (which are my other terminal blocks), the 'faulty' 1313 behaves nicely.  I am willing to purchase a new 1313, but I'm not convinced that the problem will go away.  What finally worked?

Thanks,

Karol

0 Kudos
Message 4 of 4
(2,892 Views)