Timestamping 4 DI + Sequential logic / PCI 6221

[Anton Mamyko]

Hello, I am stuck on the following problem, with project report due in two weeks.

(background)

I am an undergrad Mech Eng student, with the Final Year Project of measuring the position (relative to the gutters) of a bowl that is travelling (upto 30 m/s) down a tarmac lane. I am using x4 Through beam photo sensors to measure the bowl's velocity (at a point where I need to find out the position) and through trig, estimate its lateral position. Please refer to attached poster. This is a rough approximation technique, which is all that is needed for the 10 % (across the 5m width) accuracy.

I need to: time stamp each line break by the bowl (@ minimum resolution of a microsecond). AND be able to "index?" each timestamp to the respective line - because as you can see from the poster - I need to know which set of beams is broken first - to identify which side of the lane the bowl corssed ( or if it crosses the middle = highest score) 

(Labview setup so far) with the PCI 6221 x2 32-bit vounters

- Using GenDigPulseTrain-continuous.vi   to pulse @ 1Mhz from Cntr 0 to the source of Cntr 1 (physically wired)

- Separately, I use CountDigitalEventsBufferedFiniteExtClk.vi on cntr1  with, as already stated,  its source wired to the output of cntr 0 and its Sample clock(GATE )  PFI pin wired to a +5V Button. With samples per channel set to "4".

So, I run the 2 VIs , press the one button four times and the counts between presses in a 1d array on the front panel - great!

Questions (thanks to all in advance!):

- Can I wire up four PFI lines (each representing a certain through-beam photocell) to the SampleClock(Gate)?  and then "index" each PFI line to the buffer value that comes out - at that instance? ... or is there anyway around this?

- How do I bring in the Pulse generating VI into The buffered counting of events, at the moment I am running them in Parallel. I dont think they need to be wired together, just start and stop together.

Apologies for lack of proffesionalism, but this all relatively new to me.

Kindest Regards,

Anton Mamyko

[Anton Mamyko]

I have been luuking at Yuri's program here http://forums.ni.com/t5/Multifunction-DAQ/change-detection-with-timer/td-p/192292 

After hours of staring at help windows I can only see that I need to take away the analogue part of the program and figure out what "Register for Events node" does, it seems like thats the part that assigns the timestamp to a particular channel change.....

[Anton Mamyko]

I have this raw thing so far....

[Anton Mamyko]

close this down please. I obviously wasted peoples time with this thread. I have solved some of the problems already, many bugs though, for which i shall make another, more informative post.

[John_P1]

Hi Anton,

I'm surprised nobody responded to your post yet, it's a very interesting application.  It seems you are on the right track by using change detection to detect when the beams are broken.  You can sample the digital lines off of the change detection event so you should be able to use this to determine which beams were broken in which order.  Use the same change detection event to sample a counter, and you will have a relative timestamp for each of the samples.  A coulpe things that I notice looking at the implementation:

1.  The CO task isn't a problem, but it's unnecessary since you can just count the internal 80 MHz timebase instead and receive more precision.

2.  I haven't seen your implementation of the logic to determine the timestamps, but make sure to take into account the case when two beams are broken "simultaneously" (i.e. you would only have 3 samples instead of 4).

3.  Depending on what the signal looks like coming from your sensors, you might might run into the problem of picking up multiple edges each time a beam is broken.  This happens often with mechanical switches (think "bouncing"), but keep an eye out for it in your application as well.  There is no digital filtering available on the 6221 for change detection (newer X Series boards have the feature), but you should be able to handle this situation in software if you plan ahead. The symptom of this problem would be picking up duplicate samples, and so you would need to read more than 4 in order to obtain all of the data.

If I was programming this application, I would look into is using DAQmx Events to determine when the first sample becomes available (you can use the Change Detection Event or the Every N Samples Event with N=1).  When the event occurs, wait a certain amount of time to guarantee that the object has passed through all 4 beams.  Then, read back -1 samples, which will return all available data.  This way, you can handle the cases when you pick up a number of samples that is not exactly 4.

Kudos for coming this far on your own--I'll keep an eye out for a follow-up post with more details about the problems you are running into.

Best Regards,

[John_P1]

<Duplicate Post>