Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Counter/Timer device PCI-6602 output frequency.

Dear Community, 

 

I am in the process of building a HIL (Hardware in the Loop) setup to test Automotive ECU's. I am currently using Simulink Real Time R2016B to do this.

 

I need to generate a crankshaft and camshaft signal. This is a block signal with fixed amplitude and variable frequency, a so called: Hall effect sensor. 

 

To simulate a drive cycle, I wish to update the frequency 500 times per second. Up to a frequency of around 3.5 Khz. The signal amplitude should range from 0-5V. Furthermore, I need to simulate 5 different hall effect sensors to the ECU. 

 

I have narrowed down that I need the NI 6602 PCI card, since it has 8 timers, where the other cards have only 4.

 

Is it possible to generate stable engine or wheel speed signals with this hardware board?

 

Kind regards, 

Peter

0 Kudos
Message 1 of 4
(2,961 Views)

A 6602 isn't the best choice for precision control of a variable frequency output.  All frequency updates must be done via software timing.

 

The newer DAQ-STC3-based PCIe-6612 would support predefined, precise, variable frequency output with its counters, but it seems to be limited to 3 DMA channels.  You can explicitly configure 2 more counters to use interrupts, but I'm not certain interrupts will be sufficient for your app.

 

So I think I'd be inclined to recommend an PCIe X-series board (also DAQ-STC3-based) that can generate 5 lines of hardware-clocked DO.   Note that this will be more complicated to set up b/c you'll need a pretty high clock rate to give you good resolution on your output frequencies.   (Available frequencies can only be an integer divisor of the clock rate.) 

 

 

-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).
Message 2 of 4
(2,941 Views)

Kevin,

 

Thank you for your recommendations. 

I have checked the PCIe-6612 and PCIe X-series they are unfortunately not supported by the software I currently use (Simulink Real-Time on MATLAB R2017a). 

 

You mention: All frequency updates must be done via software timing.

 

Does this mean that if I need a precise frequency control, I need a very high sample rate? Currently I run the model at 10Khz or 0.0001 [s].

 

This list shows which hardware boards are supported: https://nl.mathworks.com/hardware-support/simulink-desktop-real-time.html

Would precise frequency control be possible with the 6602?

0 Kudos
Message 3 of 4
(2,912 Views)

First, the hardware support list does include several X-series boards.  You can identify them by model #'s that start PCIe-63xx -- the 4 digit number starting with 63 is NI's naming convention for X-series.

 

Second, I want to be very careful how I answer your question about precise frequency control and sample rate.   I'm not sure whether you and I are using the terminology quite the same way and this is prone to lead to confusion.   I'll break it down step by step.

 

1. Any NI board's counters are capable of generating a continuous *constant rate* pulse train that is *very* precise and repeatable, definitely in the sub-microsecond realm.

 

2. NI's boards also allow you to change a counter output frequency on-the-fly via software calls.  Again, both the "before" freq and the "after" freq will be very precise.  But typically, the time between software calls to make those change requests is *not* particularly precise.

 

3.  However, I note that you seem to be running real-time, so your software timing will be fairly deterministic and precise.  I kinda glided over that on my first reply.

   There's another subtle obstacle that may come up when changing NI counter output frequencies via software calls.  Once you've written a specific freq/duty cycle pair to a counter task, the counter must generate one full cycle using those new pulse specs before you're allowed to write a different set of pulse specs.

    So your frequency update rate must always be lower than the counter output frequency.   It's been a while since I fiddled with this, so you may find that you can manage ok simply by anticipating and ignoring the specific error that can arise when you try to update too often.  I'm not sure though -- it also might make the task error out and stop producing pulses.

   Over in LabVIEW where I do stuff, there's a property that can be queried to find out if a counter task is ready to accept a new set of pulse specs or not.  It's a "channel" property that can be selected from a hierarchical menu via "Counter Output-->General Properties-->More-->Advanced-->Ready for New Value".  I don't know if that obscure property is exposed in your API, but if so, you could always query before deciding whether to write a freq update.

 

4.  With all that stuff in mind, I'm changing my tune. I think you probably *can* accomplish this with a 6602 after all.

 

 

-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).
Message 4 of 4
(2,906 Views)