I think we perhaps need to take a step back before this turns into a series of unworkable positions.
The 3D printers with Arduino based controllers work because they are dedicated to what they do. For the same reason my ELS project using only an 8 bit PIC controller is very good at what it does but it will never be able to do G-Code or trajectory planning because it was designed with a specific behaviour in mind but it's a simple 1PPR sensor on the spindle which has limitations but also advantages. Similarly the Electronic Gearing Systems (often called an ELS) use spindle encoder pulses divided or multiplied to generate step pulses. The desire to rotate a chuck to simulate gears is very dear to many even though it will snap a carbide insert in a heartbeat if there is backlash in the lead screw. But that manual approach is considered important. And discounted very quickly as not important is anything above about 2500 RPM because at that point the Arduino can't keep up. The Beagle is interesting because it has the two hardware co-processors but the Beagle OS has a lifetime of 1 to 2 years before something dramatically is changed and all existing software is broken. Might well be open source but whatever is built for it should probably not use Linux and instead a standard RTOS (Real Time Operating System) So why are the dedicated systems popular? Simple. Once you buy them you don't get upgrades. They just work. You don't have to learn a new user interface. But they also only run on that hardware. If you wanted MODBUS or CANbus control it's unlikely that feature is available. If you have 2 spindles, one vertical, one horizontal it's possible you also can't use it. But more than anything the good thing, and at the same time the really really bad thing, is the concept of the hardware abstraction layer; the HAL. The dedicated boxes set/clear a bit in port_X to enable the coolant pump. The Linux systems open a file, write to the file, close the file and under the covers thousands of instructions later somewhere way deep down the code sets/clears a bit in port_X if it's on the motherboard. Otherwise it sets/clears a bit in a UDP packet which, on the next 'tick' is sent out serially over Ethernet at, granted, high speeds to the control board which pulls apart the packet and sets/clears a bit in port_X. Or it's in a CAN bus message or it's in a USB message. And the current electronics now, compared to 40 years ago, can easily do this because the basic mechanics hasn't really changed that much. The problem is that companies like Apple and Microsoft have blurred the lines between what the OS is and what the device is/does. As I understand it Apple uses Linux under the covers. Certainly Android does. And I've heard that Microsoft is heading in that direction. But what they are using is the pseudo RTOS (not quite real time). Now we have a number of different RTOS systems from the FREE RTOS to subscription and even the real time Linux variant which is free but understood by few. And again that's where the very useful HAL comes in. Any RTOS, any Controller, any Network, any text or Graphical User Interface (GUI) and any kind of hardware. The basic setup screens for LinuxCNC for either parallel port or Peter's MESA stuff is amazing and simple until you need to step outside the box. And I think, if I were to summarize this I'd say software needs to be designed so the command line editor is never ever used. Those two sets of config screen sets are what have allowed most people to set up LinuxCNC. Take those away, tell them they have to write the HAL and INI file from scratch and watch them run, quickly, to alternate systems. Enough rambling for now. John > -----Original Message----- > From: Chris Albertson [mailto:albertson.ch...@gmail.com] > Sent: December-24-21 3:10 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] Choice of CNC conversions > > No, RT patches are not a waste of time. But using something as big as a > Linux based PC to drive a machine is not going to be popular today and > will be even less so in 10 years. 40 years ago the PC is the only > affordable computer that had enough compute power. This is not longer > true. we now have 32-bit microcontrollers and FPGAs. al for under $20. > > Look at a typical hobby R/C servo. The cheapest one on Amazon is $5 (The > MG996). Inside there is a digital motor controller that measures the input > pulse with in microseconds and reads an analog voltage from the position > encoder. It uses a PID control loop to adjust the motor's current via an > H-bridge to keep the output shaft at the commanded set point. The entire > device, computer. motor, gears and all, sells for $5 on Amazon. That $5 > servo Is reliably measuring at the sub uSec level. Something a PC can't > do. In the 80's these servos were analog because you would need something > like an IBM PC to implement a PID loop. > > Nothing wrong with using LCNC, I use it. But we were talking about why a > person starting out would pass on it. It is just not what people would do > today. Today, I buy something, I expect to turn it on and then maybe > download the phone app that let's me control it. I don't expect to edit > text files to make by video doorbell work > > I'm not suggesting anyone do anything, just explaining why LCNC is not > taking over the world. People will go for the $300 box that is plug and > play 80% of the time. People want support and a warenty. > > On Fri, Dec 24, 2021 at 11:07 AM Sam Sokolik <samco...@gmail.com> wrote: > > > Hmm.. so the realtime patches being integrated into Linux kernel is > > worthless old technology? They are waisting their time? (This is > > unrelated to LinuxCNC) > > > > Currently LinuxCNC is being added to debian testing. It will soon be part > > of the debian repository. > > > > On Fri, Dec 24, 2021, 12:54 PM Chris Albertson <albertson.ch...@gmail.com> > > wrote: > > > > > The problem that is limiting LCNC's wider use is that it is a very old > > > design. It is definitely not what anyone would design today. And it is > > > not what moderned users expect or want. Documentation i=will not change > > > what it is. > > > > > > Today, if this were being built again from scratch it would > > > > > > Run on any computer and not require some special real-time version of > > > Linux. The user interface would be written in some portable way so it > > > could be accessed even on a iPad or Andriod tablet or from macOS or > > > Windows. This is possible. I proved it to myself just a few days > > > ago. I have a 12 DOF robot here that is being driven by a Raspberry Pi > > > and the user interface is web-based or X11 based and in theory, should > > work > > > on other platforms. > > > > > > Should not need a real-time OS on the computer. The real-time stuff (al > > > of it) goes in hardware, Leaving only not-t=real-time tasks to the > > > PC/Mac/iPhone > > > > > > It would configure 100% with no need to edit a single file by hand. > > > > > > It would have a conversational system so that a user could do simple > > things > > > with no need to write g-code. > > > > > > People care less about if it is free then if it acts like the above. > > > > > > What I would do is design some kind of real-time module. Perhaps that > > > would be made of Mesa cards with different firmware or of > > microcontrollers > > > like "Teensy" and each of these could handle some number of axies. Maybe > > > four. Then you use multiple of these to drive a larger machine of a > > > robot. > > > > > > The 1980's was 40 years ago. Yes it really has been that long. LCNC is > > > using 1980s software technology and people today are expecting the 21st > > > century and mostly getting what they expect. Think of a basic 3D > > > printer. It is no different from a milling machine just mechanically > > > lighter weight. The whole thing, g_code interpreter and all is a cheap > > > package with a self-contained controller One does not need to hunt > > > dumpsters for antique desktop PCs and then install specialist OSes on > > > them. The controller is built-in and pre-programmed. > > > > > > That said. I use LCNC because it does what I want and uses the 40 years > > > old (maybe 50 years old now) technology I'm familiar with. Yes it is > > that > > > Old. I was a computer science student back when this wascutting edge and > > > I'm retired now. > > > > > > Big goals for any new system should be > > > 1) cross platform, especially mobile device friendly > > > 2) zero file editing (zero, not just a small number) > > > 3) modular, you can swap out parts and add parts as requirements change. > > > 4) today we have "The Cloud" It could live at Amazon or in your own > > shop. > > > Some prefer to let a big company manage things, others like to buy their > > > own equipment is mess with it themselves. Either way should work. > > But a > > > modern CNC system would run any number of mills and lathes and laser > > > cutters and have any number of user interface screens and pendants. Jobs > > > are moved and assigned to available shop equipment as needed. The cloud > > > (local or remote, acts as a kind of NxM switch with storage and > > computation > > > while the local controller talks to motors. Today, I expect "job > > > persistence" as I move between screens that are on my Phone or in the > > > office of the shop. The cloud connects running processes that are on a > > > milling machine with the design files and operator screens while the > > > microsecond-level real-time jobs are handled by any number of little > > > controllers. TodayI'd add cameras to the system too. I decent model > > is > > > "Octoprint". I can control or monitor prints from any screen. Any > > > screen in the building or in my pocket could control any screen with no > > > handoff required. Just sign-on and your work is there. > > > > > > The problem is that all of the above would take many man-years of > > > development and there is no motivation to work on this for free. There > > > needs to be some kind of business model. Some conly has to design they > > > will develop this andthen make a living by consulting and hosts cloud > > > processes. > > > > > > But without an changes LCNC will be using 60 year old tech inanother 10 > > > years, then 70 and so on. It is already a non-starter in the eyes of > > many > > > people. it will just get more and more that way. > > > > > > The market for this is huge. Some one could make millions but the up > > front > > > effort and the existing big players will prevent that. > > > > > > > > > On Fri, Dec 24, 2021 at 2:46 AM J�r�mie Tarot <silopo...@gmail.com> > > wrote: > > > > > > > Hi, > > > > > > > > Le jeu. 23 d�c. 2021 � 20:05, John Dammeyer <jo...@autoartisans.com> a > > > > �crit : > > > > > > > > > ... > > > > > > > > But I wonder if it wouldn't be a good idea in the new year to develop a > > > > > build thread that takes a beginner through conversion of a mill to > > LCNC > > > > so > > > > > it appears to be turnkey like the perhaps the ACORN CNC approach. > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > > While working on docs translations migration and thinking about future > > > > documentation work, "my" idea along this line would be to > > > develop/document > > > > a set of "reference implementations" to be used as plug and play > > recipes > > > or > > > > basis for adaptation. > > > > > > > > These would cover all the usual suspects of DIY CNC projects like > > router, > > > > laser, plasma, mill, lathe builds/conversion/retrofits. > > > > These docs may provide infos for the size sensitive components for the > > > > reader to adapt. > > > > > > > > Another (complementary) approach would be to add to the docs a library > > of > > > > well crafted howtos about the setup of the various subsystems like > > > motion, > > > > spindle/torch, coolant, limits, e-stop... Some kind of decision tree > > > could > > > > be provided to lead the implementor who'd find the appropriate support > > > doc > > > > for each choice he'd make. > > > > > > > > For those of us that like to tinker with machines anyway, LinuxCNC is > > > > already just great... For the rest of the world that'd better have a > > > > machine that they can use to make stuff, we need to provide setups that > > > > "just work" in a way or another. > > > > > > > > Willing to work on this after docs migration and french translation is > > > > done. I'm all in to bring LinuxCNC goodness to the masses without > > putting > > > > the burden on the devs who I'd rather have working on fancier things > > for > > > > the future... > > > > > > > > As I may be unable to build an actual machine for the foreseable > > future. > > > I > > > > plan to start building docs using vismach, then move to tabletop/lab > > > setups > > > > with small real components, etc... > > > > > > > > All these reference docs could have a category and a dedicated thread > > in > > > > the forum to hold discussions, requests and criticisms. > > > > > > > > TY > > > > J�r�mie > > > > > > > > _______________________________________________ > > > > Emc-users mailing list > > > > Emc-users@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > -- > > > > > > Chris Albertson > > > Redondo Beach, California > > > > > > _______________________________________________ > > > Emc-users mailing list > > > Emc-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > _______________________________________________ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > -- > > Chris Albertson > Redondo Beach, California > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
