Feed per rev G95 way too fast

Hi, Sorry, please bear with me, I'm new here and relatively new to LinuxCNC.I've been converting an old Boxford 240 TCL to LinuxCNC running on a Pi5. 

Everything is running fine(ish) there are still some glitches and errors that crop up and the odd latency warning too (stepping is done on an EC300 running remora so I'm not so worried about the latency warning).

However... i've gotten to the point of testing, and for some reason in G95 and feeding at 0.1mm/rev the axis runs at way faster rate, 10x maybe more.Anyone have any idea what is going on?  The only other thing to note is that I am having issues with LinuxCNC seeing my index pulse, but it is seeing the count from the single encoder (100 slot disk with a second slotted opto switch for index so not quadrature). 
I'm assuming that its possible the feed issue could be linked to that.

The other issue I am having is when i run a program, it won't run through automatically.  The only way it will run is by me hitting the single step through button.  I'm wondering if that is linked to the encoder also as perhaps LinuxCNC isn't seeing "at speed" so isn't letting the program run?

hal and ini attached.  Please forgive the messy files, once they are running right I'm planning on cleaning them up. 

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.

Hi Andy, I've been running a 25,000ns relatively successfully. Which is why I've been scratching my head so much. However, actually thinking out loud on here had me thinking it had to be electrical. So I dug out the oscilloscope and probed the signal. The cheap Chinese sensors had a 20k pull up resistor which was far too strong and was causing the pulse width to be way too long. So at 1900 the signal went from a pulse train to just "on".

I've swapped out the resistor and now getting good clean pulses read by the Pi with a stable speed reading up to 4000rpm.

Thank you for your suggestions as they have pointed me in the right direction. I'm in the process of modelling up a mount so i can mount two sensors to create a encoder that will do direction as you suggested.