Physical channel to NI Terminal

[DennisW]

Hello,

I'm trying to use an external clock to read a digital signal. When I try to connect the clock output (a physical channel) to the DAQmx Timer source, I get the error:

"You have connected two terminals of  different types. The type of the source is DAQmx Physical Channel. The type of the sink is NI Terminal."

So, I guess I need to convert a physical channel to a NI terminal. I've tried a number of things, but haven't been able to do it.

Any suggestions?

Windows 7

Labview 2014 32-bit

DAQmx 14.1.0

NI PCI-6535

[James.M]

Please provide your code, or at least the offending section, so we can see what you're up to.

The timer input source needs to be a terminal, so you can't just attach a DAQmx phsical channel, you need to wire the specific terminal that performs the timing. This needs to be a DAQmx Terminal data type as well, so you need to create a constant or control to browse for the terminal you want.

[DennisW]

Code attached...

Note that this is the way the external device is wired to the 6535. The signal on port 0 line 0, and the clock on port 0, line 1.

Thanks for the quick response!

[James.M]

Hehe, first off your two controls are wired together in that little junction. That doesn't fix the problem, but needs to be fixed.

To fix the problem, you need to replace your Physical Channel control with a Terminal control. You can do this by making a new control, or right clicking it anf clicking Replace > I/O > DAQmx Name Controls > DAQmx Terminal.

Then, you should have to browse for the timing input with a name like "Dev1/PFI0". Check your pinout on your device to match the right channel and make sure its wired right. This naming scheme difference is the reason you need to have a different DAQmx wire type for this input.

Edit: Here's your datasheet. Check out the timing section. Looks like you'll be starting out with PFI4. I can't seem to find a connector pinout which is weird...

[DennisW]

Yes, I caught the double-wiring just after I sent it off. Guess my vision is getting hazy.

And thank you, I think you're getting me close. The thing is that the external clock is indeed wired to dev1/port0/line1 and not PFI X. I don't know why, and I can't change it. So think I do have to convert the Physical Channel to NI Terminal...

[crossrulz]

---

DennisW wrote:

And thank you, I think you're getting me close. The thing is that the external clock is indeed wired to dev1/port0/line1 and not PFI X. I don't know why, and I can't change it. So think I do have to convert the Physical Channel to NI Terminal...

---

You cannot do any clocking with the hardware through Port 0/Line 1.  You have to use PFI4, 5, or 6.  That is just the way the hardware is made.  Somebody should have read the data sheet before making the wiring decisions.

But if you absolutely cannot change your wiring, then you could just sample the two channels faster than the clock (at least twice the clock going into Port 0/Line 1).  Then you can find your data points by going through the waveforms in software.  This can be a pain and likely to need lots of processor and memory (depending of how fast you actually need to process the data).

[DennisW]

That's what I was afraid of. However, I note that the application I'm attempting to re-write (broken by the switch to Windows 7 64-bit) worked fine with the legacy driver - a single call to the DLL.  That NI should decide retroactively that "that's just the way it works" and blame those without the prescience to foresee such an eventuality, strikes me a bit high-handed.

Anyway, thanks for your input.

[James.M]

A software change wouldn't break the way that the terminals on the device work. The hardware itself has circuitry that makes those terminals work the way they do.

If it worked before, with the same wiring you're given, then the application must be doing what crossrulz said above. It just can't work as a hardware timed clock through that port, it must do a software loop rate to catch the digital switching.

Is the VI you attached the same code that used to work, or is this your own creation? If not, do you have access to the old source code?

[DennisW]

If the newer software does not support operations that legacy software did, that would indeed break the application. I don't believe there is anything in the DAQ hardware spec that stops one from wiring an external clock to the DIOA1erminal. Whoever designed my set-up (the identity of the miscreant is lost in the mists of time) obviously did not think so either.

The VI i attached was just some example DAQmx code I was trying to adapt to my situation. I do have access to the old source code, but I don't think that rounding it up and posting it would be productive.

Again, thank you for your input.

[James.M]

I understand that the update caused the problem, I'm just saying that it doesn't seem like the previous code utilized the clock signal the same way you're trying to if the wiring is to the digital input.

I'm just curious how the instrument communication was set up for this clock. Was it through DAQmx? Is the DLL that you've meantioned lost in the mists of time as well, or could you download that to fix the problem?