Device control in automation has moved towards digital bus systems, and away from legacy interfaces like 0-10 Volt or 4-20mA. This development is not reflected in Machinekit with a few exceptions.
The exceptions are: a few Modbus drivers, and the hostmot2 driver has an Ethernet flavor which works over a Mesanet--specific message encoding.
There is no support at all for fieldbus devices using CANopen, and no integrated support for RT Ethernet protocols like EtherCAT or Powerlink.
Besides being unable to connect a huge range of stock devices to machinekit, this has given rise to ad-hoc interfacing methods like this one: http://emergent.unpythonic.net/01198594294 with the associated reinvention of features: protocol, message encoding, device control, error checking, user interfaces - plus the downside of a point-to-point connection topology.
Many embedded devices in use support CAN (for instance stock with the TI Sitara processor used by the beaglebone, and the zedboard via its FPGA), which is a very cheap and effective method to hook up both for stock industrial devices, and homebrew controllers like the one mentioned above. Those could be CANopen masters, as well as slaves. Moreover, many embedded devices can cheaply hooked up to CANbus (eg http://www.logicsupply.com/eu-en/cbb-serial/, https://www.sparkfun.com/products/10039, http://elinux.org/RPi_CANBus).
What is missing with respect to CANbus is IMO:
integrated HAL support for low-to medium speed devices based on CANopen (a bus master), supporting the most popular device profiles including motion (DS402)
an example how to configure machinekit/HAL as a CANopen slave device (again possibly including motion), which would enable integrating machinekit into an existing automation setup
an example CANopen slave for a popular microcontroller platform, for instance Arduino-style devices, to talk to this
With respect to realtime Ethernet:
it would be great if we find a way forward to provide stock access to one of the existing EtherCAT masters with a HAL binding (eg. IgH Ethercat, SOEM, and Sascha Ittner's HAL binding); this entails finding a common position on perceived legal issues, an agreed method to deal with it, and address any formal prerequisites to do so
since RT Ethernet buses are many and a standard shakeout has not yet happened, reusable support for RT Ethernet would be helpful downstream. This could for instance be a building block which uses the AM335x PRU to handle Ethernet IO.
These two topics are somewhat related insofar as the standard encoding of message objects is based upon CANopen.
ArcEye
commented
6 years ago 
Device control in automation has moved towards digital bus systems, and away from legacy interfaces like 0-10 Volt or 4-20mA. This development is not reflected in Machinekit with a few exceptions.
The exceptions are: a few Modbus drivers, and the hostmot2 driver has an Ethernet flavor which works over a Mesanet--specific message encoding.
There is no support at all for fieldbus devices using CANopen, and no integrated support for RT Ethernet protocols like EtherCAT or Powerlink.
Besides being unable to connect a huge range of stock devices to machinekit, this has given rise to ad-hoc interfacing methods like this one: http://emergent.unpythonic.net/01198594294 with the associated reinvention of features: protocol, message encoding, device control, error checking, user interfaces - plus the downside of a point-to-point connection topology.
Many embedded devices in use support CAN (for instance stock with the TI Sitara processor used by the beaglebone, and the zedboard via its FPGA), which is a very cheap and effective method to hook up both for stock industrial devices, and homebrew controllers like the one mentioned above. Those could be CANopen masters, as well as slaves. Moreover, many embedded devices can cheaply hooked up to CANbus (eg http://www.logicsupply.com/eu-en/cbb-serial/, https://www.sparkfun.com/products/10039, http://elinux.org/RPi_CANBus).
What is missing with respect to CANbus is IMO:
With respect to realtime Ethernet:
These two topics are somewhat related insofar as the standard encoding of message objects is based upon CANopen.