LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Delaying Digital Output

Hi there

 

Was thinking this would be very simple, but I am trying to install a 1-2ms delay on a digital output pulse based on an external trigger and clock. The current setup works by creating a pulse for a set time and duration based on an array of 3600 samples per cycle. What I was aiming to do was delay this pulse by a unit of time from when I receive a digital edge of the external trigger (the trigger is the Z index of an encoder, the clock is the A input). I thought I could simply use the trigger property node and install a delay time that way, but clearly I am doing something wrong.

I have attached the setup as it is, currently using a start digital edge trigger but, as I said, converting this to a node didn't seem to work, as I received no output. Using the property node with only the task, source and type of trigger properties installed gave me an output that was all over the place. Any help would be appreciated, and if I can provide any further information that would be useful please let me know.

 

Cheers

 

Thanks in advance

0 Kudos
Message 1 of 19
(1,348 Views)

The snapshot you just posted looks an awful lot like the code you posted early on in a thread from the better part of a year ago.  Much of the rest of that extensive thread was me steering you away from DO and toward the use of counters.   It sounded like you were on board, but now it looks like you reverted back to DO.

 

I'd suggest you go back and review that thread, then implement your delayed pulse with a counter task.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 19
(1,316 Views)

Hi Kevin

 

Ah no this is not for the same thing. The previous code that you helped me with was for an injection system (which worked pretty much as it was when you sent it to me so thanks a lot for that!), this is for a valve. It doesn't need to be quite so precise as the injector, so I am still using this output purely based on the basis of the shaft encoder. This was working well, but I am now finding that there is a period in the engine cycle where it doesn't open. Basically this is because there is a limit of 3600 samples (720 degrees) per cycle and, to get the valve to open the pulse needs to be sent for about 60 crank angle degrees. But because there is a reset on the number of samples, if I want to sample at 700CAD for example, it will only ever open for 20CAD, even if I set the duration to 100CAD. Because this region is very important within the cycle, I was imagining it would be straightforward for the code to wait about 2ms (about 20CAD) to basically shift the opening times a bit later to within the range I am interested in.

0 Kudos
Message 3 of 19
(1,296 Views)

It isn't clear to me what you mean by, "reset on the number of samples", but it sounds like an unnecessary self-imposed constraint.   How and why is this a limitation?

 

Also, why NOT approach it with a counter pulse like the other situation?  It seems like it'd be more straightforward.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 19
(1,287 Views)

This is just because the Z index is used to determine a full cycle (every 720 degrees or 3600 samples), so that is needed so that the valve opens at the same time every cycle. The array I use to dictate the output duration is simply there to set a pulse high for a range based off those samples i.e. the 2000-2200 samples might need to be high.

 

I had wanted to change this to the same system as the injector, but had assumed that I wasn't able to use the same counters for 2 different tasks? Would the card be able to do this? (6323) I know it's not a high speed card either so thought there might be interference in doing this.

0 Kudos
Message 5 of 19
(1,275 Views)

In that other thread, only 2 counters were used.  X-series boards like the 6323 have 4 available, and they can all run independently of one another.   So you should be able to use 1 of the 2 still available.

 

What's even better is that when you configure a counter to generate a triggered pulse all you have to do is start the task.  All the rest happens in the hardware, no data transfer or CPU usage.

 

Like one of the pulse generators in the other thread, you can configure it to use an encoder channel as its source of "Ticks" so that the pulse duration depends directly on angle rather than time.

 

With that direct sync to the encoder, I'd be inclined to make a continuous pulse train.  Set 'High Ticks' for the pulse duration you want (in terms of angle).  Set 'Low Ticks' = 3600 - 'High Ticks'.   And then use 'initial delay' to set your original angular offset from the trigger signal.  After that first initial delay, it'll keep pulsing at the exact same angle range indefinitely.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 19
(1,269 Views)

Using an encoder channel would be ideal with being able to alter the settings on the fly using angle, whereas using time units would be more arbitrary for this application especially with engine speeds varying. Unfortunately I am not able to try any of this out just now with being in lockdown again and not having an encoder and the usb card I had access to before, so it is difficult to get my head round the continuous pulse train with the settings you mention. I know you can configure a counter input as an angular encoder, which is presumably how I can operate in terms of angle? In the coming days I can try some things out.

With 2 counters spare though I'd consider using the code as before (where the timing of the pulse is dictated by ticks, and the duration by time)? 

 

Cheers

0 Kudos
Message 7 of 19
(1,240 Views)

The example I gave in the prior linked thread set up a 1st counter to pulse based on "Ticks", triggering a 2nd counter to pulse based on Time.  Those were the requirements over in that thread.

 

Here you'd need only 1 counter, the one based on Ticks.  Then you can more directly set both the pulse start position *and* duration in terms of angle.

 

The other difference here is that you may want a start position and duration that would overlap the next TDC triggering position.  A retriggering single pulse would miss that triggering opportunity.  That's why I'm now suggesting that you run a continuous pulse train that's triggered just once.  'Initial Delay' is used by the counter task only for the very first pulse.  Here we use it to set the angular offset from TDC where the pulse will start.  'High Ticks' sets the pulse duration in terms of angle.

   All further pulse cycles after the first one will then alternate between 'Low Ticks' and 'High Ticks'.   So if you get 3600 Ticks per cycle, you'd want to set 'Low Ticks' = 3600 -  'High Ticks'.

 

Make more sense now?

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 8 of 19
(1,223 Views)

Yes thanks a lot! I see what you mean. That was the issue before with the pulse duration overlapping with the subsequent Z index and thus preventing it from completing. I did quickly manage to set up the double counter system just now and that seems to have worked. I do get what you mean though with using just the counter for the ticks and using the number of ticks per cycle to basically determine how often it triggers. 

 

For now I will stick with the original injector code you gave me as it does seem to function well and I have installed the necessary wiring. A further factor I need to consider though is that I don't really want this valve to open every cycle, as it will overheat, and the previous setup allowed the sample to open every few cycles (in this case 3). Can I perhaps use a digital pattern as opposed to a digital edge to get the counter to only trigger the pulse generation once it has received 3 digital edges? I remember from our previous discussions that using a software counter or loop will massively slow things down and render the code useless, so wondered what you'd suggest here?

 

Many thanks

0 Kudos
Message 9 of 19
(1,213 Views)

Well, if you only want to do this every 3 cycles, then you could switch over to the 1-counter approach I was just describing, but set 'Low Ticks' = (3*3600) - 'High Ticks'.  Pretty simple if you approach it that way with a continuous pulse train whose timing is hardware-driven by the encoder.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 10 of 19
(1,206 Views)