I am not that expert on machinekit, but I will try to give my opinion, maybe someone will support or correct it
The problem is communicating with lots of machine pieces, in Machinekit exists Machinetalk but it makes more Machinekit instances talking to each other (and Machinekit runs on Linux). It is based on ZMQ, that requires some Unix system calls, so moving to MCU world may be quite hard, always if it is possible to port ZMQ to firmware. Talking about low level communication protocol CAN may be a good option, since it is already used in automotive and supports multiple endpoints talking (one at time) with a master. Or even multi master if needed. But this would require some work above that comunicate in a proper way with machinekit, at least a HAL module/ direver that manages the CAN communication and shows all the connected MCU to the other HAL module Another system that try to solve this is EtherCAT, LinuxCNC can surely talk with ethercat modules I tried it a couple of years ago, and i found that the industrial world use EtherCAT on windows and has the xml config file written in a different way from the LinuxCNC world. Manufacturer will give the config in the standard way, and you will have to translate it for yourself. For example, I made a xml file to work with that arduino shield <https://www.bausano.net/en/hardware/ethercat-e-arduino/easycat.html> , but I died while trying to interface with a Weidmuller EtherCAT module (again, it was a couple of years ago, and I am a very beginner). talking about the Raspberry, I have seen everyone avoided it's Ethernet controller is on the USB-bus, so it's inherently non-real-time. Other boards available are the asus Tinkerboard, or the banana Pi, but I have seen few people using that alternatives. mngr Il giorno martedì 18 settembre 2018 05:07:43 UTC+2, Joshua Dickerson ha scritto: > > Hello everyone, > > I am working on and off again on writing my own machine controller, > largely to understand LinuxCNC and related projects like MachineKit. For > reference, here's the controller I wrote running a few years ago: > > https://www.youtube.com/watch?v=qasLhuJFZNU > > > I'm starting back up on the project. Right now it works very similar to > LinuxCNC, a shared memory space, all HAL components running on a single > controller. What I want to do is make a machine controller that could have > conceivably worked on 80s MCUs, but also work on single desktop machine. > The idea would be to have a distributed HAL that would function across > multiple MCUs- but of course works in the degenerate case of a single > machine/PC with shared memory space, as with LinuxCNC. For instance, there > would be a main MCU which reads files, runs the GUI/HMI and handles the > trajectory planning, homing, probing, tapping, etc. There would also be a > dedicated MCU for each joint controller which is updating encoders and > sensors, generating step pulses, closing servo loops, etc. > > My naive approach would be to have a registry of output signals which > includes which MCU each actually resides on. So if a particular HAL > component task is reading a signal that's already on the MCU it's running > on, it's immediately returned- otherwise it pulls the data over a network > layer (which could shared memory bus, RS485, ethernet, etc.) Is there > something out there that does this? Maybe some kind of mutant hybrid > between HAL/NML/SCADA? > > Of course this complicates things over simply using pointers to a single > shared memory space. I also get the sense the linuxCNC group balks at this > kind of idea, they want to keep it all on one machine in the interest of > latency anyway. Just searching various machine controller project > communities for where this kind of idea might be interesting. I would > really like something like a Raspberry Pi tied into a MCU which does all > the hard-RT/IO stuff, but not quite in the way Klipper does it. Klipper > basically sends commands to be followed at some specific time stamp. > That's actually pretty cool, but I want something that allows for more > feedback and flexibility between the various systems. > > Anyhow, thanks in advance for your input. > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
