Question about error -50103 and sample clock for counter

[Dongrami]

Hi, I use USB-6353 and labview program.

However, I got error message(attached below) from GPScan vi. How to fix it?

Also, I connect digital output to PFI 13 for sample clock. Is it correct? I'm not sure.... 

Can I give sample clock signal from DAQ internal system? or must need external device? 

[Kevin_Price]

Can't tell.  Anything that might be relevant is in the subvi's you didn't attach.

Please also provide a more complete description of your app & system, and talk through the thinking behind your task configuration and execution.  It's hard to know what to fix unless we know the goal you're aiming for.  (And sometimes, when you include more background info, we might recognize that you need to change your goal a bit.)

-Kevin P

[Dongrami]

Dear Kevin P

First, I want to scan the sample and get the sample signal(TTL signal?) through APD(Avalanche photon diode).

The sample stage is piezo controller which is moved by voltage. 

In GPScan.vi, there are two modes (counter and analog input mode). To get some results(scan image), I choose counter mode because APD send a TTL signal.  

So, I connected AO - piezo controller voltage / counter source - APD. 

When I ran GPScan, error -50103 occur. I think that start counter measurement part in Scan.vi has some problem... How to give trigger signal to counter? 

[Kevin_Price]

We still need the *other* key subvi called "Init" that does all the task configuration.

It would help if you could also give more description of the details of what kind of counter measurement and triggering you're trying to do, and what you expect the data to mean.  And whatever your counter is configured to do, please summarize the signals you're using to do it -- which are one-time trigger pulses, which are constant clocks, which are variable frequency pulses (such as, most likely, the signal from the APD itself).

There's a lot of ways to use counters, and the more I understand about your end goal the more likely I can give better suggestions.

-Kevin P

[Dongrami]

I try to use pulse duration mode. The details are described in the paper. 

According to buffered edge counting, when sample clock is on, source start counting of TTL signal. 

So, I'll use APD for SOURCE. 

By the way, is there any internal sample clock in DAQ(USB-6343)? or Do I have to connect external device like wave generator for sample clock? I couldn't understand sample clock exactly.  

[Kevin_Price]

Thanks.  The view from here is that the DAQmx code is kinda "clunky" and a bit ugly but seems to be substantially adequate for the intended purpose as described in the paper.

An important factor the paper fails to highlight is that the code ASSUMES you will physically wire the APD pulses to your input counters' default SOURCE PFI pin.  The "Init" code is based on that unstated assumption.  Alternately you could support flexibility for this physical wiring by feeding the 'CtrTimebaseSrc' property from a front panel DAQmx Terminal control.  [Note: not all devices will support all conceivable choices of PFI pin.  The "Device Routes" table in MAX will show green cells for the readily available routes.  Yellow cells require additional resources, and can be one of the many causes of -50103 errors.]

I would personally prefer to accomplish sync with a shared sample clock rather than the trigger-only method in the code.  Shared sample clocks are more *general* in that the method can extend sync across multiple DAQ devices in a way triggers alone cannot.  They are also more *certain*, though this is a much more subtle point. 

    CO tasks will derive their output frequency from the fastest internal timebase.  AO and AI may derive their sample clock frequency from a slower one (at least on *some* devices).  In all cases, "deriving" means "dividing down by an integer". 

    I was just in a thread where it was clear that the AO sample clock was dividing down its slower 20 MHz timebase on an M-series device where I know CO would divide down from the faster 80 MHz timebase.  Some of the *actual* frequencies you might get from dividing down an 80 MHz clock can *not* be duplicated exactly by dividing down from 20 MHz.  They can only match up exactly when the 80 MHz divisor is a multiple of 4.

    Again, it's a small and subtle issue which doesn't affect a lot of commonly-chosen round-number sample rates.  But it's lurking.

Ok, I'll move on.   Your -50103 error is about some kind of resource conflict.  It could be lots of different things.  The tasks are configured using values from GUI controls whose default values are empty in the code you posted, so there are no clues there.  Might you be specifying the same counter # more than once among your 'Pixel clock' counter output and your 'Counters' array of counter inputs?

-Kevin P