Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

PWM and analog measurment for rising and falling edge of encoder signal A &B

I have been working on this problem for a quite some time and unable to figure out a solution.

Requirement.
===============
I need to measure a PWM and Analog signal from a steering Angle Sensor module for each angular position of the module. The angular position of the module is controlled
by servo controller which provides angular position feedback in terms of quadrature encoder signal.

The number of encoder pulses per revolution received from the controller is 65536 (also configurable). Thus the minimum angluar position that can be measured is
is 360/(65536*4) ~ 0.00137.

So I need to measure the PWM signal from the module for every rising and falling edge of quadrature encoder signals (A and B). So that I can have a sample for each angular position step of 0.00137deg.

I am using 6602 and 6052E cards to work with.

=====================================
How I tried to solve? (Analog signal)
=====================================
Since I was unable to find a solution to sample the analog channel for both rising and falling edges of quadrature encoder signals (A and B).
I used only quadrature encoder signal A as external sample clock for analog input task.

Please refer the attached program. (Analog signal Sampled with A Sample Clock.vi)

Though it looks to be working fine, the analog input task fails when the motor is rotated at high speeds. Please let me know how should I proceed.

==================================
How I tried to solve? (PWM signal) (Generate pulse train for PWM.vi)
==================================
Since PWM input task support only implicit daqmx timing rather than sample clock I was unable to use the above technic in case of PWM signal.

Any idea how to proceed would be of great help both for analog and PWM signal.

Thanks,
G Anil Kumar

0 Kudos
Message 1 of 10
(8,261 Views)

Hi Gopaluni,

The solution that seems the easiest to implement would require hardware that supports change detection. Change detection allows you to detect changes on multiple lines for rising and falling edges. You can see some more details here.

It seems perfectly logical that you would run into trouble with your analog input when you have high rotational speeds, as your 6052E has a maximum (aggregate) sampling rate of 333 kS/s. One signal alone produces 131,072 edges (65,536 * 2). A and B together produce 262,144 ticks in one single revolution, which is close to what you will get out of the card!

A better way to approach helping you is to have you detail what your plans are for the analog signal. Do you really need a sample for every tick, or would you be OK doing what you’ve already mentioned with using signal A as a sample clock? In other words, what is the desired end result of all your analog data? What sampling rates are you hoping to achieve on these signals?

Mark E.
Precision DC Product Support Engineer
National Instruments

0 Kudos
Message 2 of 10
(8,243 Views)
Hi Mark,
First I would like to thank you for trying to help me out in this issue,

My main requirement is to measure the analog voltage value (2 channels) that are coming out of the module. The module has a resolution of about 0.02 deg of resolution/sensitivity. To verify the characteristics of the module  I need to be capable of measuring atleast 1/10th of the resolution of the module. So my application needs to be able to measure the voltage values atleast for every 0.002 deg or less.

I would like to take 10-20 samples for every 0.002 deg rotation of the module and then take an average of the samples to get one sample. Since the module needs to be rotated from 0-400 deg (absolute angle) probably I would like to have a sufficient amount of speed not too slow or too high. It is ok if the speed is about 1/2 rpm also.


Since the encoder signal is configurable, if it is possible to sample for both rising and falling edges of both A and B signal using my current hardware I can set the number of pulses per revolution to 65536.

Then minimum angle measurable = 360/(65536*4)=0.00137 deg.

OR

If this is not possible and I can use only signal A and sample at every rising edge. I can set the number of pulses per revolution to 131,072.

The minimum angle measurable = 360/(131072) = 0.00274 deg.

Both of the above work fine to me, the later being of better resolution.

====================
To my knowledge only the second case is possible with the current hardware system. Am I right?

Considering the second case, and if suppose I would like to take 20 samples for every rising edge.

Sample rate = 131072*20 Samples/minute * 2 channels
            ~ 87382 Samples/Second

I think at this speed (1 rpm) there should be no problem with the analog signal acquisition using 6052E card. Am I right? Please correct me if I am worng.

=====================
Also, with the previously sent code I am currently able to measure one sample for every rising edge of the signal A.

What is the method to increase the number of samples measured to 10/20? Should I have to use another counter on 6602 card to generate pulses for every rising edge of signal A and then use the output of the counter as sample clock for analog input task?

======================
The next problem that shall follows is that, I need to support new modules that provide PWM signal as output.

In this case does my hardware supports measuring PWM signal at every rising of edge of signal A (131072 pulse/revolution)? Taking into consideration the measurement of PWM signal I am unable to decide the sample rate the hardware needs to support!!

If current hardware does not support the measurement of PWM, I may think to purchase a hardware that alows me to measure both analog and PWM on every rising edge and falling edge of A and B signal. Please advice!!

Any other information needed please feel free to ask.

Thanks and Regards,
G Anil Kumar
0 Kudos
Message 3 of 10
(8,217 Views)

Maybe I'm oversimplifying, but I'm getting the impression that you've gotten pretty far down the path toward a solution by taking a number of distinct reasonable steps.  And now you're kind of stuck.  Let's back up a bit and see if a *different* set of reasonable steps might work.

1. The way NI's boards handle PWM measurement, you won't be able to sample a PWM value at a constant rate.  If you measure PWM of a TTL pulse train using a counter, you'll be buffering values at whatever instants the TTL signal makes digital transitions.  Consecutive pairs of these "semiperiod" measurements will let you figure out your PWM %, provided you're careful to keep track of which one represents on time and which one represents off time.   If your PWM is an analog signal, then you can sample it at a constant rate but you won't update your calculated PWM value very often.

2. It isn't clear to me why you *need* to capture data on the encoder transitions.  Since you have encoder position resolution that is 10x the needed measurement resolution, I'd think you could just use a constant rate shared sample clock to capture your analog voltage and encoder position.  The main catch is that you'll need to sample fast enough while moving slow enough to capture points at (nearly) every 0.00137 deg of position.

3. Finally, if you need to correlate these points to PWM, you'll need to sync the tasks so that they have the same t=0 point.  I would configure the encoder task to use the AI sample clock as its own sample clock.  Then I would configure the AI task to use a digital start trigger.  I would finally configure the PWM counter task to use the same trigger signal as an "arm start" trigger.  (This is special terminology for counter input tasks).  With this method, high speed rotation will simply produce less position resolution, but your tasks won't produce errors.

-Kevin P.

P.S.  If you were starting from scratch, I'd 2nd the suggestion from Mark to consider an M-series board with change detection.  A single board could capture encoder, PWM, and analog with the approach I just described.  Plus the change detection would allow you to experiment with capturing on encoder edges as well.  Note however that capturing with change detection means that you don't have any known time information in your measurement, and it'll be difficult to correlate to the PWM.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 10
(8,213 Views)
Hi kevin,
Thanks for you reply. I was happy to receive a reply from you, I had seen you helping on this subject for quite long time on this forums.

I think I understand what you want to convey in point1. PWM signal measurement with counter uses Implicit Timing which measures the pulse width at every digital transitions of the actual PWM signal.

Coming to your question why I would like to capture data at encoder transition (Point 2).

As my requirement demands data whether voltage value (analog signal) or pulse width (PWM signal) for every step of 0.00137 deg while the module is rotating.
I am not quite sure if by using AI Sample clock of 6052E as the sample clock to encoder task (6602), can I map the data captured in 2 arrays (analog and encoder position) one-to-one based on the index.

i.e. Can I be sure that first sample in analog voltage corresponds to first sample in the encoder position in the array. Not in time but position.
===============
My requirements demands me to capture data from the module for every angular position. The data that needs to be captured may vary from simple analog voltage to pulse width of a PWM or a CAN (Controller Area Network) message that are given out by various modules.

Angle: 0, 0.00137, 0.00274, ....... 400....
Analog Voltage/Pulse Width/CAN message: x1,x2,x3,.......

so,
x1 is the voltage value/pulse width/CAN message (based on the module under test) when the module was at position 0.

similarly
X2 corresponds to 0.00137
X3 corresponds to 0.00274
etc...

I am also quite not sure about whether an M-series would be able to meet my requirement or probably I have to purchase a motion controller card.

I am unable to find what are the various limitation of each of the hardware. Please advice.

Thanks and Regards,
G Anil Kumar
0 Kudos
Message 5 of 10
(8,192 Views)
Let me suggest how I'd recommend you set things up, and we can come back to the why's as needed.
 
1. Configure your AI task to sample faster than your encoder change rate.  Aim for 3x or more if possible, depending on rotation speed and data acq capabilities.
 
2. Configure your Encoder task to use the AI sample clock as it's own sample clock.  This will sync them in time with 1 to 1 correspondence by data array index.
 
3. Configure your PWM task to use the AI sample clock as a digital "arm start" trigger.  This will sync the start of the PWM measurement to the first sample taken of AI and Encoder.  (You'll probably want to use the semi-period measurement mode.)
 
4. Start the PWM and Encoder tasks *before* starting the AI task.  Then they will be armed and ready to start measuring at the first AI sample.
 
5. Plan to do some post-processing on your data.  Your PWM task will be an array of semi-periods (high times and low times) whose cumulative sum represent the time at the end of the interval that was just measured.  The very first value is the time from the first AI sample clock until the first active edge of your PWM signal -- it's probably meaningless for figuring duty cycle, but is needed for calculating cumulative time.
   Depending on your needs, you may need to do some interpolating to create estimated PWM values at the times corresponding to AI and Encoder samples.  Then you'd have 3 equal-size arrays of data representing info correlated in time.
 
6. Your Encoder data should have recorded >1 sample at each discrete position.  If you sampled at about 3x the encoder change rate, you'll get ~3 identical Encoder values in a row before seeing a change to the next value.  Occasionally, you may see either 2 or 4.  If plotted, it'll look like a stair-stepping pattern.   Regardless, there should be enough info there to let you do the appropriate curve-fitting, smoothing, interpolating, whatever that lets you characterized the relationship between AI and Encoder.  (This would often be possible even at lower sample rates that don't catch actual data at every encoder position.  Real-life motions and analog processes are often smooth and regular enough to allow this simplification.)
 
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 10
(8,184 Views)

Sorry to hijack this tread, but I have a similar question, which can't be met with the solutions suggested previously. I am quite stuck and need to resolve this quickly. Buying hardware is not a big issue now, buying consultation time is a bit harder so I hope I can get help this way. I don't have a budget for a PXI rack, must fit expenses to reasonably priced PCI-cards/USB units.

Situation:

I need to measure and display the operation of a 4x rotational encoder with A & B pulses operated by PWM-signal.  At the moment I have 2 x 6601 units and some older low-cost DAq-card for PCI. The information required is:

- Rotational speed (rpm) at each encoder transition. (maximum 4x changes at 1khz)

- PWM at each encoder transition (frequency varies between 50Hz to 40kHz)

Optional:

- analog voltage at about 5kS/s (brake cylinder position indication +10...-10V from a laser)

So I basicly have to show a graph where X-scale shows transitions in A and B, for a maximum amount of maybe 1000,and the same amout of PWM-levels, all triggered so that a single PWM-value corresponds to a single speed value. If at all possible, the same graph should show analog voltage, which should be sampled at a minimum of 5000kS/s. And all of these should be syncronized so that you can really tell the point where. See attached picture for explanation. I took the speed input I already have to Excel and added the PWM and analog signal with Windows Paint.

Measurements:

1. Rotation speed at each transition of A and B. The way I see it, I just count semiperiod durations with 6601 into an array and count the rotational speed from this. Simple as that, and have already implemented this

2. PWM: I am lost on how to sample the PWM only when transition occurs or somehow else syncronize them with the A and B pulses. I have different systems to measure, one gives me a PWM freq of 50Hz, so with 800 transitions of A and B you get only about 50 PWM pulses, and an other system with PWM f=40kHz gives me 40 000 pulses at 800 transitions.

I tried to just extend the shorter array (PWM or speed, depending on PWM freq) to match the longer, but it wont do, the designers want to see PWM by encoder transition, as the processor calculates a new PWM value every time a pulse occurs so these should be shown together and in sync.

3. analog measurements: I have no idea on how to get 800 transitions/pwm-levels and 5000 analog results into a single graph and so that it really is syncronized so that the designer can really be sure on if the brake activation happens at the right encoder transition. If this is not possible then I have to find another way (maybe just show analog form of A and B signals).

Thanks in advance if anyone can help me!

0 Kudos
Message 7 of 10
(8,022 Views)
    General comment:  you are very likely going to need to do some software post-processing that will essentially re-sample your raw data at some desired rate.  The raw acq data samples are not going to be naturally sync'ed in time due to their nature.  Encoder edges have somewhat variable timing, PWM will have different variable timing, and analog would most naturally be collected at a constant rate.
    Two possible approaches are:  1. perform some kind of fitting or interpolation in order to re-sample signals at a chosen rate OR 2. Generate individual timescales for the encoder and PWM edges and plot all 3 data sets on an XY chart.  This only allows for a kind of "visual analysis" though.  The first approach is better for any kind of number crunching, provided you do the re-sampling well.
 
   Encoder comment: you may get better data doing period measurement rather than semi-period measurement.  Many encoders are spec'ed to give more consistent period spacing than semi-period spacing, and you may measure false artifacts with the semi-period measurement.
 
   Analog comment: it's possible to sync the analog signal to one of the other measurements by using that signal as an external sample clock.  This will give you a variable sample rate however.  Most apps are better off using a constant sample rate.
 
   PWM comment:  you claim the encoder "A & B signals are operated by PWM".   I don't understand.  Do you actually have a *motor* that's operated by PWM and which also generates A,B encoder output?
 
   Sync comment:  You'll need to share a digital trigger signal among your tasks to sync the start times.  For short collection times, you probably won't need to worry about skew due to tolerances in the on-board timebases.  But for longer collection times, you should generate and share a master timebase with one of your 6601 counters.  Then use that common timebase for all your data acq tasks.
 
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 8 of 10
(7,981 Views)

Sorry about my incomplete first post concerning my application. English is not my first language.

Application:

I am measuring an linear drive unit, where a PWM-controlled DC-motor (though a H-bridge) drives a screw up and down. Feedback from the drive is done by X4 A B encoder. The processor calculates and adjusts the PWM-level every time an interrupt is generated from A or B lines. The system uses a sort of PID-algorithm, where the relevant parameters are rotation speed (calculated from the time difference between last interrupt and the newest) and position in relation to the target position. The A and B signals are generated with a led that shines through disc that rotates with the screw and has 7 grooves cut into it, so that each rotation creates 14 state changes/signal/rotation.

Measurements: The designers want to validation their design by measuring the PWM-level after each interrupt (change of state at A or B lines) and show them at a same scale. They also want to see some analog measurements in the same graph just to make sure that some peripherals work as specified. My problems in another format: 1. How to sync PWM measurements with linear encoder state changes from 2 channels so that I can create a graph with individual state changes as X-axis with 2 plots on the Y-axis: rotational speed plot and PWM-plot? so of my application drives for 20 encoder state changes(position changes), I would get the following information:

Position  Rotational speed (rmp) PWM %

1 3000 100

2 3400 90

3 2300 70

4 2360 65%

....

19 1900 30%

20 0 0%

I really cant figure out how to measure them so that I can reliably sync or resample both signals. pwm freq ranges from 40kHz to 50Hz between different configurations so that in one measurement I get 200 PWM-cycles for 60 encoder state changes and another gives me 30 000 PWM cycles for the same lenght of movement. The designers are not content with me just resizing the shorter array to display both rmp and PWM in the same graph, the measurements MUST be synced to the encoder state changes.

 2. I also should be able to measure analog measuremets at about 100-200kS/s and display this in the same graph as the above, but I am pretty sure this cant be done, as Labview does not include a way to show different X-axis plots in the same graph (encoder/pwm measurements will have X-axis length of 1-1000 measuments while analog measurements will have >100k measurements in the X-axis.

 Is it possible to sync and display different X-axis lenghts in the same graph?

 

At the moment I have:

1 pcs E-series DAQ

1 pcs M series 6221 daq

2 pcs 6601 counter.



Message Edited by AlphaLimaIndia on 04-22-2008 01:29 AM
0 Kudos
Message 9 of 10
(7,946 Views)
    First a little philosophical discussion about PWM.  When your designers demand an instantaneous measurement of PWM that is synced to encoder changes, it is not only impossible to do such a measurement directly with your data acq hardware, it is also impossible in a certain conceptual sense.   At any given instant, digital PWM is either 0 or 100 depending on whether the digital state is low or high.
    Clearly, that's not useful information.  The information that *is* useful is to describe PWM over an *interval* of time, not at an instant.  Your data acq hardware can only perform such measurements based on the transitions of the PWM signal, which will NOT be sync'ed to the encoder transitions.  In order to produce meaningful PWM data at the encoder transition instants, you must:
   A. Control or measure the t=0 time for the PWM,  encoder, and analog tasks so you can sync them all.
   B. Perform software processing (curve fitting, interpolation, etc.) to *estimate* a PWM value at the desired instants.  If I were the designer, I'd use the PWM value for the most recently completed interval, but you'll have to work out the details with them.
   C. (Same goes for any analog measurements).
   D. You may need to have the tasks operate from a single master timebase.  Overall, this is simplest conceptually as you can start the other 3 tasks first, then when you start the timebase they are guaranteed to share the same timing.  The DAQmx programming for this is a bit more advanced, but possible.
 
    If you're comfortable with a whole lot *more* software post-processing, there's a method that might be easier to program on the hardware.  Your 6221 could capture transitions of both the encoder A,B transitions and the PWM transitions using a Digital Input task and the "change detection" capability.  You would then be able to have your analog task use the "Change Detect Event" as its sample clock.  You'd also need to have a counter measure periods between those change detection event pulses in order to create a timescale for your data.
    You would need to do a lot of careful processing of the digital data you get to find encoder transitions vs. PWM transitions, and also consider the occasional case where they may be simultaneous.
 
   When it comes to graphing, you need to be sure to use an XY graph.  Then each set of Y measurements requires you to define a corresponding set of X values.  But, yes you can have one XY plot with 70 points overlaid with another plot having 1000 points.
 
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 10 of 10
(7,935 Views)