ColorCNC Colorlight 5A-75E/5A-75B as FPGA controller board

The angle sensor IC can be programmed to output a Quadrature (A,B,Index) signal.
In the schematic [7] of the MKS-SERVO57A, I see those three pins of the chip (12,13,14) to be floating.

Therefore there's no need to snoop the SPI bus, I can just route the 3 Quadrature pins back into the FPGA board, and patch the firmware of the microcontroller to enable those outputs.

[7] raw.githubusercontent.com/makerbase-mks/...A_V1.0_001%20SCH.pdf

DePrutser wrote:

[...]

When I got it working, I'm planning on extending your README.md and sending a pull request.

Cheers,
Cedric
 

Your pull request will be mroe then welcome to help with writing things down!

About the stepgens: just pushed a new commit in which:

• the pick-off (the position of the fixed point) can be set (in code for now, if people want I can make it also user-configurable) with different settings for position, velocity and acceleration. This gives some smoother behavior on the stepper motor. For example, if I use the same pick-off for speed and position, the maximum speed attained will be a step with every clock of the FPGA (50 MHz in my case). This is ridiculously fast and as far as I know there is know stepper driver capable of doing this. The lowest step frequency will be 1 / 2^32 step per clock cycle, which boils down to 0.01 step per second. Especially with very low speeds or with ramping down this might lead to some vibrations. Therefor, the pickoff for velocity is now shifted with an additional 8 bits. The maximum step frequency now becomes 195 kHz, which is reasonable high and close to the max frequency of for example standard Leadshine or Lichuan driver (checked with the DM542). The minimum speed is now 0.00003 steps per second. Audibly this results in a much smoother running of the stepper motor.
• the pick-off for acceleration was already shifted by 16 bits, otherwise it would be always zero. It is now also easy to re-configure this to another value.
• In the firmware the shift of the acceleration relative to the position determines the extra bytes required. For a relative shift of 16 bits, this will consume 3 bytes of extra 'space' for the registers.
• because above lead to changes in both firmware and driver, the version number is bumped. This version number will prevent users from combining incompatible firmware and driver.

With my tests I also discovered vibrations of the stepper motor at stand-still. This was not the default hissing of the driver, but it comes from a noise signal from the FPGA. I suspect that the motion planner and the error correction in the stepgen are fighting to get the error down to zero. I will check whether temporarily stopping the error-correction will solve this error this evening. 

LiteX-CNC is now working. Next I'll try to compile the gateware:
forum.linuxcnc.org/27-driver-boards/4692...itex-cnc-on-linuxcnc

Today a small improvement on the stepgen. When on standstill the stepper produced a buzzing sound, it was switching between two (micro-)steps. For standstill situations I improved the driver to prevent this instability to happen. The stepper is nog silent and still runs smooth.

"Your pull request will be more then welcome to help with writing things down!"
I've created the pull request here:
github.com/Peter-van-Tol/LiteX-CNC/pull/2

Kind regards,
Cedric

I will look into the merge request and will definitely cherry pick some components from it.

Small update: At this moment I'm designing an S-curve planner for the driver, because I was not happy with the smoothness of the current driver. What does S-curve mean? At the end of each cycle the stepper will run at the commanded velocity (calculated as the velocity to get from the old position to the new position). Any error will be corrected by accelerating faster and slower during a part of the cycle. For small errors this can be obtained within one cycle, for large errors the cycle will be stretched.

Another reason to re-write the driver is speed and readability of the code. It is much cleaner now and there are less corner cases as the formulas used will be all physics and areas of triangles. There is however one square root to solve when the error gets too large, bu I accept that for now as it runs faster then the previous version.

Before I push this new driver, there is one problem to solve: the calculation blows up when jogging and a constant speed is obtained (possibly a division by zero error). But the acceleration phase is smooth as a possibly can be.