| Author |
|
Malibu
Regular Member
Joined: 07 July 2018
Location: Australia
Online Status: Offline
Posts: 92
|
| Posted: 25 July 2018 at 10:06am | IP Logged
|
|
|
G'day all,
Another one that's left me scratching my head on PWM output...
The story - I'm fiddling around with a small stepper motor trying to get it from REAL slow in 1/32 step mode, and ramp it up to fast in full step mode using a Pololu DRV8825 board from the MM+64 with output on PWM 1
I know from experience that stepper motors can be pretty cantankerous when first setting up, but not in this situation (well, not anymore! GRRRRRR!)
I noticed a couple of step jumps a couple of times, so I spent a couple of days trying to figure out the hardware, my code and anything else I could think of. I couldn't even be sure that I was missing steps because it all happened so fast...
But, I hooked up my PC-based DSO and ran this code (not the full code, just an extract with the relevant parts)
'A few definitions
Const mStep=48, mDir=49, mEnable=50, mM2=51, mM1=52, mM0=53
'Set the pins
setpin 49,dout
setpin 50,dout
setpin 51,dout
setpin 52,dout
setpin 53,dout
'Init the pin states
Pin(mDir)=Low
Pin(mEnable)=High
Pin(mM2)=Low
Pin(mM1)=Low
Pin(mM0)=Low
'There's a Select case here
ctrlval(cEnable)=true
print "1/32"
for i = Min to Max
pin(mM0)=High:pin(mM1)=Low:pin(mM2)=High
pwm 1,i,25
pause 10
next i
print "1/16"
for i = Min to Max
pin(mM0)=Low:pin(mM1)=Low:pin(mM2)=High
pwm 1,i,25
pause 10
next i
print "1/8"
for i = Min to Max
pin(mM0)=High:pin(mM1)=High:pin(mM2)=Low
pwm 1,i,25
pause 10
next i
print "1/4"
for i = Min to Max
pin(mM0)=Low:pin(mM1)=High:pin(mM2)=Low
pwm 1,i,25
pause 10
next i
print "1/2"
for i = Min to Max
pin(mM0)=High:pin(mM1)=Low:pin(mM2)=Low
pwm 1,i,25
pause 10
next i
print "Full"
for i = Min to Max
pin(mM0)=Low:pin(mM1)=Low:pin(mM2)=Low
pwm 1,i,25
pause 10
next i |
|
|
It took a few tries to get a capture, but this is perfect to explain what my question is...
Top trace is the voltage/signal across the current sense resistor on the DRV8825.
Bottom trace is the step input pulse from the MM.
The MM Chat window is open so I can see what stage the loop is in.
So, step mode has just gone from 1/4 to 1/2 on this capture, but right at the end of the 1/4 mode, the step pulses from the MM drop out completely (hard to see how many pulse are missing, but there's a lot). You can see by the 'patterns' on the top trace to the motor what the result is when the steps drop out.
This is a random occurance, and only seems to happen during the ramp-up part of it, and at any step mode condition, but not while there is a set speed. The stepper has been happily running for 20 minutes now on a set speed (in full step mode)
Sorry for the poor picture - it's a screen capture of a screen recording that was around 3 minutes long, and this was the clearest example on it.
So, any ideas on what I'm doing wrong this time?
John
Edit - Sorry, I should have said this is running Min=600 & Max=1200
Edited by Malibu on 25 July 2018 at 10:10am
|
| Back to Top |
|
| |
Geoffg
Guru
Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2487
|
| Posted: 25 July 2018 at 3:45pm | IP Logged
|
|
|
When running at a set speed the PWM is entirely controlled by the PIC32 hardware, so you would expect it to keep running short of a power loss. However, when you are increasing/decreasing the speed MMBasic is calculating new parameters and writing them to the PIC32 hardware registers.
The problem is that it is hard to come up with any reason why the output might stall during this. I have tested the PWM with ramp up/down many times and never seen this issue. The only cause that I can think of is that something is causing a PIC32 exception and forcing a reboot. If you have AUTORUN set your program would restart after 100ms which sort of matches your DSO trace. Checking the console output would confirm this.
If that is not the cause I recommend that you create a simple program which just ramps the speed up/down and nothing else (ie, no timers, interrupts, etc). If it continues to stall I would then be able to setup a test bed with some more sophisticated test equipment and track it down. If the stalls stop then you can hunt through your bigger program for the cause.
Geoff
|
| Back to Top |
|
| |
Malibu
Regular Member
Joined: 07 July 2018
Location: Australia
Online Status: Offline
Posts: 92
|
| Posted: 25 July 2018 at 5:17pm | IP Logged
|
|
|
Thanks Geoff 
Ok, with your advise - here's the 'new' version of the code...
Option Explicit
Const mDir=49, mEnable=50, mM2=51, mM1=52, mM0=53
Const High=1, Low=0
dim i as integer
SetPin 49,dout
SetPin 50,dout
SetPin 51,dout
SetPin 52,dout
SetPin 53,dout
Pin(mDir)=Low
Pin(mEnable)=Low
Pin(mM2)=Low
Pin(mM1)=High
Pin(mM0)=High
Print "1/8 Step"
Do
Print "Ramp Up"
For i = 50 To 2000
PWM 1,i,25
Pause 10
Next i
Print "Ramp Down"
For i = 2000 To 50 step -1
PWM 1,i,25
Pause 10
Next i
loop |
|
|
... and that's the entire code that I used.
Just trying to keep the vars & const as I used them already, but did away with the pin changes inside the code.
I've kept the uStep mode at 1/8th because it is the least likely to grate on my nerves (ie: the motor doesn't jump around the table at high or low speeds)
Here's the result -
I haven't traced the output, only the PWM signal this time.
As you say, it's around 100mS (closer to around 90mS by the looks of it), but it's still there.
As an observation, it only seems to happen:
A) On ramp up timing
B) On the lower frequencies
C) Again, with no regular position or amount of times.
On saying it's 100ms second timing, it may be happening on a shorter Hz count, but my crappy DSO setup is just missing some of the skips and they might be happening too quick to have a noticeable effect on the RPM's.
Is it possible that the "PAUSE" statements are causing the PWM to hang?
I'm at a loss on this one, so I appreciate your help...
John
Edit: I just noticed when I thought about it, the first DSO picture and this current DSO picture is around the same time duration... so I guess it can't be frequency related. hmmmmm...
Edited by Malibu on 25 July 2018 at 5:25pm
|
| Back to Top |
|
| |
Geoffg
Guru
Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2487
|
| Posted: 25 July 2018 at 5:34pm | IP Logged
|
|
|
Thanks, it seems that this is the critical code:
Do
Print "Ramp Up"
For i = 50 To 2000
PWM 1,i,25
Pause 10
Next i
Print "Ramp Down"
For i = 2000 To 50 step -1
PWM 1,i,25
Pause 10
Next i
loop |
|
|
I will set it up and try to reproduce the fault (it could be a couple of days).
BTW, what chip are you using (it looks like a 64 pin MM+) and what version of the firmware are you using?
Finally, I cannot see how the PAUSE would have anything to do with it.
Watch this space,
Geoff
|
| Back to Top |
|
| |
Volhout
Regular Member
Joined: 05 March 2018
Location: Netherlands
Online Status: Offline
Posts: 93
|
| Posted: 25 July 2018 at 6:26pm | IP Logged
|
|
|
Dear Malibu,
In the MMbasic manual I read that the PWM has 0.1% resolution, translating into 1000 (1024) steps. You are writing values from 50 to 2000. Typically you could be looking at a wrap around of the PWM compare register between 1023 and 1024..
Regards,
Volhout
__________________
If nothing goes right ... turn left
|
| Back to Top |
|
| |
Malibu
Regular Member
Joined: 07 July 2018
Location: Australia
Online Status: Offline
Posts: 92
|
| Posted: 25 July 2018 at 7:53pm | IP Logged
|
|
|
Thanks Geoff, no worries... I've done enough coding to know that something like this may take a little searching!
...and to answer your questions, I'm using MM+E64 and the upload progress says "Micromite_Plus_V5.3 Version V5.4H detected"
Quote:
| Typically you could be looking at a wrap around of the PWM compare register between 1023 and 1024.. |
|
|
It's possible, but because there's no defined time that this happens, I can't see that would be an issue (I'll play with different frequency's tomorrow and check)
I just had a thought - In the Micromite manual, it mentions "CPU Speed". Do I need to specify what the crystal frequency is?
|
| Back to Top |
|
| |
Geoffg
Guru
Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2487
|
| Posted: 25 July 2018 at 9:11pm | IP Logged
|
|
|
Malibu wrote:
| I just had a thought - In the Micromite manual, it mentions "CPU Speed". Do I need to specify what the crystal frequency is? |
|
|
No (I assume that it is 20MHz).
Malibu wrote:
| the upload progress says "Micromite_Plus_V5.3 Version V5.4H detected" |
|
|
I seem to remember this before. You are running Ver 4.04.08. The above is the MMEdit version number (not the Micromite's).
There are two ways to tell the Micromite version number:
- Reset the Micromite and check the copyright message on startup.
- Run this at the command prompt: PRINT MM.VER
Geoff
|
| Back to Top |
|
| |
Azure
Guru
Joined: 09 November 2017
Location: Australia
Online Status: Offline
Posts: 446
|
| Posted: 25 July 2018 at 11:26pm | IP Logged
|
|
|
Have you tried running the code and capturing the PWM output without the stepper board or motor connected, just the MM+64 and measure the PWM output.
How are you powering the MM+64 and the stepper board.
Are you able to monitor the MM+64 console output while it is running (to see if it is resetting and displaying the start up message)?
If I get time tomorrow I will try and run the code on my MM+64 backpack and monitor the PWM output.
Note: This approach is to try and isolate the PWM drive signal down to the minimum hardware and stil be able to reproduce the problem getting that break in output.
Edited by Azure on 26 July 2018 at 12:30am
|
| Back to Top |
|
| |
Geoffg
Guru
Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2487
|
| Posted: 26 July 2018 at 1:06am | IP Logged
|
|
|
Sorry, should have been Ver 5.04.08
|
| Back to Top |
|
| |
Malibu
Regular Member
Joined: 07 July 2018
Location: Australia
Online Status: Offline
Posts: 92
|
| Posted: 26 July 2018 at 5:49am | IP Logged
|
|
|
Quote:
| (I assume that it is 20MHz) |
|
|
It is...
Quote:
| Run this at the command prompt: PRINT MM.VER |
|
|
Excellent! I didn't know you could run commands direct from the console.
It's 5.0408
Quote:
| Have you tried ... without the stepper board or motor connected |
|
|
Many times, and in both instances. When I first tried to find this problem, I thought it was the output of the driver board so did a days worth of hardware fault-finding on the output signals without the motor connected. It also happens over 4 different boards.
Quote:
| How are you powering the MM+64 and the stepper board. |
|
|
5V to the MM from a fixed 5V lab power supply, 24V to the stepper driver from the variable part of the same supply. There's no need to supply 5V to the board, it's taken from the motor supply (8-45 Volts)
Quote:
| Are you able to monitor the MM+64 console output |
|
|
Presumably you mean the MM Chat window?
There's no indication of anything wrong there. I use that with PRINT commands to see what stage the code is at (RampUP, RampDown, etc) and the only messages I get there are what I expect.
I had a thought overnight - When I get myself fired up, I might try using SERVO on the same output and see what happens. I'll keep you posted!
Thanks everyone
John
|
| Back to Top |
|
| |
Malibu
Regular Member
Joined: 07 July 2018
Location: Australia
Online Status: Offline
Posts: 92
|
| Posted: 26 July 2018 at 6:37am | IP Logged
|
|
|
Hmmmmm... Interesting!
Here's the Servo code (The theory is that it's doing 'ALMOST' the same thing, so I should get close to the same results)
In this, there no declarations, no EXPLICIT option or anything that might tie the MM up.
Do
'Ramp Up
For i = 20 To 1000
servo 1,i,0.5
Pause 0.2
Next i
Servo 1, stop
pause 1
'Ramp Down
For i = 1000 To 20 step -1
servo 1,i,0.5
Pause 0.2
Next i
servo 1, Stop
pause 1
loop |
|
|
So, with the RAMP UP code commented out (ie: only ramping down), here's the results.
A nice and clean, sweeping waveform that makes sense...
Comment out the RAMP DOWN code, and only run the RAMP UP and here's what happens.
Looks like it's only on a frequency increase...
So, here's the full code running...
None of these DSO grabs have the DRV8825 board in place (and by default, the motor isn't running)
When I first got this glitch I was pretty sure it was a hardware and/or wiring fault, or maybe I'm losing my marbles - but I'm starting to think it's neither...
I'll keep playing and see what else I can come up with... I seriously need a COFFEE right now!! 
John
|
| Back to Top |
|
| |
Geoffg
Guru
Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2487
|
| Posted: 26 July 2018 at 8:49am | IP Logged
|
|
|
Malibu wrote:
| I didn't know you could run commands direct from the console. |
|
|
Agghh, you need to read Getting Started with the Micromite
|
| Back to Top |
|
| |
|
|
Active Topics
Memberlist
Search
Help
Login
Register
Bookmark
Email
Topic: PWM gaps?
