> On 21 Sep 2019, at 03:10, justin White <[email protected]> wrote: > > 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. >
You hit the nail right on the head (Although I’d like to nuance about the Beaglebone). The FPGA solution is very powerful. At the same time it’s the Achilles heel. To get an FPGA running with mksocfpga is a lot of work and not many people can do that. When you want to apply this in an industrial environment then you need hardware that’s around for longer than the developers SoC boards are around. Say 10 year. And are available. There are some boards with long life supports. Like these: http://www.exorembedded.net/webpage?ReadForm&wPageName=products&t=Product&p=microSOM%20uS02 Even if you can buy these for example in small quantities (I’ve enquired and you can only buy them at 500 pcs, silly) you still need to develop additional hardware. So for a small form factor with RT capabilities, ready to use proper OS (not some gobbled up Linux image that loses support the moment you buy the board), availability and longevity there are not a lot alternatives for a Beaglebone... and then again you need additional hardware ;) >> On Thursday, September 19, 2019 at 4:33:49 PM UTC-4, [email protected] wrote: >> Sep 19, 2019, 19:41 by [email protected]: >> >> > 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]. >> > 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. -- 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/C936888B-80D7-4CAE-86FF-7E88AA7F0732%40basdebruijn.com.
