Category: Basic Configuration
Hi Andy,
Thank you — your reply has pointed me in a couple of useful directions.
The current logic comes from another Boxford conversion running a Pi, though that one was a 125 (not mine) rather than a 240. That said, I stripped out most of it and was still encountering issues.
It’s GPIO14; I just hadn’t updated the comment yet as I’d moved pins to double-check something.
I have, however, found the G95 issue. The problem was that spindle.0.speed-in was connected to encoder.0.velocity-rpm instead of encoder.0.velocity, so the motion planner was seeing a speed sixty times faster than expected. Correcting that resolved the issue.
Most of the encoder speed problem stemmed from not having a sufficiently fast base frequency, which meant it was under-sampling and missing the index input. Moving the index pulse to an EC300 Remora pin has fixed that.
It’s not perfect, but it’s enough to get most things running until I can sort out a better encoder. I’ll probably follow your suggestion and add a second sensor offset by N+¼, although that will take some planning — the slot sensors are quite bulky, so getting them close enough will be tricky.
I’ve had to retain part of the spindle logic, as my servo input for analogue speed and direction is –10 V → 0 → +10 V. Because of that, I’ve kept the abs portion to strip the sign so that the DAC section only ever sees a positive voltage. The spindle is then reversed using two relays that invert the normal 0–10 V signal.
Unfortunately, I’m still not getting a stable speed above 1900 rpm. I suspect this is due to the sampling of the 100 PPR disk — when I decrease the base period, the speed stabilises, and by reducing it further I’ve managed to get stable(ish) readings up to around 1900 rpm. Above that, HAL Scope just sees phase A as high rather than a pulse train.
The good news is that feeding using G95 works when using the MDI.
The bad news is that no programmes will run. I get some movement when single-stepping through, but no feed. I now suspect this is because the programme uses CSS, and given the above issues, the control isn’t seeing a stable enough RPM for CSS to function correctly. I’ll try running the programme without CSS tomorrow to confirm.
If that doesn’t help, it’s probably a “spindle at speed” issue — though that signal does appear to be set correctly when the spindle reaches speed, so I’m not entirely sure.
