The length of availability is something that was concerning me as well, that does seem to possibly be the unfortunate downside. Getting the FPGA running is only hard for the mksocfpga guys I'm sure, modifying the firmware for hardware on users end is actually very easy because of how it's implemented. While I wouldn't take anything away from the mksocfpga guys, IMO hm2 firmware is like a masterpiece that makes this quite a bit more portable and settles alot of the prior work.
Again one of the frustrating things in MK is figuring out what is going on and minor things when the major work to make it easily usable is already done. Current state seems to be like a few missing pieces to a documentation puzzle that is otherwise complete. Modifying a pinfile on the user's end is super easy, it's those missing pieces that make it a bit more difficult. You can buy the boards you mentioned individually from Arrow https://www.arrow.com/en/products/us02-0001/exor-embedded-srl. Problem with those is that they're about double the price of a DE10 and stuff like hdmi and ethernet would have to be routed through daughtercard as well since the connectors are not onboard, which adds more to the cost of the external hardware. The BBB requires additional HW as well, it's not field ready in any way without a cape. I'm not fully upto snuff on BBB but I was originally intending to make a hybrid board to use either the DE10 or BBB but the BBB was starting to erk me with all the conditional pin states....adding this disables that, you can do this but not if you do that, use this PRU don't use that one, you don't really need the PRUs....just a headache when the DE10 has 72 I/O pins from the FPGA.......do whatever you want with any one of them. Routing a PCB is greatly simplified when the only thing you really care about is tracking close to the pin when the pin can do whatever you want it to. The state of ARM itself in the Linux world is likely to improve, hopefully sometime during the 5.x kernel lifespan will make ARM socs less dependent on vendor kernels so cobbled up images may see less use and the ARM world will get a little closer to the x86 world. Intel owns Alterra so even though they say they won't be putting x86 inside an socfpga, well we'll see. Smaller nodes make that easily possible. ARM is like MK in a way so they're perfect for each other. People think ARM is for cell phones and don't realize how powerful it really can be if the support and infrastructure exists......instead, cobbled up images relying on vendor patched Linux Kernels. On Sat, Sep 21, 2019 at 4:08 AM Bas de Bruijn <[email protected]> wrote: > > > 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 > <https://groups.google.com/d/msgid/machinekit/4eb48782-49fc-40ec-b7e0-a52d1d8e8f8d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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/CA%2BQ02MP5Frg2R5FzNM6DNRFmZ9VLnNjpff%3DDsFbjxq3x3jzQiw%40mail.gmail.com.
