SCXI-1540 initialization issue

[ayoung]

I am using an SCXI-1000 chassis with an SCXI-1540 8-channel LVDT module in the first slot. I am also set up with an SCXI-1349 and SCXI-1180 feedthrough to make use of a digital output on the PCI 6220 DAQ board.

I have developed an application using LabView 7.1 and DaqMx (Not sure of the exact version offhand).

This application works great - I have my own calibration routines which give me pretty accurate results. The only problem is that, after the system sits for awhile or is rebooted, the LVDT reading does not seem to work correctly when the application is restarted. I used the example for measuring position under Examples/Daqmx/Analog Input as the basis for my LVDT code. I find that if I change the measurement limits, then change them back, or if I run a test panel in MAX first, my software will start working. This seems to be some sort of initialization issue, or perhaps there is a flaw in my usage of DaqMx. I do not want to create tasks in MAX. I want to do the bare minimum setup in MAX and create the task programmatically just like that position example. This would minimize the work needed to setup this system in the future in the event of a computer or hard drive crash. If I name the task could that help? I'm open to any suggestions here.

The only thing that is sure is that there is some sort of initialization issue. It seems like there is some caching mechanism with regard to the max and min limits, or other input parameters that affects the 1540 module with DaqMx. If so, how do I fix this initialization issue? I am thinking of trying to configure a dummy measurement at the start with different parameters as a workaround, then close that task and start my usual measurement. Remember these tasks are all unnamed like the example. If I close out one task and start another with different sample rates, is there something I need to do?

[Tom_W_[DE]]

Hi ayoung-

This is an interesting problem.  Naming the tasks won't make any difference, but if you're comfortable with creating and destroying a dummy task before your actual operation then you may have found a quick workaround.

Can you let us know how exactly your code differs from the original?  Generally I would expect this to be a software initialization problem and not something with the module itself.  I would check your VI for any uninitialized shift registers or some other means to explain why the previous settings seem to be being saved.  Also, I would suggest testing with the example itself to see if you can observe the same behavior once your VI starts to exhibit the same.

If you power cycle the chassis or the PC itself there isn't a built-in mechanism for re-synchronizing all the parameters between the PC memory, LabVIEW, and the SCXI hardware itself.  For this reason it is generally recommended to power the PC first and then the chassis when you need to reboot the system.  If you need to power cycle the chassis or just reinitialize it once it enters this state a chassis reset in MAX should be helpful.

Hopefully this helps-

[ayoung]

Tom,

Thanks for the reply.

I am not sure as to all the conditions that lead to a repeat. It is not always an issue, but seems to occur when I start working with the system after I have been away. Once I get the system running, everything is fine with regards to this issue. The PC with the 6220 is left on, so it is not necessarily a reboot related issue. I do turn the SCXI chassis off when I am gone, and power it up without rebooting the PC.

The issue repeats even with the example VI (Cont Acq LVDT Position - or something similar to that name). My VIs essentially keep the internals of that VI the same but split it into a few parts, one to generate a Task ID and start acquisition based on all the input parameters, one to read the contents of the buffer on the fly, and one to close the Task ID. I have a parallel loop that does all the LVDT reading while the test is sequenced from the main loop. A queue is used between the loops to communicate. When I send a log command, the old Task is closed and a new one started at a different sample rate for the test. When the test completes, that task is closed, and yet another task is started with the original parameters. This parallel loop essentially switches between two acquisition rates while keeping the other parameters the same. Regardless of all this new structure, it appears that the example VI exhibits the same behavior. I can change the measurement limits in that VI and run the example again, and it starts working. From that point forwards all LabView LVDT code starts working.

Incidentally, I have another LVDT question. Is there any kind of built in mechanism in either the 1540, or in MAX for filtering vibrations out of the measurement? If not, I can oversample and average and/or perform a windowed average to filter them out. I'd rather stick with raw readings where I can, but I'm running into issues because the LVDT is being used for a strain/load type application but it is picking up vibrations (as an LVDT should) as it moves on a servo drive. These vibrations are fairly symmetric, so I've had some success with averaging, but it is difficult to filter out the lower frequency vibrations without affecting the results too adversely. In many cases the vibration amplitude is greater than the measurement I'm trying to take, so the results can be buried in mechanical noise. I know that full and pro LabView have the measurement toolsets that perform FFTs, etc and help with precise filtering, but I'm working with the base version right now. If there aren't any settings in MAX to dampen the vibrations (low pass filtering of the demodulated analog input, etc.) then I'll probably continue experimenting with different forms of averaging.

Thanks for your help, and thanks in advance for any future help.

-Tony

[ayoung]

Ah - I just realized that I am cycling the power as you had first stated, so I should call the reset chassis VI as you suggested when I start my application, since I am using the same parameters as the last time. I'm guessing that if no changes in parameters occur between a task prior to chassis shutdown and a task after chassis restart, MAX or the chassis caches the parameters, detects no change, and doesn't send any update to the 1540. I'll let you know if I have any luck with the reset chassis.

Thanks again.

[Tom_W_[DE]]

Hi ayoung-

Yes, you will absolutely need to reset the chassis before you can expect to see correct readings again from your app.  Please let us know how it turns out.

Thanks-