What is the best way to connect an (optical linear) encoder to a system involving linuxcnc + Mesa 7i95T and an ODrive Pro or S1 as the motor controller for each axis.
Can a single encoder be connected to both ODrive and the mesa board simultaneously?
Can the encoder be wired to the ODrive and have the ODrive passthrough the readings onto the mesa board?
Other/better options? Hopefully other than getting two encoders per axis.
TIA!
Hmm, interesting problem! What encoder specifically is this? I think a lot will depend on that.
Ditron DC13
5V RS422 and/or 5V TTL connectivity (will likely end up with some of both types)
0.1 micron resolution
10000 counts per mm
Perhaps the simplest is to connect the encoder to the mesa board and linuxcnc, and run the ODrive in open loop. Any concerns with that approach?
Given that’s it’s just an incremental encoder, I think you should be able to connect it to both the ODrive and Mesa at once! I don’t think I see any issues at all with that 
Any ground loop or resistance / signal level concerns if splicing the encoder to both the ODrive and mesa? Could there be situations where the two PID loops (linuxcnc+mesa vs ODrive) end up “fighting” each other?
Does the ODrive have the ability to re-output the encoder values, eg via GPIO pins, to the mesa board?
Any ground loop or resistance / signal level concerns if splicing the encoder to both the ODrive and mesa?
Ground loops, sort of. The Pro has common-mode filtered encoder inputs, so it should be able to withstand some AC-mode ground differential. But you can actually make it fully isolated – if you desolder FB4/FB5, it’ll isolate the the A/B/Z and Hall encoder inputs, just note you’ll have to externally supply power to the 5V/GND on J8.
Could there be situations where the two PID loops (linuxcnc+mesa vs ODrive) end up “fighting” each other?
I mean that really depends on your system. What’s the ODrive actually doing here?
What do you mean exactly? The ODrives will be used to drive linear forcers on some axes, and brushless DC motors on others.
With the encoder connected to the ODrive, Is it possible to re-output the encoder readings through GPIO pins, say G14-G16?
Is there a particular benefit in having the ODrive in closed loop in addition to linuxcnc+mesa having the encoder feedback? Or is there a drawback in running the ODrive in open loop?
So, the ODrive doesn’t generally support “open loop” operation – BLDC motors (linear forcers being one particular type of BLDC) are pretty different in operation than stepper motors; while ODrive can do open-loop movement, it really negates the benefits of BLDC motors over steppers. Typically for operation like this, I’d recommend using the ODrive in position control mode, as it can control the position at a much higher bandwidth and fidelity (8kHz) than the linuxcnc system, and you can additionally route the encoders to the linuxcnc+mesa for the DRO monitoring.
It’s possible to report the encoder feedback over CAN/UART/USB, but it can’t retransmit through GPIO.
Thanks, makes sense. Therefore it really is essential for both ODrive and linuxcnc+mesa to have encoder feedback. The purpose for the latter is not just DRO monitoring, but especially for coordinated motion of axes.
Is the inability to retransmit through GPIO a hardware limitation, or is it just not implemented? There was no intention of using CAN/UART/USB. The plan is to control the ODrive with step/direction input, from the mesa 7i95T.
Given the ODrive’s higher bandwidth, would the ODrive’s PID tuning be made tighter and the linuxcnc+mesa looser, to prevent having the two loops interfering with each other?
Is the inability to retransmit through GPIO a hardware limitation, or is it just not implemented? There was no intention of using CAN/UART/USB. The plan is to control the ODrive with step/direction input, from the mesa 7i95T.
The GPIO pins on the FEEDBACK IO header are isolated and thus unidirectional. While this is technically possible through G10/G13 on the ISOLATED IO header, this isn’t implemented. We’ll have functionality like this in the future on some other products that may be of interest to you – very similar to what you’re doing here 
(and we may backport this to the Pro, not sure though)
The plan is to control the ODrive with step/direction input, from the mesa 7i95T.
Understood, no issues there.
Given the ODrive’s higher bandwidth, would the ODrive’s PID tuning be made tighter and the linuxcnc+mesa looser, to prevent having the two loops interfering with each other?
Good question. I think you could honestly run the linuxcnc+mesa in open loop, if it supports that (quick google says… probably?). You can generally assume that the ODrives will do exactly what you ask them to, as long as external load is less than the max torque of the motor – the rule of thumb I use is that the ODrive (when properly tuned) can control the load positioning down to about +/- 10-20 counts of the encoder. So for your 0.1 micron encoder, this would be positioning under load of around +/- 2 micron. All that being said, it’s definitely useful to give the linuxcnc+mesa position for e.g. error detection, synchronized movement, etc. So in that case, I’d probably recommend just going through the normal PID tuning procedures after tuning the ODrive, and seeing what gains you come up with.
Amazing, can’t wait! And please do backport this to the Pro
