Export Clock not working after DAQ hardware change to PCIe 6535B

[pallen]

I have a LabVIEW application that has replaced an existing PCI-DIO-32HS with a PCIe-6535B 

Above is a screenshot of the code that is generating an error.  

Error -89136 occurred at DAQmx Start Task.vi:7220001

Possible reason(s):

Specified route cannot be satisfied, because the hardware does not support it.

Property: SampClk.OutputTerm
Property: SampClk.Pulse.Polarity
Destination Device: Dev2
Destination Terminal: RTSI0

Task Name: Digital In

I was assured that this hardware upgrade would "work" for this project.  Hopefully there is some other way to more or less the same thing.   

The hardware specification indicates that there are 3 bi-directional clock terminals at PFI 4, 5 and RTSI 7 

I have tried different combinations of these terminals in the code with no luck yet.  

Any suggestions on where to look or what to try next are greatly appreciated.  

[Kevin_Price · Accepted solution]

First, I'm afraid I'm not familiar with the 6535B, but I did make a simulated device of one in MAX so I could check the "Device Routes" tab.  From there I'm trying to piece together a working theory.

Your code tries to "connect terminals" From RTSI0 as source To PFI2 as destination on some device, but it isn't clear whether it's the 6535B.  This method of signal routing happens outside any task context, and seems unlikely to be the cause of the error message which seems to reside squarely "within" a task context.

Meanwhile your error text refers to an error routing From some task's sample clock as source To RTSI0 as destination.  And the Device Routes in MAX show that the DI sample clock can only be routed to PFI5 on the 6535B.

Admittedly, I don't know the implications of your DAQmx Timing node declaring sample timing method as "Burst (Export Clock)", but since you wire in the same RTSI0 terminal name, I now suppose that that's where the illegal routing is being configured.

So, you want to export your task's sample clock to RTSI0 and then further route from RTSI0 to PFI2 using Connect Terminals.

Looking over the Device Routes tab, you would need to configure DAQmx Timing to export to PFI5 instead.   It appears that you could use Connect Terminals to route from PFI5 to PFI2 (if needed).  Or maybe you're free to rewire to use PFI5 instead of PFI2.  I think you might also be able to route from PFI5 to RTSI0 if needed to drive timing on some other device connected via RTSI.   I tend to do all my routing in a task context, so I don't know whether Connect Terminals allows more than 1 route from a given source.  I tend to suspect yes, but don't really know.

-Kevin P

[pallen]

Hi Kevin, 

Thanks very much for your reply. 

Later when looking through the specification and testing in simulation, I found the combination of PFI5 to PFI2 would appear to work in the Read.vi  But would generate an error elsewhere in the code.  

PFI5 to PFI4 appears to work in simulation without error.  I'll find out on Monday if it works with the hardware, but I think you found the solution.  

I don't think there are ( or were ) any peripherals connected via RSTI.   

The new hardware (6535B) also required a new connector that conveniently breaks out all of the PFI lines.  The re-mapped PFI hopefully won't be a problem in this case.  

[pallen]

Today I was able to test with the hardware. 

The changes to the DAQ code worked mostly as expected.  But there is a problem I am unsure how to resolve. 

When I run the Burst (Export Clock).vi, Clock signal from PFI5 is now sent to PFI4.   

This works, but not quite as it did with the DIO-32-HS

With the previous hardware, clock signal from RTSI0 was sent to PFI2.  Clock signal was only present on PFI2 during the DAQ Read.  When the Task ended, the clock signal was gone. 

With the new hardware and changes to PFI5 and 4, the clock signal appears on PFI4 as soon as the route is switched and stays "on" all the time.  (Until the card is reset) 

I'm not sure why signal would remain on the new hardware and not the old.  But I can programmatically turn it off, so I can fix this issue. 

The issue I have not been able to solve is that we also use PFI1 as a pulse trigger line.  

Pulse trigger code appears to work.  But as soon as the Burst (Export Clock).vi is called (Using PFI5), PFI1 goes HIGH (5V) and stays there until the Task is complete.  Then it goes back to 0V. 

Really not sure why this is.  

Is there some way I can force PFI1 to stay at 0V? 

Would PFI1 be expected to go HIGH when running Burst (Export Clock).vi?     

Was really hoping these two DAQ cards were going to be compatible. 

[Kevin_Price]

Again the caveat: I don't have personal experience with the 653x family of DIO cards, so these are all educated guesses based on other DAQmx experience.

I'm surprised you seem to see an "always on" sample clock signal at PFI4.  The connection from PFI5 to PFI4 is done outside of a task context, so if PFI5 is also "always on" then it's no surprise that this is mirrored on PFI4.  The surprise would be that PFI5 is always on in the first place.  I would have expected PFI5 to show a sample clock only while the DI task is actively acquiring.   That's how many other common DAQ devices work when their sample clocks are exported to PFI pins.

I did a quick look at the spec sheet but didn't find anything that clued me in about why PFI1 might go high for the duration of one of your tasks.  I had hoped I'd find some mention of an internal that gets exported to PFI1 by default, in which case there'd be some likelihood of being programmed to export elsewhere.

-Kevin P

[pallen]

Thanks again Kevin for your feedback. 

We seem to have worked around the issues.  But I'm still not really sure why things worked the way they did. 

The original code combined Connect Terminals and a programmatic Hardware Reset in the Read SubVI.  

I suspect the Reset was prevent an error when running Connect Terminals a second time without ever disconnecting. 

What is odd is that the old DIO-32HS was either very, very quickly resetting, or ignoring the reset code.  It ran this way for many years and there was no problem with the data. 

The new 6535B was not going to give accurate data with a reset happening before every Read.  

I removed both the Reset and the Connect Terminals VI and used PFI5 to export the clock signal.  The application now works, but there are a couple of questions remaining.  

When Burst (Export Clock) to PFI5 is included in the Read Task, the clock signal appears at PFI5 the first time the Task is run and remains until the hardware is Reset.  

When Burst (Export Clock) to PFI5 is included in the Read Task, PF1 goes HIGH while the Task is running.  This was a problem for us as we were using PFI1 as an output.  

When Burst (Export Clock) to PFI5 is included in the Read Task, PFI0 does NOT go HIGH.  We were able to change our application to use this as an output instead of PFI1.  

It seems the connected hardware can live with the clock signal present all the time.  But I'm wondering if a hardware reset is the only expected way to end that signal with this hardware.  Stop Task doesn't seem to be doing it.  

[Kevin_Price]

Just spitballing and thinking out loud...

Do you *need* to use the timing mode "Burst" meant for digital handshaking?   I tried a shipping example that uses regular old "Sample Clock" timing on a simulated 6535B without error.  I added a call to DAQmx Export Signal to route the sample clock to PFI5, still without error.  (And I *did* get errors when trying other PFI pins, so their absence with PFI5 seems more significant).

Perhaps *this* method would only produce clock pulses on PFI5 while the DI task is actively acquiring?  That's how many other DAQ devices would behave with regular "Sample Clock" timing.  And it might also prevent PFI1 from going high throughout the acquisition -- maybe this is a another signal useful for certain kinds of handshaking, but not needed with a regular sample clock?

-Kevin P

[pallen]

Thanks again for your reply! 

The customer seemed happy to just live with things as they were the other day.  But at least I have some other things I can try if this becomes a problem later. 

The exported clock signal is used as timing for an external A to D converter and the timing is critical.  Fortunately, if the timing is not right, it's very obvious in the returned signals.  

They have a backlog of testing to complete.  But if I get the chance, I will put the scope back on the card and try a couple of different clock types to see what that changes.