screening / glitchy operation - sanity check

[Jonathan]

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



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]

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

[dsc]

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]

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



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]

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:



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]

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:



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:



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



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



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]

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]

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

Regards,
dsc.

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

[Jonathan]

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.