screening / glitchy operation - sanity check

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:

Attachment 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.

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?

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.

Quote:

---

Originally Posted by dsc

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 ?

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:

Attachment 10861

and here's after:

Attachment 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.

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:

Attachment 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:

Attachment 10866

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

Attachment 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.

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.

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.

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:

Attachment 10868

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

Regards,
dsc.

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 ?

Your code looks like it should be fine.

Quote:

---

Originally Posted by dsc

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...

Attachment 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.

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

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.

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):

Attachment 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 ;)

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:

Attachment 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.

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:

Attachment 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:

Attachment 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:

Attachment 10901

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

Attachment 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.

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.

I thought it might not be the real noise, the ground is connected to 0VDC on the breadboard.

Regards,
dsc.

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.

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.

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.

Kudos to Jonathan for recommending the logic analyser, here's what I've found on the PWM channel:

Attachment 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.