Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

error 10123 Invalid paramID used

Hello,

I am using ComponentWorks to create a buffered event counting application in Visual Basic.
When configuring the counter to be gated on a PFI line, I get the following error: "error 10123: configuring gate properties, invalid paramID used".

I would like to use PFI31 as a gate for counter 2, and my code is posted below.
Can you help, please?

Thank you

CWCounter.Device = 1
CWCounter.NMeasurements = N
CWCounter.BufferMode = cwctrContinuous
CWCounter.GateSource = cwctrPFIGS
CWCounter.GateSignal = 31
CWCounter.Counter = 2
0 Kudos
Message 1 of 6
(3,756 Views)

I only use LabVIEW so I can't help with VB or CW syntax.  However, I do know the 660x family has limited signal routing abilities.  In general, any PFI pin that's a default Gate pin for any counter can be used as a programmed Gate signal for any other counter, but other PFI pins can't. 

In your case, PFI 31 is listed as Counter 2's default Source pin.  Try wiring and configuring for PFI 30 (pin 67), which is Counter 2's default Gate.  Hope it works!

-Kevin P.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 6
(3,744 Views)
Thank you.
Useful to know.

This is strange though. Because it seems that I can use PFI 32 with the DAQmx driver, but not with Component works and Traditional DAQ. Is this a limitation of the 6602 card? or of the driver?

Best regards,

Atacama
0 Kudos
Message 3 of 6
(3,716 Views)

Apparently, it's the driver.  In general, DAQmx makes it easier to route timing signals, handling more of the grunt-work behind the scenes.  It also has extended the range of routings allowed, such as the case you've discovered.

An old trick I used to use in traditional NI-DAQ was to explicitly route a signal up onto a RTSI line and then configure my task to use that RTSI line as a Source or Gate or whatever.   When I did it, I was typically routing a pulse train output or an analog sample clock signal.  I'm not certain, but there *may* be a way for you to do such a routing from PFI to RTSI even on an input pin.  I recall that this indirect routing allowed me to program some things I couldn't have routed directly, but I'm not sure if I ever routed an input PFI to RTSI.  I can only vouch for routing counter outputs.

If you explore your device under MAX, there's a tab or menu option somewhere to define valid and invalid routing combos.

-Kevin P.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 6
(3,713 Views)
Thank you. How can I do this rounting?
0 Kudos
Message 5 of 6
(3,692 Views)

Because your PFI pin is typically used as an input, I'm not certain that traditional NI-DAQ will allow you to route it to RTSI.  Since I only know LabVIEW, I also don't know the syntax you'd use to try.  In LabVIEW, there was a function named "Route Signal.vi" that I used, maybe you could look for a similarly named function?

Then again, why not just go ahead and use DAQmx where you've already demonstrated functionality?

-Kevin P.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 6
(3,687 Views)