Encoder position feedback

[MadTooler]

I recently found your control system while looking for encoder feedback with an esp32 based gcode system. I am very impressed.

(https://github.com/bdring/Grbl_Esp32/issues/330#issuecomment-587589644)

The post that lead me here mentioned was in the Grbl_ESP32 repo and mentioned the delta drawing robot with Dynamixel Servo Modules that could disable the motor while tracking motion via the built in encoders. I am considering developing a motion system with maybe two or three steppers that will also have encoders. Possibly two encoders per axis since I will probably use a closed loop stepper driver to offload close loop correction to the driver instead of FluidNC, but also have an incremental encoder on the axis shaft to read manual movements into the controller.

Is there a config of FluidNC that allows for XY encoder inputs as you suggested with the delta robot?

Thanks

[bdring]

FluidNC does not read encoders. It can periodically read position information in idle mode from motors with a communications interface. It can do that with the Dynamixel motors now.

We do not have plans for reading "dumb" encoders at this time.

[MadTooler]

Thanks for the reply.

How frequent is a periodic read of position information in idle mode?

Maybe I will look into making a mod of FluidNC (not my preference), or maybe add another processor to deal with the encoders and other add-on features I have in mind. Are you aware if FluidNC is using the "pulse counter hardware peripheral" or related resources of the esp32?

[bdring]

Only fast enough for human interaction. no more than 10Hz.

[MitchBradley]

The pulse counter is not used.

[jeedee23]

Thanks for the reply.

How frequent is a periodic read of position information in idle mode?

Maybe I will look into making a mod of FluidNC (not my preference), or maybe add another processor to deal with the encoders and other add-on features I have in mind. Are you aware if FluidNC is using the "pulse counter hardware peripheral" or related resources of the esp32?

Hi, I am on the brink of doing the exact same thing in order to remove all possible backlash. Indeed we would need an extra processor which gives the "go" for every start of travel (is on right position), and also gives the "ok" on the end of the travel.

I do this with rotating and linear encoders counting and sending the feedback. However we need to adapt the firmware, so the main esp32 receives in realtime the data from another ESP32. As this has to go at a very fast pace I wandered, if you had achieved something. It is like a closed loop system, for which there are eough drivers of course. But if you have backlash, no matter what you send, the backlash is there.

We could do a test run before starting, calculate the backlash, and integrate the data in the firmware. Is there a backlash correction in the firmware?

[MitchBradley]

Who exactly is this "we"? You are talking a major redesign of the most critical core routines of FluidNC.

[jeedee23]

Who exactly is this "we"? You are talking a major redesign of the most critical core routines of FluidNC.

We as in "We", me, myself and others. There is no major redesign, the data should come from a separate system. See my feature request. Backlash data then should be added an/or substituted from the travel steps, in steps or microsteps. Calculating those data should be a complete other system, so we (as in me, myself and others) don't interfere with the already existing system. Of course, we (as in me, myself and others) could also write a gcode, then let that code run, measure, regenerate the gcode (and eventually others) . But that is a complete workaround, and very difficult if it concerns arcs.

[MitchBradley]

we need to adapt the firmware, so the main esp32 receives in realtime the data from another ESP32. As this has to go at a very fast pace

Unless you know something that I don't about the innards of the FluidNC planner and communications framework, I would say that is major redesign.

"Very fast pace" communications is a difficult thing when you are dealing with a system that already has complex communications requirements with multiple other devices over different physical channels, and already has hard realtime scheduling requirements for motion control.

We are already struggling with making relatively-slow communications to pendants and IO expanders reliable enough to actually use without crashing machines.

[MadTooler]

Who exactly is this "we"? You are talking a major redesign of the most critical core routines of FluidNC.

We as in "We", me, myself and others. There is no major redesign, the data should come from a separate system. See my feature request. Backlash data then should be added an/or substituted from the travel steps, in steps or microsteps. Calculating those data should be a complete other system, so we (as in me, myself and others) don't interfere with the already existing system. Of course, we (as in me, myself and others) could also write a gcode, then let that code run, measure, regenerate the gcode (and eventually others) . But that is a complete workaround, and very difficult if it concerns arcs.

@jeedee23 You have to be careful with backlash comp on machines like an old lathes. It can lead to oscillation and rough cuts as the slop is taken up by cutter pressure.

The solution I am working under, although I now run a custom gcode sender, is to have a dedicated MCU (RP2040 but esp32 would work well too) as a closed loop motor driver. I think that is the direction you are headed. The motor driver then receives both encoder and step/dir signals and does the work needed to keep on position. If it cannot, it sends a fault direct to pins on the fluidnc board.

The hardest part, at least for me, is timing and blending in new steps as needed for error correction. I can't share my exact coded solution since it isn't really a good fit with all the additional custom tasks I have pushed onto my closed loop driver (current state is pretty much a mess too). However, there are several good opensource closed loop motor drivers out there that could be a good source if you decide to take this approach.

[hsyngndz85]

I2c den konum bilgisi alıp yorumlayacak bi eklenti lazım 6 eksene kadar mümkünmü

[hsyngndz85]

https://github.com/Aus3D/MagneticEncoder kaynaklar hazır fluidnc ye eklenti gerekiyor sadece

[hsyngndz85]

Şu anda "aptal" kodlayıcıları okumaya yönelik planlarımız yok. Demişsiniz ama bu haliyle pro makina gapmaktan uzak bu yazılım

[bdring]

This is a closed issue.

We have no plans on supporting encoders in FluidNC at this time.

[hsyngndz85]

Sorun değil önerdiğim bu yazılımı modifiye edip kullanıcam kartımın kapalı çevrim özelliği olacak. Bu arada fluidnc özelliklerini inceledim harika görünüyor. Kolay gelsin

[jeedee23]

Who exactly is this "we"? You are talking a major redesign of the most critical core routines of FluidNC.

We as in "We", me, myself and others. There is no major redesign, the data should come from a separate system. See my feature request. Backlash data then should be added an/or substituted from the travel steps, in steps or microsteps. Calculating those data should be a complete other system, so we (as in me, myself and others) don't interfere with the already existing system. Of course, we (as in me, myself and others) could also write a gcode, then let that code run, measure, regenerate the gcode (and eventually others) . But that is a complete workaround, and very difficult if it concerns arcs.

@jeedee23 You have to be careful with backlash comp on machines like an old lathes. It can lead to oscillation and rough cuts as the slop is taken up by cutter pressure.

The solution I am working under, although I now run a custom gcode sender, is to have a dedicated MCU (RP2040 but esp32 would work well too) as a closed loop motor driver. I think that is the direction you are headed. The motor driver then receives both encoder and step/dir signals and does the work needed to keep on position. If it cannot, it sends a fault direct to pins on the fluidnc board.

The hardest part, at least for me, is timing and blending in new steps as needed for error correction. I can't share my exact coded solution since it isn't really a good fit with all the additional custom tasks I have pushed onto my closed loop driver (current state is pretty much a mess too). However, there are several good opensource closed loop motor drivers out there that could be a good source if you decide to take this approach.

You are correct, therefore, the backlash must first be checked by the system and then, every individual stepper will indeed have it's proper esp32, working with interrupts, and "foresee" the coming backlash, thus compensating it, spreading over the multiple steps, before end of command, the linear actuator will give feedback during deceleration, of the actual position up to 0.001 mm. Depending on the tolerance in the setup, we then can let the system decide, whether to compensate the final adjustment after deceleration, of course with the proper slow down if we need such a small tolerance. We need to be indeed very carefull about oscillation and vibrations. But, as an older person with time, I have the time advantage, slow and sure.