PCIe 6537b - synchronized digital input/output

[Patrick60]

Hello community,

I have one question regarding the digital input/output using PCIe 6537b card and hope someone can help me.

We are currently using the PCI6534 and are searching for a follow-up, because we will receive new desktop PC's which won't have PCI slots (PCIe only). So we decided to test the PCIe 6537B.

When simply using our old DAQmx.vi, which configures the digital data processing for the DAQ card, with the 6537b I get an error (code -89136)

I don't know exactly what's the problem, it has something to do with step 3, deriving the trigger from the master and exporting it via RTSI0 line to the slave as trigger input to get input/output synchronized. The first DAQmx - start task.vi is OK and at the 2nd start task.vi i get the error message.

I tried to edit the used .vi and am not receiving an error anymore up to now.

Unfortunately I don't have a chance to test the DAQcard for e.g. an SPI communcation at the moment, as we don't have a fitting cable for the PCIe 6537B at the moment (just the old ones for 6534)...

Now my question is:

Are the input and output still synchronized, even without the master triggering the slave? I think yes as they both are using the onboard clock?

If not, are there any possibilities to get it synchronized?

I researched the NI website and according this tutorial "http://www.ni.com/tutorial/3615/en/", topic 4 "multifunction synchronization --> shared sample clock" it should be OK?

Any help and comments are very appreciated.

Thank you very much for your help.VI used for PCI-6534used for PCIe-6537B

[Kevin_Price]

1. No, your tasks are no longer sync'ed.  The DI starts first, then the DO starts after.

2. I'm not fond of the original sync method anyway.  My recommendation:

• In the DO task's timing property node, add another terminal to query SampClk.Term
• Wire this (and the sample rate) up to the DI task's DAQmx Timing function
• Continue to start the DI task before the DO task, as you're already doing.  This is all you need to be synced, even if the DO and DI are on different boards with a timing bus connection (such as RTSI or a PXI backplane, etc.)
• I would strongly consider setting the DI task sample clock polarity to be opposite to the DO so that DO happens on the *leading* edge while DI happens on the *trailing* edge.  This often makes the data more meaningful -- DI sample #100 is taken very shortly after DO stimulus #100, allowing your UUT to respond to the signal you inject.   I don't know the default polarity for the sample clock signal, it can probably be found in the manual or with some careful experiments.

-Kevin P

[Patrick60]

Good Morning Kevin_Prince,

thank you very much for your reply and your help.

I edited my programme according your recommendation, the only thing I am not 100% sure about is the SampClk.Term terminal of the DO timing property node.

I have found two terminals which will return an input for the DI's DAQmx Timing funtion.

- SampleClk.Source (german: SampleClk.Quelle)

- SampleClk.timebase.Source (german: SampleClk.Zeitbasis.Quelle)

I hope the selected terminal is the correct one, because I couldn't find a terminal called SampleClk.Term.

I am planning to install the latest DAQmx Version in the next days (depending on when I receive the admin rights to install something on this PC ... -_-) as I am using DAQmx 9.6.2 at the moment... Could this be the reason for not finding SampleClk.Term ?

I've understood the problem with the clock sampling and leading/falling edge, thank you for the hint.

My programme looks like the following up to now:

Could you please just give a short feedback if this should be OK now?

I am completely new to the DAQmx topic; I've thought I understood quite everything with the help of the online tutorial and the LabView help - seems like my thoughts were wrong...

So again thank you very much for your help

Best regards,

Patrick

[Patrick60]

Good Morning Kevin_Prince,

thank you very much for your reply and your help.

I edited my programme according your recommendation, the only thing I am not 100% sure about is the SampClk.Term terminal of the DO timing property node.

I have found two terminals which will return an input for the DI's DAQmx Timing funtion.

- SampleClk.Source (german: SampleClk.Quelle)

- SampleClk.timebase.Source (german: SampleClk.Zeitbasis.Quelle)

I hope the selected terminal is the correct one, because I couldn't find a terminal called SampleClk.Term.

I am planning to install the latest DAQmx Version in the next days (depending on when I receive the admin rights to install something on this PC ... -_-) as I am using DAQmx 9.6.2 at the moment... Could this be the reason for not finding SampleClk.Term ?

I've understood the problem with the clock sampling and leading/falling edge, thank you for the hint.

My programme looks like the following up to now:

Should this be OK now?

I am completely new to the DAQmx topic; I've thought I understood quite everything with the help of the online tutorial and the LabView help - seems like my thoughts were wrong...

So again thank you very much for your help

Best regards,

Patrick

[Patrick60]

I can't edit my previous post anymore..

I've recognized that the used SampleClk.Source seems to be wrong as it just forwards "OnBoardClock" to the DI DAQmx timing function

I tested the programme with the PCI6534 and it doesn't work correctly.

Trying to find out whats wrong, any help is welcome 🙂

Thank you in advance

I've attached the .vi which I am testing at the moment. But the synchronization doesn't seem to work...

[Kevin_Price]

Here's where I found the property on my machine:

I also made a couple mods to your code and backsaved to LV 2012.  Give it a try and let me know.

-Kevin P

[Patrick60]

Hey,

thanks for the screenshot - I think the DAQmx version is the reason why i don't have that much propertys for DAQmx Timing node to select.

Meanwhile today i found out why my original programme didn't work.

-> in the original programme the input source (sample clock) @ DAQmx-Trigger.vi was on RTSI0 line, which is not allowed on PCIe-6537B but was allowed for PCI6534. For PCIe-6537B i changed RTSI0 to RTSI7 and now its working with our original programme.

Nevertheless I want to check your .vi tomorror, thank you very much for providing it.

have a nice evening,

Patrick

[Patrick60]

Good morning Kevin_price,

I've just tried your programme, i get an error -200462 after the DAQmx timing property node.

("output buffer empty")

Maybe it really has something to do with the DAQmx driver version? There is still no "SampClk.Term" in the dropdown menu available, even when using the property node inside your pgoramme.

(I still have no permission to install new drivers on my machine.)...

As i said the original sync method is now working with a small adaption for 6537B and I can now use the original programme for both 6534 and 6537B, so I won't "steal" any more of your time and use this programme.

Thank you very much for your time and your help.

Have a nice day

[Kevin_Price]

Just be careful to understand that the sync method shown in msg 1 for the 6534 will not *always* be the best choice.

What gets synced there is the 1st sample of the lower task and the trigger instant of the upper task.  There's a short post-trigger delay before the upper task acquires its own 1st sample.   In this particular app, that's probably to your advantage as it provides for a little of that system response time I mentioned in msg 2.   You might be able to change the trigger polarity or adjust the trigger delay time to provide a little extra time for system response, if needed.

I don't have a board similar to your 6537B, but I tried my code on a simulated device and got the same error.  It looks like the board may not support the kind of signal routing I'm accustomed to expect from the boards I use more commonly.  Sorry about that, but glad you have an alternate solution.

-Kevin P

[Patrick60]

We didn't have any issues in the last years but now I know where I could adjust the programme to get some xtra time if there

are some problems with data acquiring. Thank you

Ah Ok, so at least the reason is not my DAQmx driver version.

No Problem, thanks anyways for your help and time !