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
