05-19-2008 10:26 AM
05-20-2008 10:28 PM
05-21-2008 07:50 AM
05-22-2008 07:10 PM
Hi Nick,
I am still looking into how to make this method of using the Counter Output Event work. However, I am assuming that you are simply interested in triggering a .NET event based on some signal you input on the PFI4 line. In this case, one method that I would suggest trying would be to use the Sample Clock Event, which will trigger an event based on each sample clock. For your application, you could simply configure some task (such as CI Count Edges) and configure the timing for the task to use a sample clock. The source of the sample clock would be the PFI4 line and you would configure the sample mode to be “Hardware Timed Single Point” (you can use an arbitrary rate of 1000 and set the active edge to be rising). This way, when you trigger the PFI line, the Sample Clock Event will register and trigger your event. Let me know if this method will work for your application. Thanks,
09-18-2009 04:24 PM
Hi Daniel S...
I too ran into the same issue as the original poster. Tried using a CI Task, with a channel set to Count Edges, and setting initial count to one below terminal count, and then use CounterOutputEvent to get the software event. However, I too got error -200800.
Then I tried your suggestion...but it doesn't seem to work. The CI Task never gets any samples. Come to think of it...it's not clear what sample clock timing means for a CI Count Edges Task/Channel...I'm more surprised it doesn't give an error, rather than it doesn't work.
I'm trying other variations of this game..but am getting weary. I'm keen to know if you or anybody has a solution for this sample problem of generating a software event based on a trigger that can be explained.
Vijay Iyer
HHMI/Janelia Farm
09-18-2009 04:56 PM
Hi Vijay,
I never did get the code I posted working, and am insead using a less-than-optimal polling solution.
Sorry I cannot be of more help.
/Nick
09-18-2009 05:32 PM
Something that does sort of work is to create a CO Task (Frequency Generation), and then set it to a high sample rate and a finite number of samples (minimum of 2), and set to trigger on edge of interest. Then you can register the DoneEvent, and it will fire callback. However, I find there is more latency with Done event than with everyNSamples event, so this event will fire after the first EveryN event of the 'real' Task, if it is set to come quite soon.
This is pretty vexing.
09-18-2009 05:51 PM
Hello Vijay,
Unfortunately, the problem is that the CounterOutputEvent is only supported for a Counter Output task, and will return the -200800 error if used with another task, such as Counter input. This is not intuitive, but it is the case. In fact, the error description has since been changed from what Nick posted above, and now reads as follows:
"Event source signal specified is not supported with the Measurement Type and/or Sample Timing Type of the task."
It has been some time, but if I remember correctly, the workaround I posed allows an event to be fired based off of an external trigger occurring on the PFI line. I assumed this was the intended function since the original code was trying to register an event when a pulse was detected and caused the counter to reach terminal count. This code does the same thing, only in a different way by setting the external trigger as a sample clock and firing the SampleClockEvent when it occurs. Please see the VI below for how this is implemented.
Hope this helps,
09-18-2009 06:00 PM
Thanks very much for posting this and verifying that it does work in your hands. I am having trouble getting to work in my hands, and am concerned that perhaps it's an S series board issue. Is there any way you can verify that this does in fact work for S series boards?
09-19-2009 10:00 AM
Good and bad news.
I have in fact gotten this idea to largely work, using S series device (also works with other device types).
Only issue is that the first edge that occurs on the sample clock source does not generate an event, but then all subsequent events do (causing callback to execute each time).
This can be worked around, in my application at least, by sending an extra edge, before any of the other Tasks that wait for this edge are started, but this is not elegant to say the least.
I have seen a similar-ish issue in past, with EveryNSamples events. They fail to execute the first time. This I've pretty much resolved by calling DAQmxStopTask() after registering the event via DAQmxRegisterEveryNSamplesEvent()...strange, but it has worked reliably as a fix. Unfortunately, this doesn't seem to help in this case.
I will be curious to see if anybody else observes this issue.