PDA DAQ channels swapping

[Bandit]

Hi everyone.

I'm experiencing problems with a PDA based app collecting analog data from 6 channels. All advice appreciated.

Hardware is a Juniper Allegro CX, running Windows CE.net 4.20, Intel ARM X-scale processor, 128Mb RAM, NI DAQCard 6024E in expansion pod.

Development platform is LabVIEW 8.6 with PDA module.

DAQmx base has 6 channel continuous acquisition set up, channels 0 to 5, 100Hz scan rate, 1000Hz conversion rate, as task 'readg' (see code)

Acquisition seems to be running perfectly well for a while, then channels switch around. e.g. all channels grounded, except for channel 2 with 0.1HZ sine input from a sig gen and channel 3 hardwired to 3V. After 30 seconds or so the channels all move around by 2 positions, Ch2 readings move to Ch0, Ch 3 to Ch1 etc. After another 30 seconds they move again by 2 steps, and after another 30 seconds or so they move two further steps (so they are back where they started). This continues until app is stopped.

This thread suggests something similar, but doesn't run to conclusion so no solution there... http://forums.ni.com/ni/board/message?board.id=250&message.id=12209&query.id=3315#M12209

(side issue - can anyone tell me how to post a thread in a neater way than this?)

Struggling here. 100Hz per channel is fastest required by my app, it's needs to run for up to 15 minutes, and channels need to stay put!

I'm posting code from a calibration routine that's doing this. The routine is part of a larger application. Upper loop is handling user interface and sitting in part 2 in the idle mode, so shouldn't be interfereing with anything.

Thanks for any assistance you can offer.

Bandit.

[Jeremy_T]

Hi Bandit

I hope you're having a good day. I've been looking into this issue and have got hold of a PDA so that I can try and see whether I can replicate the same behaviour you are seeing when performing your data acquisition, but I just wanted to ask a couple of questions too.

Have you tried acquiring on just a single channel to see whether that works out fine? Does this behave any differently from multiple channels?

Do the intervals between the channels swapping seem constant, or is there an element of randomness to this?

There's nothing immediately obviously incorrectly set up in your code, so I'll try to set something similar up myself and let you know the results.

Kind Regards

[Bandit]

Hi Jeremy, thanks for replying. I seem to have trouble posting hrer today, but I wll try again.

There were no noticable errors using just one channel. Not sure how I would spot one channel swapping with itself however

I haven't tried with other numbers of channels (2, 3, 4...). As swapp was by 2 channels every time I wonder what would happen with an odd number of channels?

Swapping did seem to occur on a regular basis, no randomness was noted, but Ididn't time the intervals between swapping either.

I'm working on another project at the moment, so can't follow any of these idea's up further just at the moment.

Let me know what you find when you try it.

I realise the DAQmx base setup won't be included with the files I posted. If you want to know settings I used, or can tell me where on the PC to find the file of settings, I'll attach them to a post here as appropriate.

Best regards,

Bandit

[Jeremy_T]

Hi Bandit

Sorry, I don't think I put that particularly well - it would be rather odd if the channel could swap with itself! I was wondering more whether there was any other unexpected behaviour for just a single channel, but as you've said, there was no noticable error.

I shouldn't have thought I'll have any trouble setting up a DAQmx Base task myself for the purposes of testing this, but if you do get a moment then it's possible to export your MAX configuration by following the steps in this KB.

I'll keep you updated on my findings.

Kind Regards

[Bandit]

Hi Jeremy,

Are you sure I can export from MAX? I can do that for NI-DAQmx setups, but I don't think MAX will play with DAQmx Base.

Regards,

Bandit

[Jeremy_T]

Hi Bandit

That's true, sorry about that. I'll let you know if I find where you can transfer the DAQmx Base task from, otherwise, I'll keep you updated on whether I can replicate the issue here.

Kind Regards

[mikealder]

Jeremy, Have a dig through the NI records for a fault logged by me with a large SCXI system probably circa 2001 it transpired that Radar interference was knocking out some of sync signals - I doubt its the same as this fault but the end result sounds very similar - Sasha and Dave Emery were both involved in this Warton/ Woodford issue.

In the end we decided to detect when it skipped and re-initialised the daq card to clear the fault as screening the interference wasn't viable - Mike

[Jeremy_T]

Hi All

Sorry about the delay in getting back to you, I was out of office for a while. In the meantime though, a colleague of mine has been trying to replicate the issue using a PDA we have here at the office. Unfortunately though, whenever he tried taking measurements, he was unable to see any evidence of channels swapping in this manner.

Thanks a lot for posting, Mike. Funnily enough, Sacha still remembers that problem and I spoke to him about it as we sit nearby in the office. He described to me the way that your SCXI channels were swapping due to a nearby radar system and it does sound very similar to this issue. Bandit, could you be experiencing similar interference in your location? Are there any RF sources in your area? Could you try taking the PDA to another location and trying it out there to see whether that makes a difference. I would expect that what we are seeing is due to something in hardware, rather than software, since all the drivers do is assume that the first sample will be from channel 1, second from channel 2, third from channel 3 etc. Therefore, there must be some kind of hardware glitch that is causing this. Could you give us any information about the expansion module you are using to connect your DAQcard to the PDA? There may be a possibility that this interface is somehow causing a glitch in the data.

In terms of dealing with the channel swapping, one suggestion could be to pass a known reference voltage down one channel and detect when this reference voltage has been switched to another channel. This will tell you when the switching has occured so then you could tailor your other channels accordingly. I believe this is the type of thing that Mike did to get round the issue. Can you confirm whether this is the case, Mike?

Kind Regards

[mikealder]

As I have 64 channels of voltage input available on the 700+ channel SCXI system I fed the following in to the system:

+24V in to VIP062

0V in to VIP063

-24V in to VIP064

When the channels skipped it was easy to detect with a simple comparitor gate looking at each of the three channels, when they detected a skip event a simple call to re-initialise the DAQ card which put the channels back where they should have been.

We added a "Skip Counter" to the front panel of each of the vi's that run on the system and can often see skip counts as high as 400 in a single day, but to the end user they cannot detect the skip, a typical single iteration of the main vi would take around 50mS when the skip is detected this iteration time increases to around 250mS for the single iteration while the card is re-initialised then it settles back down to 50mS.

Not ideal, but screening the SCXI hardware wasn't viable and with 150 feet long test interface cables connected to the back of the system these would act like aerials anyway, so the easy option (for me) was to detect the skip and deal with it as it occured. (Not too surprised Sacha hasn't forgotten this one as it had quite a few of your chaps scratching their heads for a week or two) - Mike

[Bandit]

Hi Mike, I have been having trouble posting here, but let me try again.

Firstly thank you for taking the time and trouble to post.

My application is significantly different to yours - runs for a few minutes, PDA based, short cable lengths (<0.5m). I'm sure I could implement something like you suggest, but would also need to indicate when data was lost during initialisation and for how long. It's possible that during those periods significant data coulsd be lost. The data is also post processed by synchronising it with other information. For that synchronisation to remain valid throughout the test period the duration of the drop outs would have to be known - possibly the data would have to be padded during the re-initialisation.

However, due to work pressures this particular development has been contracted out to an external company. Though the resulting application is not yet faultless it doesn't present this particular fault. The external company have written their own aquisition code. I'll post back when I know more, meanwhile thanks for your interest in my problem.

Regards,

Bandit.