Home  |  Contents 

Microcontroller and PC projects
  Forum Index : Microcontroller and PC projects         Section
Subject Topic: PWM gaps? Post ReplyPost New Topic
<< Prev Page of 8 Next >>
Author
Message << Prev Topic | Next Topic >>
Malibu
Regular Member
Regular Member


Joined: 07 July 2018
Location: Australia
Online Status: Offline
Posts: 79
Posted: 26 July 2018 at 9:15am | IP Logged Quote Malibu

Quote:
Agghh, you need to read Getting Started with the Micromite

Quote:
Almost any command can be entered at the command prompt and this is often used to test a command and see how it works.


Ooops, sorry Boss... I must have missed that line among the other 6 pdf's I have open to guide me!

I stand suitably informed on 'Immediate Mode' now


Back to Top View Malibu's Profile Search for other posts by Malibu
 
panky
Guru
Guru
Avatar

Joined: 02 October 2012
Location: Australia
Online Status: Offline
Posts: 554
Posted: 26 July 2018 at 3:02pm | IP Logged Quote panky

Malibu,

I could be wrong here (it's happened before ), but in your code, the FOR ... NEXT loop time should work out at somewhere between 100 to 150 uSecs plus the PAUSE of 200uSecs for something in the region of 300 to 400uSecs total loop time.

As the maximum freq you are setting is 2000Hz, (which has a period of 500uSecs), all the frequency settings you are sending the PWM controller will be less than 1 pulse width of the frequency you are setting? So , the PWM controller is being reset each time through the loop before it even completes 1 cycle?

No idea if this would have any impact on stability but it seems a strange operation.

As an asside, executing PWM 1,2000,50 from the command line and monitoring the PWM output at the constant frequency of 2000 shows no jitter on both a 100MHz Hantek DSO5102B digital scope and a 100MHz analogue CRO (Tektronix TAS465). Tested over a range of frequencies, all withn the same result.

What I do see on the Hantek is more apparent noise and artifacts running through the display - I suspect these are sampling/quantitisation errors or noise.

panky

__________________
DonTSM1,Duinomite,CGCMM1,CGCMM2,2xDimitech,3xWWuMites,MicksMuP,Grogster1A,4xPeterMuM+,Zonker DIP-600,3xCGuKits,CGuBoard2,SnadPic100,SCBP64 & Exp100,PMMZ144,PMMZ100 .. and loving it![:D
Back to Top View panky's Profile Search for other posts by panky
 
Azure
Guru
Guru
Avatar

Joined: 09 November 2017
Location: Australia
Online Status: Offline
Posts: 435
Posted: 26 July 2018 at 3:09pm | IP Logged Quote Azure

I have managed to do some testing.

Using MM+64 LCD Backpack running 5.04.09. Running from USB power and nothing else connected to MM (except a microbridge board to communicate with the PC).

Using the following code
Quote:
Option Explicit

Dim i As integer

Print "1/8 Step"

Do
Print "Ramp Up"
For i = 50 To 2000 Step 1
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


It ramps up and down with no break in the PWM pulse at any time. Monitored through multiple ramp up/down cycles.

I checked it on my computer using bitscope and also on my Rigol 100MHz oscilloscope.

Depending on scope setting it can have some trouble displaying it as a continuous stream, it is a sweeping frequency pulse train with a varying pulse width (% of frequency).

I have tried varying the step increments (tried 1, 10, 50 and 100) making it ramp faster across the same frequency range), varying the PWM width (tried50%, 25%, 5% and 1%) and varying the pause time. All of these still had the PWM pulse running without any breaks or deadtime.

So I think the PWM output is working fine, on 5.04.09 anyway.

That I not to saying all is working properly with your stepper motor (because you know it's not).

Something that came to mind while I was staring at scope displays and pondering on the problem was that the PWM on time is varying as a percentage (25%) of the frequency. So at the low ramp speed (i=50) the pulse will be fairly long and at high speed the pulse will be much shorter (i=2000). Not sure if this has anything to do with the motor not stepping smoothly, just wanted to mention it in case it turns on a light somewhere.

Edited by Azure on 26 July 2018 at 3:11pm
Back to Top View Azure's Profile Search for other posts by Azure
 
Malibu
Regular Member
Regular Member


Joined: 07 July 2018
Location: Australia
Online Status: Offline
Posts: 79
Posted: 26 July 2018 at 4:18pm | IP Logged Quote Malibu

Hi Panky,
Quote:
the PWM controller is being reset each time through the loop

Ok, so what you're saying is that the PWM has got a new command before it's finished with the old one?
An idea that I hadn't thought of, so I'll ponder that one. It could explain why it only happens on an increase in Hz and not a decrease.

Quote:
executing PWM 1,2000,50 from the command line and monitoring the PWM output at the constant frequency of 2000 shows no jitter

Nope, no problems with fixed frequencies here either. There seems to be quite a lot of noise for me too, but I just put that down to the Hantek USB CRO

Azure,
Quote:
Using MM+64 LCD Backpack running 5.04.09. Running from USB power and nothing else connected to MM

Same as what I have at the moment, but 5.04.08 (I even took out the LCD to be sure)

Quote:
varying as a percentage (25%) of the frequency. So at the low ramp speed (i=50) the pulse will be fairly long and at high speed the pulse will be much shorter (i=2000)

Yeah, early on I was playing around with the % duty and even tried 1% at 20kHz. It was such a short signal, I think the capacitance in the circuit started to play havoc. The specs on the 8825 chip says a minimum pulse width of 1.9uS, so 25% duty should have it covered.

Quote:
It ramps up and down with no break in the PWM pulse at any time.

No worries, thanks for that confirmation... I'll need to check a little more and see what else I can come up with.
I'm sure Geoff is going to find the same thing as you, so thanks to all for your valued input...

John
Back to Top View Malibu's Profile Search for other posts by Malibu
 
Azure
Guru
Guru
Avatar

Joined: 09 November 2017
Location: Australia
Online Status: Offline
Posts: 435
Posted: 26 July 2018 at 11:14pm | IP Logged Quote Azure

I suppose it might be prudent to ask what you are trying to achieve.

The reason I ask is a lot of stepper motor drive software will count steps and have routines which provide an angle or steps to position the motor accurately. Your code seems to be a (accurately controlled rpm) free running stepper motor driver to which you may add external controls (hall sensor, rotary encoder, limit switches, etc) to aid controlling the motor. If that is not what you intend then a different motor control method is needed than using PWM or SERVO as it does not keep track of elapsed the steps.

PWM/SERVO will also not work if you need to go below their minimum frequency of 20Hz.

I have made some extracts with notes from the manuals below that you may assist in developing your code.

The most important one is the stepper controller minimum pulse width is 1.9us (0.0019ms). Calculations below show the test program creates pulses well over the minimum required.

From the stepper controller chip spec:
Max Step frequency 250KHz
Microstepping selectable from full, 1/2, 1/4, 1/8, 1/16 and 1/32 steps
Step pulse minimum 1.9us (for both high and low) and step active on rising edge
Setup time for other pins before step pulse 650ns

Note: 250KHz = 4us = 0.004ms, Theoretical max based on min pulses 2x1.9us ~ 263KHz.

From MicroMite user manual:
PWM
Frequency range 20Hz to 500KHz
Duty cycle as % of frequency accurate to 0.1% below 25KHz

Notes: 20Hz = 50,000us = 50ms, 500KHz = 2us = 0.002ms
So for test program lower and upper pwm high pulse
@ 25% duty cycle
20Hz = 50,000us = 50ms @ 25% duty = 50,000us / 4 = 12,500us = 12.5ms pulse
2KHz = 500us = 0.5ms @ 25% duty 500us / 4 = 125us = 0.125ms pulse
Both high pulses are longer than the min pulse width of 1.9us
Both low pulses will be 3 times longer the above so also longer than 1.9us min
Theoretical max PWM freq @ 25% duty is ~ 130KHz before min pulse is violated

@ 1% duty cycle
20Hz = 50,000us = 50ms @ 1% duty = 50,000us / 100 = 500us = 0.5ms pulse
2KHz = 500us = 0.5ms @ 25% duty 500us / 100 = 5us = 0.005ms pulse
Both would still be valid for stepper controller @ 1% duty cycle
End Notes:

SERVO
Frequency range 20 to 1000Hz
Pulse width in milliseconds, min 0.01ms to max 18.9ms

Notes: So max frequency may not be high enough at 1KHz.
0.01ms = 10,000us so MM min pulse width is well above stepper controller min (1.9us)
End Notes:

SETTICK
Period in ms, min 1 to max 2147483647
PULSE
Width in ms, min 0.005 (5us) at 40MHz clock speed

Notes: SETTICK min of 1ms = 1000Hz, so max freq using it will be 1KHz.
PULSE can create a pulse and it's minimum is still with the stepper controller specs.

I think there is also the option of creating a fast timer output pin and looping it back to an interrupt pin for, this culd then trigger a pulse in the interrupt routine. But that is another post altogether.
Back to Top View Azure's Profile Search for other posts by Azure
 
jimbotron
Regular Member
Regular Member


Joined: 27 November 2013
Location: Australia
Online Status: Offline
Posts: 46
Posted: 26 July 2018 at 11:42pm | IP Logged Quote jimbotron

Looks like a race condition. To increase the frequency of the PWM you reduce the value of the Period register (PR). If the new value of the PR is less than the current count the PWM counter will continue to its maximum count causing a glitch.
Imagine the PWM clock is 1MHz, duty cycle = 50% and the frequency is 100Hz. That means the PR would be set to 9,999. On each cycle the PWM counter counts up until it hits 9,999 then resets. The output is set to 1 on reset and to zero when the count hits 4,999. If the frequency is changed to 101 Hz then PR must be set to 9,900. If the PWM counter is currently at 9,950 then it has already missed the reset point and will continue until the counter overflows and returns to zero by itself resulting in a glitch. The lower the frequency the more likely you'll get a glitch.
If you are decreasing the frequency the Period Register is increased so it is impossible for the PWM counter to be higher than the Period Register.
The glitch is hard to detect, you need to set your scope to trigger in pulse mode then select a 0 pulse greater than 1ms.
The PWM hardware allows duty cycle to be changed without problems as the new duty cycle value is buffered then loaded when the counter resets. However there is no buffer for the Period register. To avoid a glitch you'd need to change the code to wait until the PWM counter resets.
Back to Top View jimbotron's Profile Search for other posts by jimbotron
 
Malibu
Regular Member
Regular Member


Joined: 07 July 2018
Location: Australia
Online Status: Offline
Posts: 79
Posted: 27 July 2018 at 6:05am | IP Logged Quote Malibu

'morning all, up early... all bleary eyed looking at some fresh ideas here.

Quote:
I suppose it might be prudent to ask what you are trying to achieve.

It's not about being prudent, it's just a damn good question to ask! (And probably something would have been easier to understand if I said first off )

Ok, it's actually an idea for a coil winder. Simple enough, just a spindle (the motor shaft) holding a bobbin that a coil of wire will be wound onto (It's actually for guitar pickups)
I went the idea of a stepper because I get better speed control at low RPM's. I started off testing with BLDC motors which are great for fast speed (12k RPM), but completely useless down low. With steppers, I've had from 1 to 1500RPM perfectly controlled. (There's torque issues as well, but that's another story!)
The idea is speed control via a pot, ramp from 0 revs to the set revs at a defined rate. The issue with steppers is that in full step mode, the motor is noisy and clunky so low speeds are run in 1/32 mode. Micromode is no good at high speed so it needs to be change up through the stepmode from 1/32 to full step at the maximum speeds. Count control will be via a single pulse encoder by using a slotted wheel read by a slotted switch. Accurate to 1 turn, but that's good enough over a wind count of 11k turns. With steppers, I can also keep tally of the amount of steps taken for each turn pulse, and if there's a large enough discrepancy, I can fire an electronic shear-pin and stop the motor dead.
The problem is that the transition between step modes can cause a tiny <clunk> in the motor which is why I've been experimenting with a sliding increase in frequencies.
It made sense to me that PWM would be the best (and programably, the easiest)way to do it.
I was just stumped on why this glitch popped up during the ramp up times...

Quote:
SETTICK
Period in ms, min 1 to max 2147483647
PULSE
Width in ms, min 0.005 (5us) at 40MHz clock speed


The two options I'm up early to try out today! I'll let you know how it goes.
(I've got 6 windows to come out and get replaced today, so it might be a while)

Quote:
If the PWM counter is currently at 9,950 then it has already missed the reset point and will continue until the counter overflows and returns to zero by itself resulting in a glitch.


Jimbo, thanks for that explanation... that makes sense now as to WHY it's happening.
I dredged up a few dusty memories of register operations in 16f84's and mentally put them into this context, and I can see the problem now! Thanks
I think half my problem is the DSO - it's ok, but woefully lacking in some areas (I need a REAL one)

I know I can get a smooth ramp with steppers, it's just finding the best way and I'll hit it hard for a while using the PULSE command (Fingers Crossed!)
Thanks to everyone for the good advise and ideas!

John
Back to Top View Malibu's Profile Search for other posts by Malibu
 
Azure
Guru
Guru
Avatar

Joined: 09 November 2017
Location: Australia
Online Status: Offline
Posts: 435
Posted: 27 July 2018 at 3:07pm | IP Logged Quote Azure

That explanation helps a lot. It clarifies a lot of what is needed.

Do you have any idea what the maximum frequency you will need for the pulses (the most steps/sec you are likely to need). This will help determine the shortest timing resolution needed and options can be considered from there.

It can be worked out by by coming up with the max coil RPM you need/want, multiplying by the motor steps per revolution and again by the microstep mode. If there are any pulleys/gearing their drive ratios need to also be included.

Quote:
I know I can get a smooth ramp with steppers, it's just finding the best way and I'll hit it hard for a while using the PULSE command (Fingers Crossed!)


The concern I mentioned was that while this is another option (also very clean and simple to do), I don't think you can use it with the settick command as it only goes up to 1KHz (which is the subject of the question above), you will proably need to explore the timer to external pin with loopback triggering an interrupt option.

Re the glitch, we need to ask Geoff how the MM changes the frequency option for the PWM command. If it is somehow doing it cleanly in conjunction with a duty cycle reload then all might be good. Running the test code above did not show any glitching. I will try and set it up again and see if I can grab some footage of the ramp up and down to post.

Edited by Azure on 27 July 2018 at 3:11pm
Back to Top View Azure's Profile Search for other posts by Azure
 
Malibu
Regular Member
Regular Member


Joined: 07 July 2018
Location: Australia
Online Status: Offline
Posts: 79
Posted: 27 July 2018 at 4:47pm | IP Logged Quote Malibu

Quote:
It can be worked out by by coming up with the max coil RPM you need/want, multiplying by the motor steps per revolution and again by the microstep mode. If there are any pulleys/gearing their drive ratios need to also be included.

Max Rpm's on the output shaft I'm looking at is around 1500 RPM... so it's 1500 div 60 * 200(PPS) gives me around 5kHz
A stepper doing 1500 RPM is near on useless because there will be little torque, so I'll probably need a pulley ratio to drive a final shaft. Hence the testing

I looked at the SETTICK command briefly and a resolution of 1mS won't be good enough I don't think, but it was a busy day so didn't have much time to play.

Quote:
Running the test code above did not show any glitching.

I was wondering earlier, what crystal frequency are you using on you MM? Maybe it has a bearing on the result.

For now, I need to settle in and relax! With 6 double glazed windows out and in, a roomful of furniture moved (yet to be moved back) I'm done for!
Is it Scotch-o-clock yet??

John
Back to Top View Malibu's Profile Search for other posts by Malibu
 
Geoffg
Guru
Guru
Avatar

Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2403
Posted: 27 July 2018 at 5:23pm | IP Logged Quote Geoffg

I can see the output stalling. Even this little program will cause it:
Do
  PWM 1, 1000, 25
  PWM 1, 1001, 25
Loop

Each time the output stalls the signal is low (never high) and each time it lasts for 84mS regardless of the PWM frequency. The occurrence appears to be random. SERVO does the same.

This is going to take some serious debugging as it involves the PIC32 hardware and its documentation (the latter is problematical). Leave it with me.

Geoff
Back to Top View Geoffg's Profile Search for other posts by Geoffg Visit Geoffg's Homepage
 
Azure
Guru
Guru
Avatar

Joined: 09 November 2017
Location: Australia
Online Status: Offline
Posts: 435
Posted: 27 July 2018 at 5:30pm | IP Logged Quote Azure

Geoffg wrote:
I can see the output stalling. Even this little program will cause it:
Do
  PWM 1, 1000, 25
  PWM 1, 1001, 25
Loop

Each time the output stalls the signal is low (never high) and each time it lasts for 84mS regardless of the PWM frequency. The occurrence appears to be random. SERVO does the same.


Geoff, I'll setup my unit again and try that code as well. That way there will be more than 1 unit to verify things on.

That probably answers my question about whether the PWM/SERVO freq is reloaded in sync with the signal pulse.

How did you determine it was stalling (ie what are you using to measure it)?
Back to Top View Azure's Profile Search for other posts by Azure
 
Geoffg
Guru
Guru
Avatar

Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2403
Posted: 27 July 2018 at 6:36pm | IP Logged Quote Geoffg

I think that the fix will be to generate a PIC32 interrupt when the timer count wraps back to zero and then update the timer's period register The code is already there for updating the SERVO pulse width. The question will be how much does this load down the CPU.

I used a digital scope running a 10mS/div timebase.
Back to Top View Geoffg's Profile Search for other posts by Geoffg Visit Geoffg's Homepage
 


<< Prev Page of 8 Next >>
In the news...
 
Post ReplyPost New Topic
Printable version Printable version
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum

Powered by Web Wiz Forums version 7.8
Copyright ©2001-2004 Web Wiz Guide

This page was generated in 0.1250 seconds.
Privacy Policy     Process times : 0, 0, 0, 0.12