May I change counter parameter while it is counting?

[RobertoBozzolo]

Hi all.

I'm using CVI 7.1 and traditional daq with a PCI-6601 board to perform simple event counting to count delays on some tested devices

For my application I need to change the type of counting from ungated to gated while the counter is running: is it possible?

My application is configured this way:

GPCTR_Set_Application (1, ND_COUNTER_0, ND_SIMPLE_EVENT_CNT);
GPCTR_Change_Parameter (1, ND_COUNTER_0, ND_SOURCE, ND_INTERNAL_100_KHZ);
GPCTR_Control (1, ND_COUNTER_0, ND_PROGRAM);

Now, while the counter is running I need to follow on counting only if the gate signal is high. If I simply use

GPCTR_Change_Parameter (1, ND_COUNTER_0, ND_GATE, ND_PFI_38);
I receive the error that "The specified resource is already armed", so I tried with

GPCTR_Control (1, ND_COUNTER_0, ND_DISARM);
GPCTR_Change_Parameter (1, ND_COUNTER_0, ND_GATE, ND_PFI_38);
GPCTR_Control (1, ND_COUNTER_0, ND_ARM);
but the counter continues counting regardless the state of the gate signal. That's why my question: how can I perform this task?

(Note: if configured from start for gated counting, the counter operates regularly based on gate state)

[Kevin_Price]

I don't think that kind of configuration can be changed while the task is running.  I also can't comment on the DAQ calls as I only use LabVIEW.

However, it seems like there's other ways to accomplish the same kind of effect.  For example, set up your main counter for gated counting all the time.  But now instead of wiring an external signal directly to the Gate input do something like:

- wire the external signal to a digital input.  Poll that digital value to determine in software when gating should be happening.

- generate a digital output to act as the gating signal.  Wire this output to the counter gate.

-Kevin P.

[RobertoBozzolo]

Hi Kevin, thanks for your answer. Unfortunately I don't think your solution is feasible in my application since I am using 6601 card to precisely count up intervals with a precision of 1/100th of second: I cannot rely on software performance for such a precision (if I could, maybe I had no need of a counter card!   )

At present I modified my application to act this way: when I need to change counter configuration
1. I read counter value and store it in memory
2. I stop the counter and reprogram it for hated counting
3. I restart the counter
This does not seem to introduce a significant loss in time measurement, but if I could rearrange counter action without need to stop it and restart I would be more happy.

[RobertoBozzolo]

Sorry, I forgot one step above:

4. After restarting the counter, total time is time measured + time saved in step 1

[Kevin_Price]

Unfortunately I don't think your solution is feasible in my application since I am using 6601 card to precisely count up intervals with a precision of 1/100th of second: I cannot rely on software performance for such a precision

I guess I don't understand how software performance is more of an issue with the DIO method I suggested than with the ideal case you want.  Here's my understanding:

Ideal Method (not actually possible):

1. Software monitors signals and/or program status until conditions show that it's time to switch between gated and ungated modes.

2. A software call is made to change the counter mode from gated to ungated counting on-the-fly without stopping the counter.

My suggestion (actually possible):

1. Software monitors signals and/or program status until conditions show that it's time to switch between gated and ungated modes.

2. A software call is made to write a DIO bit to change the state of the counter's gate on-the-fly without stopping the counter.

It seems that both methods rely on a software-based decision in step 1.  That's the source of the software uncertainty, and it seems like it'd be the same either way...

-Kevin P.

[RobertoBozzolo]

Kevin, in my application I am monitoring a long-lasting process (approx. 45 seconds long) in which I must measure the time a contact is on. 6601 card is dedicated to measure this time: the contact is used as the gate signal of the counter so that time measurement is exactly related to the process being surveyed. The problem is that during part of this process I cannot be connected to the actual contact, so I cannot use its state as the gating signal during all time.

I was hoping that I could change counter configuration on the fly so that I can start counting based on the gate, switch to ungated counting while I cannot survey the contact and switch back to gated at the end of the interval, when I can use again the contact as counter gate.

In the meanwhile I am monitoring some other parts of the process and acquiring measures on serial (that is intrinsically "slow") devices: due to this sum of processes going on inside the computer, I cannot rely of my program being enough fast as to monitor the state of the DUT and mirror it in a gating signal.

I have tested my solution to sum up partial timer counts and found it not so easy to manage so I decided to introduce a little hardware modification in the measuring system and OR the gating signal with a digital output of the 6601: I can manage in the software to drive this signal with significant margin on actual phenomenon, so that I am now using the counter always in gated mode. This solution is more or less in the way of your last answer seem we arrived at it contemporarily!