Confused about CO Pulse output.

[bhpowell]

I'm converting a Traditional DAQ application that used "Single Triggered Pulse Generation".  It seems like the appropriate DAQmx solution is to use a "CO Pulse Ticks" task.

I'm using a PXIe-6614 board, and have a signal wired to Counter 1 Source (PFI35 on the 6614).  When I see the second pulse on the Source, I want to generate a single pulse on the Counter 1 Output.  Here's what I wrote:

(Ignore the fact that I am stopping immediately after starting; this is just a test VI.)

When I run this, I get the following error. I'm not sure what to do with it.

Any advice?

[Kevin_Price]

Um, try stuff?  Cry? 😭

Seriously though, I find that error msg confusing too -- it seems to claim that a DI task is already routing its sample clock to your counter's source pin, and seemingly it's referencing the deep-inside internal pin, not the default PFI 35 terminal you can access.  And thus you're not allowed to route from PFI 35 to that same internal pin.

But that'd be a pretty weird routing that shouldn't be going on automatically even if there really *is* a DI task running, which as far as I know, there isn't.

I'd go into MAX and reset the device.  If that doesn't help, I'd remain confused but continue trying to work around the confusion until I felt like going through a full PC power down-wait-power up sequence. 

   So next I'd try changing the task config.  First I'd try using one of the other counters instead of Ctr1.  I'd probably also try using different PFI terminals too, though the error msg doesn't *seem* to suggest that as the problem.

I've never used a 6614 so maybe it has some special behavior.  But this sounds to me like a problem that ought to be cleared up (and not recur) after a device reset or a full power cycle.  

It's possible the message could be a sign of a damaged device, but I'm not at all sure that any such problem deep in the board's innards would get recognized and reported via DAQmx.  It would be conceivable that it might make a board try to configure a route and then query for success/failure.  But I don't think it would then *also* do further self-inquiry at the hardware level to figure out what routing configuration is preventing success.

   My guess is that this seems more like the kind of thing handled with some kind of routing lookup database (for a given device - what's allowed?, what other resources are needed?, are any already reserved for other purposes?) within the DAQmx driver.

   So I suppose one more drastic fall-back might be to fully uninstall and then re-install DAQmx.

-Kevin P

[bhpowell]

Spoiler alert: based on your suggestions, I got it working.  (I think.)

I did, in fact, try stuff, but my lack of confidence in how counters work probably caused me to abandon my head-banging too early. 😉

I forgot to mention that all my testing was done with simulated DAQ devices.  My PXI system doesn't have a development environment on it, so testing there means building an EXE and copying it.  Knowing what I know about how DAQmx simulation works, I believe that if configuration won't work in simulation, it won't work on the real device.

But, my bad, I should have tried it on a real 6614.  So I built and executable and copied it over--and guess what, it worked!  (Well, at least my simple VI.  Now, I have to see if it's doing the right thing when I have signals configured.  I also got an expected warning from the Stop, since it comes right after the start.)

It turns out that the failure wasn't because I was using a simulated device, but because, as you surmised, the simulated device was in a bad state.  Both of these things fixed my problem as well:

* I created a new device and tried Dev2/ctr1 and /Dev2/PFI35.

* I went into Max and reset the simulated Dev1.

Thank you for responding, posing questions, and suggesting ideas to lead me in the right direction.

[altenbach]

---

@bhpowell wrote:

It turns out that the failure wasn't because I was using a simulated device, but because, as you surmised, the simulated device was in a bad state.

---

Yes, simulated devices (even in a "good" state, whatever that means) are completely useless to develop most code while the hardware is elsewhere and there are ideas to fix that. 😉

[bhpowell]

I agree that the "random" nature of the inputs and outputs is a problem, and better control of that is a good idea.  I kudo'd it.

I do think that using simulated devices for configuration of tasks is useful, the spurious bad state notwithstanding.  I can, for example, get away with only replacing my reads and writes.  I don't have to simulate any of the configuration in my code.  At least so far.