Tracking where I am in between TTL pulses

[Signal_G]

Greetings.  I have a little Labview experience but very little with counters.  I have a PCI-6602 card with a CB-68LP connector block.  I have used up 7 of the 8 channels counting events so I have one channel left. 

What I have is a Z pulse that is followed be four events and then another Z pulse.  I know the point in the cycle at which each of these events occurs.  I need to write in my program which event is occuring. 

I apologize for the confusion.  It's difficult to explain.

The ideal situation for me is that if the Z pulse is a 360 degree cycle I could track in my program if I am in the first, second, third, or fourth quarter of the cycle between Z pulses.  I know that sounds almost impossible since my Z pulse can change. 

For what it's worth, I CAN run one of the events in a separate TTL input if that helps me. 

I have been trying to just reference the Z pulse to a timebase, then a little math would get it done for me but I don't have a full knowledge of counter/timers. 

Any help would be appreciated.  Sorry for the confusing post.

Dave B

[lady_engineer]

Hi Dave,

I must admit, I am confused as to what you are trying to do.  It almost sounds like you are trying to use the signal on Z as your timebase.  I am not sure this can be done.  Could you explain more what you want from this signal?  Are you tring to count position?  Or would you like the frequency or period of the signal?

[Signal_G]

I found another way to get it done.  Thanks for your help.

[Mathan]

Hai Dave,

Could you please show the another way how u solved, so that others visiting this thread will get benefits.

Thanks,

Mathan

[Signal_G]

I did sort of a work around.  I had basically an engine with four sparks timed by a Z pulse.  I wanted to know which spark was occuring without having to burn up four channels on my nearly full counter card so my goal was to track the Z and apply the math of my known timing cycle to the Z timing so I'd know what spark was supposed to be happening at a given time. 

There were a lot of flaws in that plan including that my program wouldn't know the Z pulse period until AFTER it occured.  I'm still waiting for NI to release their "read future data.vi".  Hopefully it will be in the "Time Travel.llb". release.

I realized that my timing card has a bunch of DIO's that I could use for the sparks.  I did a mock up and it works so far.  If I keep this going I'll have a wire to every terminal of my CB-68LP. 

One thing I have learned in this year of Labview education is that sometimes your best solution to a difficult task is to come at it from a different angle.

I don't know if this would ever help anyone.  I guess if you've maxxed out your counter card it could.

Cheers.

Message Edited by RZTC Dave on 07-10-2008 07:28 AM

[Kevin_Price]

Friendly tip: if you're reading in the TTL spark timing signals with DIO inputs, you're relying on software timing to characterize things.  There's a fair chance this may come back to bite you again, especially as you get into higher engine speeds or more real-time processing.

Suggestion 1: If you monitor the 360 degree timing from your Z-index signal, it's true that you'll get (slightly) stale measurement data from it.  However, your engine probably doesn't change speed by many 100's of RPM in a single revolution either.  So the stale measurement is probably a pretty good approximation.  Probably usually better than what you can determine using software timing.

Suggestion 2: Check out the M-series boards with either 8 or 32 "correlated DIO" lines.  These are capable of making hardware-timed measurements of digital input signals.

-Kevin P.

[Signal_G]

We usually don't run much higher than 40hz.  Do you think I'll have problems?

Thanks

[Signal_G]

Kevin...forgot to ask...any clues on how I could time from the most recent Z-pulse?  Based on my current program construction, if I time from the Z I'd need to set it to execute one of four cases during each period of the cycle. 

The first 90 degress case 3 would be active.  The next 90 case 4, the next 90 case 2, the next 90 case 1.  I'd feel safer with that arrangement if I could figure out how to make it happen.  I'm still fairly new to timing cards.  This has been a great education.

Thanks Kevin...

[Kevin_Price]

1. At only 40 Hz, your software-timed DIO plan should be able to work pretty well.  You won't have 100% assurance, but I'd venture that you can probably do better than 99%.

2. Questions to help me understand better.

  A. What kind of timing events are being counted by the other 7 counters?  Do you have encoder-like position signals available?

  B. You speak of case 3 being active during the 1st 90 degrees (and other cases during other 90 deg segments).  What exactly do you mean?  Are these software case structure cases containing code that needs to run exactly during certain 90 deg segments?  If so, what kind of code is running there?

  C. What's the big picture here?  Why do you need to know which 90 deg segment you're in?  Are you generating actuation control signals (like valves)?  What are the timing requirements -- not just speed, but also jitter, i.e., consistency?

  D. Do you have budget available for something like a 6221?  Sometimes a little extra hardware can save you from some complex and time-consuming software development and debugging.  Your answers to the other questions might point toward the usefulness of additional data acq hardware...

-Kevin P.

[Signal_G]

I am measuring the speed of an event.  To keep it simple, I am measuring the edge separation between TTL pulses.  As the event moves through a cylinder it sets off probes that will send my system a 5 volt, TTL pulse.  Knowing the time between the event passing probe 1 and probe 2 will tell me the speed of the wave.  I have 7 probes in each of 4 tubes.  Because we are running at 40 hz or less my boss would like to run all seven probes for each tube together.  This way we are writing a smaller amount of data and only using a 7 channels of a counter card rather than 28. 

So probe 1 in each tube will generate a pulse to the same channel.

To determine which tube I'm in I am referencing the spark for each tube.  My plan is that when the spark for tube 1 occurs it initiates case #1.  Spark 2 will make case 2 true, etc for 3 and 4.  Each case performs the exact same reading on the exact same channels.  Since not all tubes are exactly the same, each case will have custom formatting for that tube. 

In each of these cases I am measuring the time between probes to figure speed.  We can run one tube up to all four.  My program should work for all without any intervention from the user since unused tubes will never send their corresponding case structures to true. 

Using the 90 degrees per was when I was considering using the Z (timing) pulse to determine which tube is active.  Now that I'm using sparks for each tube that is much simpler (I hope).  The sparks coming into the DIO (adjusted to give me a clean TTL) will activate the case for their corresponding tube. 

The 6221 is pretty affordable but I think this should work with what I have.  If it doesn't I could sell them on another piece of hardware. 

Do you think this will work?

Thanks

Dave