LabVIEW
Absolute Time Pulse Generation
Well, 500 us is a known number of samples at a fixed clock rate. Depending on hardware used, you should be able to generate a task which outputs a single pulse with the appropriate length and then have it be triggered by a DAQmx Event on your other task for number of samples acquired.
Currently on phone but will edit with an example if the description isn't enough.
I think you've probably misunderstood my post, but let's go back to the start, because maybe it's not a good solution anyway (we'll see).
I'll post what I understood, and please correct me where I'm wrong:
- You have two tasks
- One input, unknown sampling frequency?
- One output, desired 500 us pulse every 1800 samples of the first task (input)
- The duration of the pulse is critical? Important, at least? And should be 500us
Is the input irregularly sampled, or are you instead measuring something else (e.g. analog input reading encoder pulses, and you want to count 1800 "high" values but you're having to acquire this as an analog signal and not on a counter)?
If it is irregularly sampled, how are you controlling the sample clock? Is it some external trigger?
Do you have access to a counter on your DAQ device? Better yet, what is your DAQ device? 🙂
@James_SS wrote:
the output is just a digital pulse (doesn't have to be at 1800 samples or for 500us- ... - but my resolution needs to be in microseconds).
Do you mean that the duration of the pulse has to be able to be varied in microsecond steps? i.e. that you want to be able to set on the front panel to have a 497us or a 501us pulse? Especially if you want to change that value at runtime, this is tricky without some specific hardware options, probably most critically a counter for the output (in addition to the fact that you're probably going to want a different counter for the input).
@James_SS wrote:
The counter will go up from 1 to 3601, and reset every time it gets the signal that its reached a full cycle. In my head I was thinking I would have a case structure which is continuously looking at the counter, and when it reaches for sample 1800, it goes true. Otherwise its false. When it goes true, it sends a signal to digital output for 500 microseconds.
When you say "the counter" - do you mean a counter in a DAQ system, or a software counter (like a shift register that you're incrementing)?
Does your encoder have a Z pulse to allow for resetting? (might not really help that much, but worth considering depending on its accuracy specifications)
How are you timing your acquisition of this input? Unless it's with a Change Detection counter (which it might be, but I'd like to confirm that if that's what you're doing) then the use of "samples" to describe "pulses" is probably misleading - here I mean that a "sample" is you reading some value (might be low, low, low, high, high, high, as 6 consecutive samples) and a "pulse" is the waveform shape that appears on your input (either via pull-up resistor and an open collector/drain output, or an actually driven line).
@James_SS wrote:
I would need to check the DAQ device that we use (am not currently able to get to it being stuck at home at this time).
If you can remember the vague number or series of the device, or some characteristics, might be we could guess a bit at its capabilities (even if some details would depend on the specific model).
For example, tabletop USB device, X or M series, starts with 63, or cRIO/cDAQ module (so C-series) analog input module with 32 lines, mixed-input/output, etc etc.
Adding a bit to cbutcher's excellent help.
1. I see a need for 2 counters working together here. One will use the variable-rate encoder signal to drive its behavior, the other will use a clock at a constant rate. You kinda can't combine both kinds of master timing sources into a single counter task.
2. Similar threads I've read and been in have typically used the encoder's Z-index pulse to mark TDC or whatever. Then they'd want to offset their pulse by some angle away from that absolute angular reference. So it's pretty important to know if you've got a Z-index and whether it's meaningful in your system.
3. I'd configure a "helper" counter for retriggerable single pulse generation. (Most any semi-modern DAQ device should support that.) Configure it with units of "Ticks" and configure your encoder A channel to be the source of those ticks. I always set Low Ticks and Initial Delay to be the same, equal to the amount of angular offset you want. High Ticks can be the minimum value of 2 Ticks. Configure the task to trigger off the encoder Z-index.
4. The 2nd counter will also need to be a retriggerable single pulse generator. It will use the 1st counter's output as its trigger with both low time and initial delay set to minimal values (probably something in the realm of 100 nanosec or less). The high time will be set to your ~500 us target.
5. I've attached a vi and a snippet to illustrate. Code requires a device that supports the "initial delay on retrigger" property, else things get more difficult.
-Kevin P
Yes it's as you say- I'd ideally be able to adjust it on the front panel by microseconds during the run.
Sorry I'm not using the correct wording probably- by counts I do just mean the samples given off by the shaft encoder every time a rotation of 0.2 degrees has been reached. With regards to the Z index I honestly don't know.
I've attached the relevant snapshots of the current set-up which may help.
I was using samples to describe in the input and the pulses to describe the absolute time-dependent output.
I believe the DAQ card being used is an NI PCIe-6323
Hi Kevin
Looks as though this code could work.. was definitely not what I'd had in mind so thanks a lot for your help! Just trying to work out a few things.
Not on this PC, but on another, we measure the speed of the engine with an analogue input and the Z index (I assume) that you refer to is offset because the shaft encoder picks up TDC just before 360 degrees (the actual TDC). Would this mean on the code that the start digital edges could be replaced with "reference digital edges"?
I have attached some code from the other PC to illustrate the input that I'd be using.
How exactly would you control the timing of this? As I'd said, I'd envisioned a case structure that sets this to go off once a certain sample number had been reached i.e. the injection/spark would go off a few degrees (or ticks in this case?) before or after the real TDC.
Also wondered why you needed a minimum value of nanoseconds for the 1st counter- this can't just be 0? Apologies for my ignorance, just trying to understand how it is working.
Thanks again.
