Start DAQ acquisition or reading on TTL rising front

[Kevin_Price]

There must be some small, probably subtle thing that isn't quite the same in the full-up app as when you've done your piece-by-piece testing.   It's hard to give any further specific ideas without being right there in the middle of troubleshooting. 

Just be extra careful to compare and look for differences between the examples that *do* work corectly, and the full-up app code that doesn't.  Getting a pulse signal out to PFI12 in the full app seems like the 1st order of business.

-Kevin P

[scozia123]

Good Morning Kevin_Price,

I finally solved the problem, it was just that 10ns low level for the CO was simply too short, so that it was set as 0, without any trigger event at all.

Thank you for your precious help

Kind regards

[Kevin_Price]

1. Glad you've found a way to get things working

2. Nevertheless, I'm not so sure of your diagnosis.  Some things don't sound quite right.

- you refer to a 10 nanosec pulse time.  I had recommended 100 nanosec.  Was the 10 a typo in your message or was it a typo in your code?

- 10 nanosec is indeed not possible.  The minimum possible is 2 cycles of the timebase.  On your M-series board you have an 80 MHz timebase, so 2 cycles make 25 nanosec.  (2 cycles on X-series are 20 nanosec, 2 cycles on E-series are 100.  That was behind my recommendation of 100 nanosec - it'd work pretty universally on many flavors of DAQ boards.)

- configuring a counter for an illegally short time interval should either produce an error or else DAQmx will coerce it to the smallest legal value.  (I got bit a little while back when a DAQmx version change around 9.1 or so changed the behavior from coercion to error.)  If you got no output at all, it's probably because there was an error.  The error would prevent the CO task from functioning and creating an output.

   A likely take-away lesson is to *always* pay close attention to errors when troubleshooting.  They usually point you quite quickly toward the root cause.

- If I remember correctly, wiring an illegally short value into low time or high time will (now) produce an error.  In older DAQmx versions, it would coerce to the smallest legal interval instead.  I think (but am not sure) the initial delay input will *still* coerce to the smallest legal interval without throwing an error.   If so, I really have no idea why they chose to treat the  inputs in different ways.

-Kevin P

[scozia123]

Good morning,

yes, it was indeed a typo in my code and the overall output was not an error, (which I would expect), but it was just nothing, or a pulse which was too short for the camera specs.

Kind regards

[Kevin_Price]

Gotcha, too short for the camera specs makes sense.  It was about the *camera* not being triggered by a short pulse rather than the DAQmx task not creating it.

-Kevin P