Delay for retriggerable finite counter

[lyzhab]

Hello I'm new to labview and using a pcie-6323 and had some clock issues. What I am trying to do is use a counter to generate a clock (frame clock in the figure), and based on it to trigger and generate another "Camera trigger clock" to trigger a camera. The Camera trigger clock is a finite, retriggerable counter. This is an code writtern by lab alumni. Previously it worked very well.

Recently I would like to add a constant delay for all the Camera trigger clock pulses- not just the initial one. When I saw this sample, https://decibel.ni.com/content/docs/DOC-10685, I tried to add the start.delay to my code, like the following figure. But once I run the program, I got a 200452 error code and the program needs to be closed.

I also saw this link mentioned to use Enable Initial Delay On Retrigger., http://digital.ni.com/public.nsf/allkb/204538A044431C9B86257377004EB952 . But I tried to put it in several different positions, e.g. after the Creat Channel vi, after the timing vi, after the start trigger vi and after the trigger property node, I still got the same error problem.

I think the pcie-6323 should be with the STC3 Timing Engine, http://www.ni.com/pdf/manuals/370784g.pdf , so I don't know why I had the 200452 error. I wonder if there is a simple way to solve this problem and achieve my goal. I saw some examples used two counters to do this delay, but I guess there should be an easier way? If someone can show me a figure or sample vi, it would be very helpful. I really appreciate it!

Thanks a lot!

[Bob_Schor]

You need to attach the actual VI, not a picture of a part of the VI.  With the code in hand, we can edit it, move pieces around, test it out, and see what "makes it tick".  Once we understand it, we can (maybe) help you with it.  Otherwise, you are making us work much harder than we should (and not paying all that well, to boot ... 

Bob Schor

[Alexander_Sobolev · Accepted solution]

Start delay is a wrong one, use Initial delay (input in create virtual channel - original 0.0008 in camera trigger clock task). Enable initial delay on retrigger applies to it. 

Another way is to use frame clock pulse width (duty cycle) as delay control - trigger one task on rising edge, and another - on falling edge. 

[Kevin_Price · Accepted solution]

Playing the "what changed?" game:

1. You described adding a property node to enable initial delay on retrigger

2. You also wired in values to define a Start Trigger delay in units of seconds

A quick experiment here on a simulated X-series devices suggests that the real problem is item #2.  That particular property doesn't apply to counter output tasks because anything related to timing or delay is already fully specified by the low time / high time pair, the initial delay, and the property set in #1 above.

Intuitively, it was reasonable for you to think you needed to define the properties in #2, but in reality it appears you can't.  Try it on your real hardware to be sure, but I think it'll work when you don't write those properties.  To precisely define the delay after the trigger, you'll need to use the 'Initial Delay' pulse parameter (as well as item #1 above).

-Kevin P

[lyzhab]

Hi guys, thank you very much! I did find the error came from the usage of start.delay when I used the debug mode. Now when I remove it, the program works very well! I saw another post in this forum mentioned that the start.delay can only be used for AI (couldn't find it now). I was confused as the guys who post because I couldn't find related useful information in the labview help. But anyway, your explain made sense to me.

I attached my code here just in case some one also had the same problem.