Yes it could work that way. There are Arduino based g-code interpreters. I have one on my 3D printer. A 3D printer is a four-axis stepper motor based machine. So it is certainly possible to run something like LinuxCNC on a very low-end chip. The Arduino uses a 16 Mhz 8-bit chip.
But that is not what I am suggesting. I'm suggesting the microcontroller gets a set of points in 3D space and the time to hit each point. then the controller only has to move the motors in a synchronized way so as to hit the points, each one at the specified time. Because the points are time-tagged that can be sent in batches in non-real time. The machine that sends the points can read the g-code files or maybe some other kind of file or maybe it is reading a hand help pendent. But in either case, the input is converted to a set of points to be hit at a spec'd speed. Because there are time tags on the data the machine that reads g-code need not be real-time. Or maybe we called it "very soft" real-time where one-second latency is acceptable. This process could run on a PC or a Mac or maybe even a phone. The goal is to push ALL, every bit of the hard real-time work onto a small chip that runs a "real" RTOS. I did not invent this. Someone figured it out years ago that if the commands are time-tagged and queued that the sender is no longer real-time couped to the device that dequeues and executes the commands. LinuxCNC does not do this so we have RT requirements backed up all the way to nearly every part of the system. On Sat, Jan 25, 2020 at 2:43 PM Alan Condit <condit.a...@gmail.com> wrote: > Chris, > > I am just trying to figure out your idea? Who parses the gcode file? The $5 > chip? > If you are running everything but the user interface on the $5 chip, it > sounds like headless lcnc to me. > > If you are running 6 axis on the $5 chip then you have all the wiring > complexities that we have now. The $5 chip needs to connect to a breakout > board something > like that to protect the chip and it (the $5 chip) needs to be located > someplace where it is convenient to wire all the axises from. So other than > the difference in cost what does this $5 chip buy you? > > Alan > > > > From: Chris Albertson <albertson.ch...@gmail.com> > > To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net > > > > Cc: > > Bcc: > > Date: Fri, 24 Jan 2020 21:56:18 -0800 > > Subject: Re: [Emc-users] Real-time OS for machine controllers > > On Fri, Jan 24, 2020 at 8:29 PM Alan Condit <condit.a...@gmail.com> > wrote: > > > > > Chris, > > > > > > If I send 10000 steps to a smart X-axis controller, how does it stay in > > > sync with a smart > > > y-axis controller without someone controlling the synchronization > between > > > the two? > > > > > > > As said, "steps" are the wrong thing to send. What they do is send > time, > > tagged points. Each point has a time tag on it. It is not hard to > > synchronize clocks at the microsecond level. > > > > What they send is a list of target points. Assuming the machine works > in > > (x, y, z) space each point, you have "time", (x, y, z) and (x', y', z') > and > > (x'', y'', z''). A machine might have more or fewer axis with different > > names, but same idea. Each controller can handle up to some maximum > > number of axis and it wold not be until you are over that limit that > you'd > > have to split things. Doing six axis on one controller is reasonable. > > > > The controller tries its best to hit the target points. It can happen > that > > a target is impossible. Also, some of ths data can be omitted. Doing so > > wuld free the controller to do what it "wants". I think you always want > > x,y,z but could maybe omit the prime (velocity) or double prime > > (acceleration) This kind of path planning is what LinuxCNC already does, > > but today it is reasonable to push this down into a $5 chip. > > > > LinuxCNC is originally written used the exact oposite aproach and move > all > > the "smarts" upstream into a PC. > > > > The non-real-time part has to read the g-code or the conversational > > interface or the hand pendant or video data and convert to a stream of > > target points. > > > > That said, "steps" could work if each one had a time tag. But that > pushes > > the planning upstream and I think the better plan is to move as much > > "smarts" as possible as close to the physical motor as possible. So let > > the motor driver figure out what rate to drive each otor so the targets > are > > reached. > > > > > > > > Alan > > > > > > _______________________________________________ > 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
