Implementing pulse setup/hold time monitoring device
nyholku
Posts: 14
in Propeller 1
I need an instrument that can monitor two signals from a stepper motor controller.
Namely STEP and DIR.
For the STEP signal I want to monitor the step pulse length and time between pulses recording min and max.
For the DIR signal I want to record the minimum setup/hold time in relation to rising edge of the STEP pulse.
The STEP signal frequency is max 150 kHz and the minimum pulse length (both more or less
guaranteed by design because it is software generated) is 500 nsec.
Required accuracy is 2 usec.
I happen to have Parallax Propeller dev kit that I've never used so I figure out, maybe this is something that
could be relatively easily implemented on it.
Is this feasible?
Where should I start?
Pointers to 'closest similar' ready made project to get me started?
I've never programmed Propeller but have close to 40 years of experience in embedded stuff with
all the usual suspect CPUs working with assembler and C.
Any comments welcome.
cheers Kusti
Namely STEP and DIR.
For the STEP signal I want to monitor the step pulse length and time between pulses recording min and max.
For the DIR signal I want to record the minimum setup/hold time in relation to rising edge of the STEP pulse.
The STEP signal frequency is max 150 kHz and the minimum pulse length (both more or less
guaranteed by design because it is software generated) is 500 nsec.
Required accuracy is 2 usec.
I happen to have Parallax Propeller dev kit that I've never used so I figure out, maybe this is something that
could be relatively easily implemented on it.
Is this feasible?
Where should I start?
Pointers to 'closest similar' ready made project to get me started?
I've never programmed Propeller but have close to 40 years of experience in embedded stuff with
all the usual suspect CPUs working with assembler and C.
Any comments welcome.
cheers Kusti
Comments
Here is some sample code that records how long a signal is high and low using some hardware counters.
To convert counter values to microseconds you need to divide by 80 as the processer is running at 80 Mhz.
Here is a link to the hardware manual and also about counters.
https://parallax.com/downloads/propeller-p8x32a-documentation
Mike
Looks simple enough to get me started, I will dug out the dev kit tonight and see what happens
Funny, I was not expecting C, my mind set was spin and stuff though I had read about C on Propeller when bought the kit some years ago.
cheers Kusti
Love the propeller as it's straight forward and simple to program.
STM on the other hand is a head banger.
Mike
As above, gated counters can measure Hi or Lo times, to 12.5ns, but you may need care to capture a single pulse before the next one arrives.
One easy sanity check there, would be to allocate one COG CTRA,CTRB pair, and have one Pulse-Width gated, and the other Edge counting.
Reading both, without clearing either, will roughly indicate cases where multiple pulses were averaged.
Roughly is because you cannot capture both values on the same sysclk, nearest possible capture is 50ns, so there can be small phase creep of the two.
If you are ok with averages, you could measure many pulses in HLL.
setup/hold time is not so simple... but timers can do LOGIC A & !B etc on two pins, so that can assist :
Here you track STEP edge using wait and save gated timers (cT1,cT3 points), then when DIR has _/= since last save, wait for next STEP, and cT2-cT1 is th, and cT4-CT3 is tsu
I have some hurdles on the way but I will make a second thread on those.
Most instructions (pasm) are 4 clocks so at 80MHz thats 50ns per instruction. However you can overclock the prop. Most of Parallax P1 boards have pluggable xtals and Parallax sell (currently?) 6.25MHz crystals. That would give you 100MHz or 40ns per instruction. The waitpxx instructions can get 1 clock resolution after setup.
Then there are two counters that can be programmed in each cog.
You biggest problem will be seeing the results on a monitor. Youll need to do some averaging.
Start with something simple. Wait for the start of the step pulse, time the length, output it, wait a little for the output, and repeat.
Fakt is (not Fake), that for some reason step/direction signals exist, while it would be much better to only have quadrature signals to drive a stepper. But it is, as is is. The problem is: if there is a "dir" signal, it makes only sense to change dir of a stepper at low speed, that is, step pulses have low frequency. A good idea is the change direction in the middle of two step pulses. But in a control loop you might be forced to change direction very quickly (if for example the loop runs at 20kHz). So you create more decisions than you can execute. In this case: just do nothing, wait until you decision settles.
So my advice: before you solve the problem to measure a problem, try to eliminate the underlying problem. You could e.g. easily take the output of the stepper controller, filter any glitch and create new step/dir signals to drive your motor driver.
So for your testing, you could just use a simple program to wait for Step to go hi, read the time CNT, read the DIR pin, then wait for Step to go low, read CNT, sub the first CNT value from the new CNT value, and output the results to hub for another cog to process at its leisure, and go back to the start. You could add for the first wait to subtract its CNT from the previous CNT when STEP went low to give the time of the low part of Step. All this is easy in pasm.
Here is a simple example (untested and not complete)
However, that is easy to add to your example loop, if they configure the CTRA, CTRB to be 2-pin gated from STEP, DIR, they can also be read and MIN values collected.
Either way, Tachyon Forth itself can easily do what you want including the VGA display and even data-logging to an SD if there is some reason for that.
My goal is a device that proves to me that the stepper motor controller firmware is functioning correctly.
After each optimisation and release
So it needs to count the steps observing dir and output the motor position.
It needs to monitor the STEP pulse length and time between pulses.
It needs to monitor DIR signal in relation to the STEP signal.
More specifically:
STEP pulse needs to a have a minimum length and both the speed (inverse of
time between pulses) and acceleration (inverse of change of time between pulses)
have to be guarded agains some limit.
The DIR signal must be guarded against being too close either after or before a step pulse.
The DIR signal must be guarded against being too short.
These are goals that are not easily accomplished with off the shelf measurement devices.
I have not yet read through the responses for which I'm thankful.
I just hurried to write this clarification and will now proceed to read your thought. Thanks!
The simplest design is to sample and report each edge, but at 150kHz that gets to be a high reporting rate.
Burst capture is possible, but the P1 has limited RAM.
Since you know your targets, and are interested in limits, an alternative design would be to send Arm & Report signals, and have P1 collect the minimums.
You then collect and report
DIR_t1_min
DIR_t0_min
DIR_tsu_min
DIR_th_min
STEP_t1_min
STEP_t0_min
STEP_dt_max
Even that will be tight, as you have only ~133 PASM opcodes time budget to capture and perform all those min/max tests.
One COG could test STEP and another could test DIR & timer hardware can run gated to collect t1,t0.
Possibly a 3rd cog can manage DIR_tsu_min, DIR_th_min, STEP_dt_max ?
A 4th cog does the serial link arm/report.