The FPGA is LinuxCNC's magic bullet because FPGA's in general are magic bullets. IMHO, mksocfpga could also be Machinekit's magic bullet in a way that is even more potent that off the shelf Mesa hardware. This is what LinuxCNC is missing, and Machinekit is not quite exploiting enough. The means exist for you to design your own field tolerant hardware and configure the hm2 firmware however it suits using an socfpga dev board of your choosing as long as Charles/Michael have gotten their hands on it.
Not to knock MK, I understand it's mission statement... I just don't have real faith in Beaglebone or Raspberry Pi hardware. I'm sure they are great for 3D printers and such but running a machinetool on them makes me cringe. I think the DE10 Nano is good hardware with an FPGA that is more than large enough. Could use a bit more CPU and a GPU though. CPU performance seems good enough with a FB that I think it can get away with quite a bit. I have yet to explore the headless-remote setup but I'd think there would be very little left to desire if it's well sorted. I would not say microcontrollers are not plenty capable but I would not bother with the availability of very capable FPGA hardware that is relatively easily configured. Micros are better sorted for something specialized like the STM32 used in STMBL drives. I can understand the desire for low cost machine control for a 3D printer, but trying to spend less for the control solution than the cost of 1 motor and step driver is a bit silly. The fact that you can control a machine with reasonable hardware for a couple hundred bucks these days all in is amazing in and of itself. On Thursday, September 19, 2019 at 4:33:49 PM UTC-4, [email protected] wrote: > > Sep 19, 2019, 19:41 by [email protected] <javascript:>: > > > Hi Cern, > > > > You are the guy. You helped me a lot. > > > > And, > > > > Isn't the following veeery long and also great explanation about what I > (kind of) have asked for in the first place? > > > I don't know about great, but in a way it is. And you can use it today if > you are able to meet the limitations (AXIS like GUI, remote HAL components, > MKWrapper, Launcher and so on). The problem with the latency and what is > one capable with reaching is the video Frame Buffer. You are never going to > get the best when you run the graphics on the same system. (Plus you should > always use processor isolation, you can even let different tasks (threads) > run on different wholly isolated cores.) > > BTW, in many cases you don't even need FPGA. It became a kind of magic > bullet in LinuxCNC community, because the solution around HostMot2 works, > it has support from Peter Wallace, is universal and people like repetition. > There are many (commercial) solutions based on microcontrollers which work > as good. > > But if you want something like CS-LAB CSMIO (real-time tasks with > additional hardware for encoder counting, PWM and step/dir generation and > some real-time processed GPIO commanded by some higher system), then you > are out of luck with current system. Even if @SnowWhite's SoC solutions > could be excellent for this, you would still need to slash the Motion > component. > > (That's another legacy from LinuxCNC, they historically had a problem with > letting go of the all-in-one system.) > > Cern. > > > > > Berkdan > > > >> @cern > >> > >> Curious, what is the state of machinetalk? > >> > >> I am at some point planning on running a remote GUI, pretty much as you > described with a de10 nano as the RT pc/FPGA and some ARM or small X86 > running the interface. I didn’t get too far in depth of what I need to do > with remotely controlling it, too busy with hardware but I thought the > remote concept of machinekit was solid. > >> > > This is only my view at the situation and as such there is going to be a > difference of opinions. Mainly what Machinetalk is and what it should do. > > > > The Machinetalk and HALtalk is a joint baby of Michael Haberler and > Alexander Rössler (for whom I think it was a diploma work). By post-mortem > investigation, there were a quite big plans for what Machinetalk should be > able to do. It was intended as a replacement of the NML and also shift from > current position, when NML sits on top of (for example) motion component, > nearer the HALayer core. That way it would enable node structure of machine > system setup. (As a example, imagine two RTAPI instances (msgd and > rtapi_app daemons) running infinite real-time loop tasks like now, but > getting the instruction from one separate planner, which it itself is > controlled from numerous terminals [GUIs].) Instances of Machinekit should > be also able to communicate with each other, not only with current > clien-server. As there was intention for direct control of rtapi_app > created HAL. > > > > But then Michael Haberler performed his exit stage left without > finishing his work (he even wanted to write documentation) and Alexander > Rössler was always (and by his online activity still is) interested more in > GUI and HMI work and replacing AXIS with something remote/running on > Android/written in modern language. > > > > So, the current situation is that the Machinetalk (and affiliated > technologies) is deeply ingrained into Machinekit, but not deeply enough as > too much LinuxCNC ways is still visible. And then it's development stalled. > And that is the root of my frustration. > > > > So, to @Bas, if you want to use only the UI components, you are fine as > it works. (But is still only a clutch, as the messages are translated to > NML to communicate with Machinekit-CNC side.) However, look for example at > the NOTYET portion of code in rtapi_app and then how HALCMD communicates > with rtapi_app. It uses the Machinetalk. But then not. It uses the ZeroMQ > layer and Protobuf serialization. And then it registers itself as a HAL > module, which I consider a braindead move (OK, I get it why it does that, > but it's bad architectural design and means that the process needs to run > on the same system as a rtapi_app). Saner approach would be to enforce the > rtapi_app only place where access to the HAL shared memory space happen. > CMDLINE would message rtapi_app socket with command, rtapi_app would > execute it and send back a status. That way you can milk the great feature > of ZeroMQ and use HALCMD from everywhere, even Windows Machines. (Typical > machine programmer monkey cannot use Linux.) > > > > I think the best approach would be to implement what I described here: > https://github.com/machinekit/machinekit-hal/issues/230 < > https://github.com/machinekit/machinekit-hal/issues/230> with Linux based > permissions on file access, onto this connect new process which would do > the Machitalk access (machinetalk_app), which would do all what is done now > plus manage permissions (which current implementation of Machinetalk does > not even take into account) based on certificates, protocols and interfaces > (you can have an interface you consider implicitly safe which is direct > connection to other parts of the machine and then another which is LAN) > onto which would be connected the HALCMD and other similar applications or > remote/nonRT connected rtapi_app (Machinekit-HAL) instances. But, as I > said, it is only my opinion. > > > > Also, part of Machinekit is the router message pipe (currently not used, > I think) which is intended for direct messaging between two HAL modules. > Imagine module which has a ring buffer. This ring buffer is filled from one > side by (for example) RT HAL module, then on other end emptied by this > router, send over ZeroMQ to other machine and there the dealer puts this > message back into receiving ring buffer of some local HAL module. Problem > with this is that the HAL module works with structures, but the router has > to serialize this to Protobuf format and remote router has to deserialize > it. For this, something with same-on-wire-same-in-memory format would be > better. Like Flat buffers (pending consideration on memory alignment). > > > > Machinetalk is also big on multipart messaging concept. Which is > considered by parental ZeroMQ community as an obsolete (or starting to be > obsolete) and is no longer supported with new messaging patterns and > sockets - like the UDP, which for direct communication between two > Machinekit/Machinetalk instances would be the best. > > > > (BTW, Machinetalk with DNS-SD will have a big problem with non-Ethernet > network, for example were you implement the ZeroMQ pattern over RS-232 > serial, for which there already was interest.) > > > > It would be also great to use the current HAL-REMOTE component pattern > for PIN creation before the actual HAL component is instantiated. I see the > use for going away with the postgui.hal hack and streamlining the HAL > configuration setup and tear down for non-realtime capable components. > > > > Sorry for the rant, but that is what I see is problematic with > Machinetalk. I want independent islands of functionality which don't care > about where they run and are able to dynamically change each other. > > > > But it needs people interested in it. And so far, nobody (with big > enough means) really is. > > > > Cern. > > > > -- > > 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 [email protected] <javascript:>. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/machinekit/f58e7235-a387-482b-bd51-061e87e711a7%40googlegroups.com. > > > > > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/4eb48782-49fc-40ec-b7e0-a52d1d8e8f8d%40googlegroups.com.
