DAQmx "Terminal already configured" error when executing analog output with external encoder clock (error with PCIe-6323 but not with PCI-6229)

[Cemios]

Hello,

I am having trouble replacing a PCI-6229 card by a PCIe-6323 card on a specific application.

The application uses 2 encoders (ctr0 and ctr1), with the "DevX/ai/SampleClock" for synchronisation.

Here is the encoder initialization vi :

Encoder Initialization

Then, the task that reads the encoder values is runing in the backgroung. No problem so far.

And sometimes, I have to execute an analog output task to command an actuator.

This task uses DevX/PFI8 as an external clock (PFI8 is also used by the encoder ctr0). This was working fine for 10 years with PCI-6229.

But now, I had to replace the PC and the card (new reference : PCIe-6323) because the PCI-6229 is not manufactured anymore.

Here is the code for the analog output :

Here is the error with the PCIe-6323 :

Error code : -200775

Explanation :

Error -200775 occurred at PilotConfGeneAnaTrigg.vi

Possible reason(s):

Terminal has already been configured with a different Minimum Pulse Width by another task.

Device: Dev4
Terminal: PFI3
Requested Value: No Filter
Configured Value: 5,120000000E-06

Task Name: _unnamedTask<11D>

I cannot use another PFI because all the digital outputs/inputs of the card are already used. I tried to use the PFI from another card (PCIe-6321 connected with an RTSI cable to PCIe-6323) but it does not work.

I tried to remove the filter from the encoder, but then I get an error "ressource already used by another task".

I could free PFIs from the card, and wire PFI8 to a free PFI to use as an external clock but that would mean rewire digital inputs/outputs to another card, and create bridges between PFI. My client is not in my country, so I would rather find another solution if anyone can help.

Thank you very much in advance 🙂

[Kevin_Price]

I believe the problem is that you've configured digital filtering on the PFI8 terminal for the sake of your encoder acquisition.  Meanwhile the AO task does *not* want any filter on PFI8 when it uses it as a sample clock.  This seems to cause a resource conflict on your newer X-series device that you did not see on your older M-series device.

The *first* thing I'd try is to see what happens if you call DAQmx Control Task and "commit" the AO task before you configure and start the encoder tasks.  There's a chance that by changing the order of things, AO will be allowed to get direct access to PFI8 as long as you ask for it before the encoder task starts claiming board resources to do filtering.

    (Maybe this should be a simple throw-away program just to test the concept, rather than working to integrate this sequence of events into your main code.)

Another possibility to consider is that the change to an X-series card gives you access to 2 additional counters.  We can use 1 of them to try to help solve this.

The 3rd counter would generate a single pulse and be retriggerable by PFI8.  It would have a minimum low time and initial delay, something like 1 microsec or less.  We're basically aiming to make a minimal-delay repeater of the original PFI8 active edge.  (Maybe it would also need to be "committed" or started before configuring the encoder tasks?).   And then you'd have the AO task use this 3rd counter's output as its sample clock rather than using PFI8 directly.  You can reference this internal terminal with syntax like "/DevX/Ctr2InternalOutput".

-Kevin P

[Cemios]

Hello,

OK, I will try to configure the AO taks before the encoder to check if that solve the task issue.

But it won't solve all my problem.

We use PFI8 to control the speed of the analog output setpoints thanks to the encoder signal on PFI8. In that case, if I am not mistaken, the external clock (PFI8) of the analog output waits for a trigger to set the analog output.

But at the beginning, the encoder has to move in order to generate signlas and to trig the output. For that, before executing the analog output with the external clock. We execute a simple analog task with one setpoint, without clock. With that, the encoder signal starts moving, and it makes it possible then to use a task with external clock.

I hope you understand what I mean.

For the solution to use another counter, I wanted to do it at first, but unfortunately, all the digital inputs/outputs of the card are being used. So to free a counter would mean to wire digital inputs/outputs on another card. And my client is not in the same country than me. It will not have the budget to do that.

Here you can see the first step of the analog output --> Tha makes it possible to launch the movement so that the encoder generates a signal

Then we launch the task with the PFI8 external clock to control the speed of the output depending on the PFI8 triggers :

Because of that, your solution to commit the AO task before the encoder might solve the task issue, but it will not solve my functionality because I need to be able to switch the AO task from one configuration to another.

[Kevin_Price]

Ok, I follow you.  Still, I'm going to poke and prod a little at some assumptions in hopes that a different perspective might jar something loose and help you find a way to get unstuck.

1. At the outset, there's already a little imperfection built in. You have to generate an initial static AO signal to get motion started before you can switch over to the mode you want where the AO samples are clocked out based on encoder position (rather than fixed timing).  You can't control how much of that motion you miss before you're able to get the AO task going again to generate the desired output pattern.

    It seems kinda unavoidable, but I think it's worth explicitly calling it out and acknowledging it.  And it's worth weighing some other possible imperfections against it -- are the new ones making things unacceptably worse?

2. My experience has been that quadrature encoders are much less likely to need digital filtering than single channel encoders.  The nature of quadrature state cycles tends to nullify the brief phantom count change caused by a noise spike -- because the trailing edge of the spike brings the count right back where it belongs.

    So the question is, are you *sure* the digital filtering is necessary and helpful?

3. Just to be clear about my sequencing suggestion.  You would need to first generate the initial static AO to get motion started.  Then you'd reconfigure AO to the point where you "commit" but don't yet start.  This gives AO the best shot at reserving direct access to PFI8 as a sample clock.  Only after that would you configure and start the encoder task, including the attempt to use digital filtering on PFI8.  And finally you'd go back and actually start the AO task.

    The complicated back-and-forth was why I suggested trying the idea out with standalone throw away code.  The sequencing would probably be tricky to immediately integrate into the full app, and not worth trying until you had reason to expect it to help.  It's also likely to increase the amount of imperfection mentioned back in #1.

    Note: in the brief time between starting the encoder task and starting the AO task, the encoder counter can accumulate some counts worth of motion.  The first sample likely won't show a position of 0.  You may need to subtract that first value from all samples if any downstream algorithm needs to be zero-based for position.

4. There's a way to use the extra counter and the internal terminal "CtrXInternalOutput" without a need for physical rewiring.  It's a bit of a subtle trick.  You can use a DAQmx Channel property node to specify that counter's output *terminal*.  And if you specify an empty string or blank terminal constant, it will suppress trying to send the output to *any* external physical PFI terminal.  Your DI/ DO wiring doesn't need to be affected.  But your other tasks can still react to the internal signal at "CtrXInternalOutput".

Ok, there's 3 little rabbit trails to consider, let us know what you find...

-Kevin P

[Cemios]

Hi,

I am going to try and give you an update on each point that you noted 🙂

1. You are totally right, and I acknowledge that the first analog task to get the motion starting is imperfect, but as you said, it is kinda unavoidable. This project was delivered in 2011, and I had to make a computer/hardware retrofit, so I did not plan to have this kind of issues...

2. I am also ok with the fact that most of the time, we do not need digital filtering for quadrature encoders. Int this case, it was configured with a filter, so I did not want to create a new issue by changing the configuration. Too muche variables that I do not control (project is very old, and I begin to work for the company in 2014). So I am "sure" it needs filtering --> At this point, I am not sure about anything 🙂

3. I tried your sequencing :

- Generate AO to get motin started

- Commit specific AO with PFI8 external clock

- Start encoder task with filter

- Execute AO specific task

The same error appeared, but this time it appreade on the encoder task initialisation. It basically said the same thing : PFI8 is already configured with no filter by another task, so not possible to configure PFI8 with filter for the encoder.

Then I tried removing totally the Property Node that configures the filter fro the encoder task. Without the filter, the code worked (even if encoder task is before or after analog task).

So I reactivated the filter of the encoder task and I tried to find a way to configure the same filter for the analog output external clock. I tried to code a standalone application as you suggested :

With that DAQmx Timing property modification (I used the same filter value than for the encoder), I do not have any task error anymore no matter where I place the encoder task.

I will have to try and test this solution on the machine to confirm, but that seems to be a good beginning.

4. I will wait and see what happens with the solution I found before getting into that 🙂

Thanks again for your help and suggestions about the filter being the problem. Maybe it is not the cards hardware that caused this. I think it is more about the DAQmx versions.

[Kevin_Price]

3. That was a good idea, configuring the same kind of digital filter on PFI8 as a sample clock for the AO task!   I agree, if that avoids the error, no need to explore #4.

The newer X-series devices are *generally* more flexible and capable for signal routing than older MIO devices, so I would also tend to suspect this is a DAQmx issue rather than a hardware limitation.  But I really can't say for sure.

-Kevin P