Absolute Time Pulse Generation

[Kevin_Price]

Good news: the X-series 63xx boards *do* support the "initial delay on retrigger" property.

I can give some partial clarification, but am limited until I have a more complete understanding of what your equipment and application are all about.

I'm assuming that you shouldn't want to use a case structure or any other kind of software method to decide when to issue your controlled-duration pulse.   The method I'm proposing is a hardware solution that will be vastly more regular and repeatable.

   You would continue to deal with "Start Triggering" and not change over to "Reference Triggering".  I can't go through all the gory details right now, but one common theme to keep in mind is that counters really aren't quite the same kind of thing to work with as AI,AO,DI,DO.   For now, just trust me on this part.

The 100 nanosecond comment is because NI's counters require a minimum of 2 timebase cycles each for low time and high time.  On very old counters (DAQ-STC era), this equated to 100 nanosec.  Newer counters (DAQ-STC3) have a faster timebase of 100 MHz, so 2 cycles equates to 20 nanosec.   This is the one you have in your X-series board.  In-between eras (NI-TIO, DAQ-STC2) had a max timebase of 80 MHz, so 2 cycles require 25 nanosec.

   I got used to this stuff in the olden days and adopted a habit of using 100 nanosec as a universal "very short but definitely supported" time interval.

I'm assuming you have some kind of 1-per-rev pulse signal that functions similarly to a Z-index.  It acts as a reference mark for a fixed angular orientation of a rotating axis.  Once every rev, you reach that specific orientation and a pulse happens.

   I further assume that this index pulse happens somewhere *other* than the orientation where you *really* want to issue your own controlled-time pulse.

   In the code I posted, the upper config is about receiving an index pulse as a trigger, and then generating a pulse at some *specific angular offset* away from that index pulse.  The lower config is about receiving *that* pulse as a trigger and generating the time-controlled pulse.

-Kevin P

[James_SS]

Many thanks for the explanations and also for checking the capability of the card being used. 

With regards to the reference, yes I am sure there is a reference signal to denote TDC for the engine, which may or may not be this Z-impulse. In this case, the shaft encoder will pick this signal up consistently at 340.95 degrees rather than 360 on the engine (so we apply an angular offset so that the injection can be referenced against the real TDC)- but this should be easy enough to deal with as a constant. For the injection pulse that I'd like to control during a run, the timing of this needs to be versatile (although I'd keep things fairly constant i.e. 5-15 degrees before (the real) TDC).

With the code you've sent, I'm assuming the ticks will be the same as 'samples' and I will receive 3600 per cycle- so if I want to inject at 10 degrees before TDC, for example, I would configure it to sample 50 'ticks' away (5 samples per degree x 10 degrees). The encoder channel A will be my shaft encoder input-  apologies if you've already explained, but what are the purposes of the 'helper counter' input and 'trigger for helper counter'? 

[Kevin_Price]

Some of your math doesn't seem right and I'm also reluctant to use your term "samples" which normally carry a very different meaning in data acq.

That said, I'll try to summarize some more.

The purpose of the "helper counter" is to define an offset *angle* from your once-per-rev signal (the TDC sensor?) to the angular position where you'd like to generate the output pulse.  The DAQmx term "Ticks" refers to encoder edges of a particular polarity, rising by default.

   If you want to issue your pulse 10 degrees after the rising edge of your TDC pulse, you'd set the offset to a number of encoder edges that corresponds to 10 degrees.  (From what you've written, I can't tell if that'll be 50 or 100.  You'll have to work out the details on that.)

   Note: What I referred to as the "trigger for helper counter" should be the terminal where you wire the TDC sensor signal.

-Kevin P

[James_SS]

Maths should be correct- there are 2 engine rotations per cycle, so is 720 degrees overall with the 3600 'ticks', which equates to 5 per degree. 

Thanks for the explanation- I still wasn't sure whether the helper counter and the encoder channel A input would just come from the same source though, since the source of the ticks and the 'clock' are using the same 1800 pulses per revolution? 

Maybe the answer for this is the same, but I also wasn't able to see why there is an output pulse 'terminal' as well as an output pulse 'counter'..

Thanks again

[Kevin_Price]

The "counter" is the part of the board's integrated circuitry that can perform counting and timing functions.  Your board has 4 such functional components. 

The "terminal" is the place where you can connect signals to come into or out of the board.

The counter is not equal to a terminal.  Neither is equal to a clock.  A clock is a signal, a terminal is a location, a counter is a set of multi-functional circuitry.

(I understand your math now, I was translating in terms of the traditional 360 deg per revolution but I understand why you're talking in terms of 720 deg per engine cycle.)

-Kevin P

[James_SS]

Ok. So, in that case, would the counter for the helper counter used at the start and the output pulse counter for the duration come from the same counter on the board i.e. ctr0?

Unfortunately I can't test the code out until I am able to go back. I have a USB-6211 with me at home, which seems to also have counter functions... do you know if it would it be possible to test the code with this board without any sort of external encoder/pulse generator? (Otherwise I might look into purchasing an indexed encoder)

Thanks a lot

[Kevin_Price]

1. No, the "helper" counter and the "output pulse" counter need to be distinct tasks using differerent counters.  On your M-series 6211 that only has 2 counters, one will be ctr0, the other will be ctr1.

2. You *can* test this out without an encoder as an external clock, but there are some significant caveats and you'll have to do some digging in and getting creative.

   I really don't have time to give a complete step-by-step tutorial about several advanced features available in DAQmx.  But here are some "breadcrumbs" to help you get started.

   Instead of specifying a PFI pin as the timebase for the helper counter, you could specify an internal timebase.  These are *really* fast though.  So if you want a much slower signal as a timebase, you could potentially run a slowish hw-timed AI or AO task in parallel, and specify that task's sample clock as the timebase for the helper counter.

3. You can simulate the initial TDC trigger signal with a DO task.  You'll find that many DO lines share an output pin with a PFI line.  You can configure to trigger off a particular PFI line, and then toggle it with a DO task.

4. The property for "Enable Initial Delay on Retrigger" isn't supported for your at-home M-series device and will probably generate an error if you try to set it.

5. I did some experiments of my own, inspired by this thread.  Maybe the question and example code I posted can help?   Note: several things in that code are specific to X-series devices.  Mods would be needed to run under M-series.  Notably, you only have 2 counters available, the 2 posted vi's use a total of 4.

-Kevin P

[James_SS]

Ok that's a shame that this card won't be able to perform the retrigger.

To update you, I am looking to get a separate card and PC alone to do the injection for the engine. Hopefully this will simplify things because it can run on time alone and won't affect anything else running at the same time which is dependent on the shaft encoder signal.

For this I simply need to detect the Z index, count a certain number of pulses after this, then set the pin (high) for a set duration, then return it to low again until the next iteration. This seems fairly simple, do you see any potential problems with doing this? 

[Kevin_Price]

I really think you're drawing several wrong conclusions in your last post.  My comments in place in red.

---

Ok that's a shame that this card won't be able to perform the retrigger.  It *can* perform retriggering, it just can't *directly* run the code I linked.  It also doesn't support the "enable initial delay on retrigger" property, but you don't need it.  All you need to do is set your low ticks and initial delay equal to one another in the first place.

To update you, I am looking to get a separate card and PC alone to do the injection for the engine. Hopefully this will simplify things because it can run on time alone and won't affect anything else running at the same time which is dependent on the shaft encoder signal.  This sounds like the wrong approach.  I honestly don't see how a 2nd card & PC are supposed to make things better.  I *can* foresee significant extra complications maintaining sync.  If you follow the advice in this thread, just stick with your 1 original PC.  The pulse tasks are completely set up in hardware -- once started, they will not *in any way* interfere with code running on the PC.

For this I simply need to detect the Z index, count a certain number of pulses after this, then set the pin (high) for a set duration, then return it to low again until the next iteration. This seems fairly simple, do you see any potential problems with doing this?   What, do you mean any problems OTHER THAN THIS ENTIRE THREAD which has been focused on avoiding software polling and reaction times by using a hardware-timed approach?!?    

---

Many of my comments in msg #17 are specifically aimed at how you could still test things out while using only your USB-6211 device.  Have you tried these things out?   Did you get stuck?   Where?   I recognize that some of the workarounds I mention are not trivial common knowledge, I just don't have the time to write up a whole detailed tutorial.

-Kevin P

[James_SS]

Ok apologies, I had the impression that one of the reasons for keeping things hardware based was because a software based approach would interfere with other applications running simultaneously on the PC/card.

In your post from the other thread, you seemed to be having problems making changes on the fly? Were you able to find the cause for this or still investigating?

I have now ordered an indexed encoder to try and test this VI to avoid the need for generating some sort of dummy signal from the card itself, so will let you know how that goes.

On a slight side note, an improvement to the current set-up would be to replace the shaft encoder with one that can measure more resolutely i.e. 0.04 CAD rather than 0.2. Do you know if the labview card I use in the lab (the 6323) would be able to cope with 10,000 pulses per revolution (right now it is receiving 1800 ppr)? From its spec sheet I can see the analogue input is limited to 250kS/s which is fine for the temperature and other data we collect on that PC at least. 

Thanks again