synchronizing multiple dio

[mhfracis]

I am using two pxi-1006 chassis daisy-chained, each with four pxi-6534 dio cards and one 6070E card.  My goal is to synchronized all eight 6534 cards with a clock and a trigger.  The clock will be running at about 1MHz.  For one chassis, I can share a clock via the rtsi line, but using a rtsi line to share the trig line would cause each device to trigger at separate times.  This is because the trigger is repeating, so i'm assuming software delay causes them to trigger at different times.  One solution to this is supposed to be using the ai/StartTrigger to synchronize devices (like the example)  This seems to have intermittent errors (Read error -200284)  When my software acquires from all eight cards it is more common than when I only use four cards (single chassis) it happens less frequently.  Is there a way to fix this?

[David L.]

Hi mhfracis,

The error you are getting is a timeout error, indicating that all of the samples have not been read before the timeout value was reached. (3 seconds in your case) I suggest we debug this by starting small. Does this error happen when you only have one card in the chassis? When adding multiple cards, I may suggest putting a simple error handler on each task, and not grouping them together, so that you can tell which task is creating the error and see if multiple tasks are creating an error (I.E. - all of them may be timing out, but we are only getting one error right now because the error clusters are merged together). What about increasing the timeout value? Would that harm your project for any reason? It will be a huge help to narrow down when and where this error is happening, and then go from there.

Regards,

[mhfracis]

I changed the timeout value to 10s and it didn't seem to make any change.  I set the read samples to be less than the acquire samples and the errors seem to be gone.  Why should this matter?  Does it mean i'm skipping samples?

[David L.]

Hi mhfracis,

Can you expand on how many more samples you need to input into the DAQmx timing VI than the DAQmx read, as I am curious if this may be related to a known issue where we need the clock to continue past the number of samples we want to acquire in order to eliminate an error. (Basically, what you are already doing - set the 'read samples' to be less than the 'timing samples', therefore forcing the clock to continue past the last sample you read).

If this does not resolve the issue, I would like to breakdown your code in order to get more information about when and where the error is occurring. Let’s start with some of the items from my last post (1 card; simple error handler for each task to determine where the error is coming from). Please post back with any further details that may be helpful in tracking down the error.

[mhfracis]

The example below is the basically works.  A section of the code will still skip a trigger now and then.  The clock and trigger are on a loop,so I believe that a card will miss the trigger that the other cards are using, and trigger on the next incoming.  It is usually the 4th and 8th cards that will do this.(1-4 are in chassis 1 and 5-8 are in chassis 2).  This happens wether the read samples are the same or less than the acquire samples.  I think some of my early errors were from the data clock phase, ( I had a different clock phase going to each chassis).  I have two triggers in the current setup.  One is a hardware AND gate that only lets the clock through following a trigger.  The second trigger is for the daqmx start trig.  The time between these triggers is about 600us.  Increasing this time, or adding a 1s delay between them doesn't seem to have an effect.  If I take either of these two triggers out, then the data will have an arbitrary start point.  Both chassis i'm using are 18 slot, the cards are in slots 3,5,7,and 9 of each.  To route the clocks through rtsi, i'm using the MAX to connect the busses together. 

The example i've posted will also skip triggers in the same way, though I think it may be slightly less often than the code with all eight cards.

I've tried changing the number of threads that Labview uses (\LabVIEW\vi.lib\utility\sysinfo.llb\threadconfig.vi) but this didn't seem to have an effect either.

I would think i've taken any code processing bottleneck out of question from what i've done.  Is there anything else I should try?

[David L.]

After viewing the information in the service request that was created, the overall problem was that some of the boards did not receive the trigger at exactly the same moment, therefore were not perfectly ‘synchronized’. To synchronize devices in a PXI chassis, the PXI_Star bus must be used, as it has equal length lines from slot 2 to all other slots in the PXI chassis. (What is the Star Trigger on the PXI Backplane?)

The 6534 can only accept the clock from the PXI_Star bus, and not any triggers, as it is a DAQmx device. Only certain modular instrument devices (Scopes, Function Generators, HSDIO, etc) can accept triggers from the PXI_Star bus. Since this is true, the 6534’s cannot receive the triggers simultaneously when being routed through the PXI backplane.