PDA

View Full Version : screening / glitchy operation - sanity check



dsc
24-11-2013, 02:28 PM
I'm using a HBS86 + 8Nm motor with a 68VDC supply and driving this with a PIC based uC system via a PWM output. I've coded up a ramp start function, which generates a PWM with a variable frequency to ramp the motor up from 60RPM to 240RPM. On the scope all looks good, on the motor it works, but I can hear the motor sometimes glitching, as if it's loosing steps. I've even seen a 'positioning error' once on the driver, it needed a power cycle afterwards to get things going again. I'm using screened cables, but currently haven't got the screens connected, so I thought maybe this is the reason. Here's how it's connected:

10858

I've numbered the screens, should all 1-3 be connected to 4 - E(arth) / chassis? I'm guessing I need to put a link between the E(arth) terminal and the chassis as well to get the whole chassis earthed?

Thanks in advance for any suggestions.

Regards,
dsc.

Jonathan
24-11-2013, 02:55 PM
This is most likely to be a software problem. In what language have you programmed the PIC? If you don't mind posting the code then I'll have a look at it for you. I expect it'll be the PIC not outputting pulses with a smoothly changing frequency, e.g:
Instead of,
|_|_|_|__|___|____|____|____| ...
Something like,
_|_|_|____|__|___|____|____|____| ...

This can be caused by things like stopping the output (briefly) whilst calculating the period which would introduce an additional delay. Are you using the hardware PWM module, or doing it 'manually' with a loop?

dsc
24-11-2013, 03:12 PM
Thanks Jonathan, on the scope it looks like the top example from your reply. I can post a scope recording if I figure out how to record with the fancy model I've borrowed from work. The function for the slow ramp is below, coded in C:

void slow_ramp(void)
{
//PWM code for slow ramp start
CCPR1L = 0b00000010; //set to 2, so pulse width is 2 x 16 = 32 with 16 prescaler

while (PR2 != 18) //ramp up speed slowly from 60RPM [PR2 = 77] to 240RPM [PR2 = 18]
{
while (TMR2IF == 0) {} //wait for overflow
PR2--;
__delay_ms(5);
}
}

Using the hardware PWM module on the PIC.

Regards,
dsc.

EddyCurrent
24-11-2013, 06:56 PM
I've numbered the screens, should all 1-3 be connected to 4 - E(arth) / chassis? I'm guessing I need to put a link between the E(arth) terminal and the chassis as well to get the whole chassis earthed?

Yes I would connect them all together but each cable screen should be earthed at one end only, the other ends should be insulated with some heat shrink sleeving for example.


should TMR2IF be cleared at each loop ?

dsc
24-11-2013, 09:49 PM
I've connected the screen (one end, the other is tied back) for the PUL / DIR inputs into the E(arth) on the PSU, not much difference though, here's a shot before the screen got connected:

10861

and here's after:

10862

Minimal difference, although there's a lot of noise on that line (that's the PUL- / GND scopped). Not sure what it is, or how to get rid of it. On the other hand, the proto board is a mess full of breadboard wires, so isn't exactly super noise resistant.

I can't capture a long scope, I can only do a print screen kind of capture which isn't good enough to show how the PWM frequency changes. I can see a rolling effect ie. frequency increasing on the scope when the motor starts, but I don't know what causes the glitches on the motor. It stopped again with a positioning error today, don't know why though.

EDIT: here's a video, although it's hard to hear the glitches: https://vimeo.com/80205760

Regards,
dsc.

dsc
26-11-2013, 08:51 AM
I've done some further testing on this, here's my findings:

1) as soon as I plug the DC supply in, there's noise on the PIC lines. It doesn't matter if the PIC lines connected to the driver or not, the noise is still there:

10865

It's periodical, with a period of 11.5us, which gives a frequency of around 87kHz.

2) plugging the PIC control lines to the driver, causes the low levels to jump up by around 100mV, I wasn't expecting that to be honest:

10866

3) there's loads of spikes on top of the PWM signal, see here:

10867

Not sure this makes a lot of difference, the high level trigger for the HBS86 is > 3.5VDC and low is < 0.5VDC, so it should behave itself.

Any ideas on how to tame this? screening to earth doesn't seem to affect the noise at all. I've also tried ferrites, with not a lot of luck.

Regards,
dsc.

EddyCurrent
26-11-2013, 09:27 AM
Chances are it's a switch mode dc supply, in cases like this I used to connect the circuit to batteries as this eliminates a lot of problems straight away and indicates where the main problem lies.

dsc
26-11-2013, 10:02 AM
Cheers EddyCurrent, I was thinking it's something to do with the plug-in DC power supply I'm using for the PIC circuitry running in parallel with the big 68VDC PSU. I will try a 9VDC battery and report back.

Regards,
dsc.

dsc
27-11-2013, 10:24 AM
I've switched to a 9VDC battery, not much difference, after which I've earthed the driver chassis, which dropped the noise levels significantly. Comparison between a battery supply and plug-in DC supply with the driver chassis earthed:

10868

I'll stick with the plug-in supply and keep everything earthed.

Regards,
dsc.

EddyCurrent
27-11-2013, 10:30 AM
That's good, the main thing with trying a battery is to remove that doubt so at least now you know the PSU is okay.
So with noise levels dropped has it improved the operation ?

Jonathan
27-11-2013, 10:38 AM
Your code looks like it should be fine.


I've switched to a 9VDC battery, not much difference, after which I've earthed the driver chassis, which dropped the noise levels significantly.

So did it solve the problem? Since using a battery didn't make a difference, that implies the noise is not emanating from the supply. The most likely source is the 'mess of breadboard wires'. You should aim to keep the wires short to minimize stray inductance, keep power wires close together for the same reason and use decoupling capacitors.

For example, you can see in this photo how the breadboard on the right uses much longer wires than necessary and the capacitor is a long way from the IC. My one on the left is neater...

10869

The circuit above still worked as it operated at quite low frequencies (where stray inductance is less of an issue). If it hadn't then it would be worth rearranging it.

Jonathan
27-11-2013, 10:42 AM
Oh also, if you want to be able to record logic level signals over a longer period, you could get a logic analyzer like this one:

USB 24M 8CH 24MHz Logic Analyser 1.1.16 | eBay (http://www.ebay.co.uk/itm/USB-24M-8CH-24MHz-Logic-Analyser-1-1-16-/321241417226?pt=UK_Computing_Other_Computing_Netwo rking&hash=item4acb7b060a)

dsc
27-11-2013, 10:49 AM
I haven't tried running the motor yet, so I can't say, it definitely dropped the noise levels from around 700mV max to 400mV max.

I've changed my approach slightly, the ramp was done with a simple delay function, which isn't great as it prohibits the user from stopping the motor whilst it's ramping up. I already have a 100ms interrupt setup, which I will use to modify the PR2 register and change the frequency there. I'm going for a 1000ms ramp up, during which the motor can still be stopped easily by pressing a button. Safer and better overall I think, although it does have a downside. It won't be as smooth as before as I only have 10 interrupts within that 1000ms period and I need to go from PR2 = 77 to PR2 = 18. This means dropping the PR2 by 6 every 100ms.

My breadboard is a mixture of short and long wires, so I'm sure that's not helping this case. I'd normally stick it in a metal earthed box, but the board is rather large and so won't fit in anything I already have.

I'll add that logic analyser to my shopping list.

Regards,
dsc.

Jonathan
27-11-2013, 11:02 AM
Can't you just connect the button to one of the interrupt-on-change pins and make that a high priority interrupt? That will allow you to break from the delay function and stop the motor. You could also use a timer based interrupt instead of the delay - just set the timer pre-scalars so it overflows every 5ms (or whatever you need) and enable the relevant interrupt bit. That way the PIC can do something useful instead of twiddling it's thumbs for 5ms.

By stop you presumably mean increment PR2 to decelerate the motor in a controlled manner, otherwise you risk loosing synchronization particularly if the load inertia or speed are high. If you want the motion to be smoother, then instead of using constant acceleration you could set the derivative of acceleration ('jerk') to be an s-curve like tanh(x):

10870

To do that, either use the (approximate) equation for that function or a lookup table to calculate the required PR2 value each time the timer interrupt occurs. I don't know what the purpose of this project is so not sure if this is necessary, but it's more interesting ;)

dsc
27-11-2013, 11:27 AM
I can do, it's just currently it's connected as a general I/O, debounced with some action behind it. The change of approach is using a timer based INT, the period is set to 100ms, as the INT also acts as a 0.1s timer for timer / LCD /sampling purposes, I've looked at changing it to 15ms or so to change the PR2 by 1 rather than 6, but overall there's very little difference in how this relates to speed. Here's a comparison between a 1 per INT change vs. 6 per INT change:

10872

Also the above shows the speed changing in relation to the value in PR2, as you can see it's not linear. I wanted to stop the motor without slowing it down, the load inertia isn't high and max speed will be around 500RPM.

All I'm wanting from the slow ramp is to have more torque at the start, the torque requirement drops once the thing is moving.

Regards,
dsc.

EDIT: wrong attachment shown before.

dsc
29-11-2013, 08:20 PM
Ok I've tried the new approach with changes to the PR2 every 100ms, all works well on a scope and on the motor, although the motor still glitches now and then on start up. Have a look at the noise levels:

10899

Huge is an understatement, this is measured directly on the plug to the driver, everything is grounded at this point, this includes:

- chassis of the machine
- motor
- driver
- screen on the PUL cable
- screen on the encoder cable

here's another print showing the noise levels with the motor stopped:

10900

I'm surprised the thing doesn't trigger itself. If I unplug the motor and disconnect from the drive, the noise levels drop significantly:

10901

The biggest question mark is the noise levels when I disconnect the screen on the PUL cable:

10902

Grounding the screen seems to make things worse for some reason. Yes the screen is only connected on one side, the other side is tied back.

Regards,
dsc.

irving2008
30-11-2013, 07:26 AM
Where are you attaching scope ground to? Sometimes the act of observing can make things seem worse.

If possible try using two probes differentially with scope ground at star point.

dsc
30-11-2013, 11:28 AM
I thought it might not be the real noise, the ground is connected to 0VDC on the breadboard.

Regards,
dsc.

dsc
30-11-2013, 09:43 PM
Right, ignoring the scope for a second and focusing on how the motor works. I'd say that 70% of the time it starts normally and runs normally, but every now and then (this can be a few starts in a row or every few starts) I can hear the motor glitching. It's hard to describe, but it's like the motor jumps a few steps whilst ramping up, I'd say it's a jarring / vibrating sound as if the pulses at that point come too often and the motor can't keep up. I've used both the scope and a logic analyser and the pulses are generated properly, so I can only blame noise or something on the driver side. Could this be the detent torque kicking in, similar to the problems I've had on the DM856 and low frequency pulsing (when microstepping the motor can't be kept in between microsteps and so falls into the closest full step position)?

I can only hear this jarring noise on ramp up / when changing frequency, when it's at the required speed it runs smoothly. The same jarring can be heard when using a signal generator and changing frequency. I've tidied up the wiring on the breadboard, there's only a few long wires left (for the LCD), everything else is done via flat wiring on the surface of the breadboard. I've also used a long meter cable to connect the controller to the driver and earthed the screen, but earthing (one sided) makes the noise worse! the noise only appears when the driver is connected to the driver, if disconnected it's all nice and smooth.

Any ideas on what else can be tried would be good. So far nothing I've tried has eliminated the dreaded glitches / jarring...

Regards,
dsc.

Jonathan
30-11-2013, 10:29 PM
When you accelerate the motor it will pass through it's resonant frequencies, so the noise you hear may be due to this. Try recording the rpm at which you hear the 'jarring noise' and just run the motor at that speed. Also see if the noise occurs at the same speed every time. If it continuously sounds bad at that speed, or even stalls, you know you're at a resonant point. The speed at which that occurs will change if the motor is connected to a load. It shouldn't be a problem if the driver is doing what the manual claims.

Edit: Having said that, since you say it doesn't happen consistently it sounds like something else might be amiss.

dsc
01-12-2013, 01:25 PM
Indeed it doesn't happen consistently, it's a spurious thing, a few smooth starts and then you get two or three with glitches, then back to smooth starts again. Also I get those dreaded positioning errors again, which forces me to power cycle the driver. If it was only glitches on ramp up I'd be willing to let it go, but it causes positioning errors, which stops the whole thing from running, so I need to resolve it.

Regards,
dsc.

dsc
01-12-2013, 10:35 PM
Kudos to Jonathan for recommending the logic analyser, here's what I've found on the PWM channel:

10926

This was due to the fact that I was updating the PR2 without waiting for the PWM cycle to finish (I was doing that before, but you need to clear the TMR2IF flag before you go into the while loop; normally the flag gets set and sits like that forever, unless the TMR2 interrupt is enabled). I've now changed the code slightly and voila! no glitches.

Regards,
dsc.