You can do all sorts of fancy stuff - with realtime tucked comfortably in the computer... (not excluding torch height control all within linuxcnc)
https://www.youtube.com/shorts/nViXP9SsdWc Linuxcnc is like a large real time lego set... sam On Sun, Apr 17, 2022 at 8:42 PM Rod Webster <r...@vehiclemods.net.au> wrote: > So Andy's post brings is right back to Peters comment > > Basically just following the LinuxCNC model of having the host be the > > locus of control. This is the basic difference between buffered systems > > like Mach and LinuxCNC. By having the LinuxCNC host be the controller > > you gain a number of advantages: > > > 1. The external hardware is simpler (and more uniform) > > 2. The more complex parts of the control are located on a host > > with basically unlimited memory and CPU capabilities so real time > behaviour > > is extensible by a large group of users/developers using standard tools. > > 3. Specifically, returning actual position allows use of the following > > error mechanism for tuning and robust fault detection without a side > > channel of status information. > > > Aside from continual improvement to the core tc (trajectory controller), > The hidden gem in Linuxcnc is the ability to write your own components in C > that are compiled and installed with a single command. Once implemented in > hal (hardware extraction layer) via your hal file with loadrt and addf > commands, your custom component has access to that infinite memory and CPU > capability AND it is treated as if it is part of the Linuxcnc core viar the > controlling servo thread. > > Whether it is possible to use a serial modbus encoder in the real time > environment might be problematic though. You might be able to use external > hardware with a UART (perhaps from Mesa) that accumulated the encoder count > for linuxcnc to read every millisecond. In theory, you should only need one > UART in a multidrop environment but whether a serial protocol would be fast > enough to service all encoders in a single servo thread cycle would be a > moot point. > > If you wanted an alternative to Mesa there are always solutions from Jon or > you could use ethercat. Linuxcnc will not care at the tc level. > > Rod Webster > *1300 896 832* > +61 435 765 611 > Vehicle Modifications Network > www.vehiclemods.net.au > > > On Mon, 18 Apr 2022 at 10:00, andy pugh <bodge...@gmail.com> wrote: > > > On Sat, 16 Apr 2022 at 00:42, Torsten Curdt via Emc-developers > > <emc-developers@lists.sourceforge.net> wrote: > > > > > IIUC the GCODE interpreter runs in the non-realtime part. It sends the > > step > > > instructions to a card to execute the steps. This is obvious when > using a > > > LPT port, but how does this work via Ethernet? > > > > There are some steps missing here that have not been explained in > > later posts which might explain the process. > > > > The interpreter, as you said, runs in user space, it reads G-code and > > converts it in to "canonical commands" which are fed to the motion > > queue. > > These commands are the basic things that a CNC machine needs to do. It > > is worth noting that many G and M-codes only affect the internal > > status of the interpreter, and that is partly why the program line > > counter skips non-movement commands, they simply don't exist in te > > queue) > > Also, the interpreter is a pluggable module, it doesn't have to be > G-code. > > > > There are several steps from here, including converting the commands > > into NML messages ( > > > > > https://www.nist.gov/publications/neutral-message-language-model-and-method-message-passing-heterogeneous-environments > > ) but eventually the commands get to the "trajectory planner" (tp) > > (userspace) where they are put into the motion queue, which is > > consumed by the (realtime) "trajectory controller" (tc). > > > > Every 1mS the tc calculates new positions for all axes, and puts those > > positions on to HAL pins. > > > > What happens next depends on the system. With an LPT system the HAL > > "stepgen" component 1mS thread reads how many steps have been made in > > the last period, and from that and the new position calculates the > > required step-rate to hit the new position at the end of the current > > period. Then, in the fast thread the (integer maths only) step > > generator makes the pulses. > > > > With a Mesa or Pico stepper system there is no fast thread, the HAL > > driver does the same calculations as the LPT driver, though, but > > passes the required step rate through PCI, EPP, SPI or ethernet to the > > FPGA (or processor) on the card by writing to registers on the card. > > > > So, the cards are doing very little. > > > > As far as I know an ethernet smoothstepper does not do this. I don't > > even think that they "buffer" as is often suggested. In fact I think > > that they move all of the "tc" on to the hardware. So probing and > > spindle-synched motion is handled inside the card, not on the host > > controller. > > > > -- > > atp > > "A motorcycle is a bicycle with a pandemonium attachment and is > > designed for the especial use of mechanical geniuses, daredevils and > > lunatics." > > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > > > > _______________________________________________ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
