Re: [Emc-developers] curious about the ethernet protocol
On 4/20/22 13:26, Torsten Curdt via Emc-developers wrote: But to me the whole idea breaks down when using a Closed Loop Stepper or a Servo. At least unless you feed the encoders into LinuxCNC it seems to heavily weaken the idea. Yes, that's the whole idea! The encoder is read by LinuxCNC, PID processes the difference between commanded and actual position, and sends out commands to the motor drive to minimize error. LinuxCNC originally came from the servo world, and various stepper "back ends" were later applied. You make it sound so common :) Are there boards where you can just connect the 4 encoder pins and turn that into two signals to read by LinuxCNC? (as Gene suggested) Yes, Pico Systems, Mesa, and a few others. And let's say the closed loop driver tries to fix the difference between commanded and actual position - you would still also feed the encoders through to LinuxCNC? Couldn't the two loops cause problems? If you use a velocity servo drive, then MOST of the gain is in the drive, and the PID loop is just keeping small errors from creeping in. I (Pico Systems) make 3 different systems for use with LinuxCNC. First came the PPMC, which was an expandable system to control analog velocity servos. Then, I came up with a stepper controller, which had encoder counters and step generators. On that, the encoder counters could be selected to count the steps produced, so it could run open-loop. Then, I hacked up that unit to generate PWM instead of steps (constant pulse rate, varying pulse width) to control servo motors. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
The Fanuc drives on the mill used Fanus feedback but the drive had quad output so I connected that to LinuxCNC easy peasy simple On Wed, Apr 20, 2022 at 5:59 PM Stuart Stevenson wrote: > use the encoder feedback on both the motor drive and LinuxCNC > > On Wed, Apr 20, 2022 at 5:38 PM Sam Sokolik wrote: > >> Linuxcnc doesn't care where you close the feedback loop (linuxcnc always >> closes the feedback loop). Simple step/direction closes the loop between >> the step-gen and linuxcnc. >> >> >> >> sam >> >> On Wed, Apr 20, 2022 at 3:57 PM Torsten Curdt via Emc-developers < >> emc-developers@lists.sourceforge.net> wrote: >> >> > > > That said - that's a dual loop with two different encoders. >> > > > That's not really the same dual loop when you have LinuxCNC and a >> > Closed >> > > > Loop Stepper/Servo Driver. >> > > >> > > If you only have one feedback source, how can you have a dual feedback >> > > loop? With the feedback closed on the driver, your joint will be >> treated >> > as >> > > if its open loop by linuxcnc. >> > > Yes, Linuxcnc will use a pid but its generally not aware of the >> drive's >> > > encoder. Its just dealing with step and direction pulses. >> > > >> > >> > That is exactly the point I was trying to make. >> > I guess the closed loop on the driver will do a decent job. >> > But such a system does not really seem to be in the full spirit of >> LinuxCNC >> > being in control. >> > >> > ___ >> > 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 >> > > > -- > Addressee is the intended audience. > If you are not the addressee then my consent is not given for you to read > this email furthermore it is my wish you would close this without saving or > reading, and cease and desist from saving or opening my private > correspondence. > Thank you for honoring my wish. > > -- Addressee is the intended audience. If you are not the addressee then my consent is not given for you to read this email furthermore it is my wish you would close this without saving or reading, and cease and desist from saving or opening my private correspondence. Thank you for honoring my wish. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
use the encoder feedback on both the motor drive and LinuxCNC On Wed, Apr 20, 2022 at 5:38 PM Sam Sokolik wrote: > Linuxcnc doesn't care where you close the feedback loop (linuxcnc always > closes the feedback loop). Simple step/direction closes the loop between > the step-gen and linuxcnc. > > > > sam > > On Wed, Apr 20, 2022 at 3:57 PM Torsten Curdt via Emc-developers < > emc-developers@lists.sourceforge.net> wrote: > > > > > That said - that's a dual loop with two different encoders. > > > > That's not really the same dual loop when you have LinuxCNC and a > > Closed > > > > Loop Stepper/Servo Driver. > > > > > > If you only have one feedback source, how can you have a dual feedback > > > loop? With the feedback closed on the driver, your joint will be > treated > > as > > > if its open loop by linuxcnc. > > > Yes, Linuxcnc will use a pid but its generally not aware of the drive's > > > encoder. Its just dealing with step and direction pulses. > > > > > > > That is exactly the point I was trying to make. > > I guess the closed loop on the driver will do a decent job. > > But such a system does not really seem to be in the full spirit of > LinuxCNC > > being in control. > > > > ___ > > 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 > -- Addressee is the intended audience. If you are not the addressee then my consent is not given for you to read this email furthermore it is my wish you would close this without saving or reading, and cease and desist from saving or opening my private correspondence. Thank you for honoring my wish. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
Linuxcnc doesn't care where you close the feedback loop (linuxcnc always closes the feedback loop). Simple step/direction closes the loop between the step-gen and linuxcnc. sam On Wed, Apr 20, 2022 at 3:57 PM Torsten Curdt via Emc-developers < emc-developers@lists.sourceforge.net> wrote: > > > That said - that's a dual loop with two different encoders. > > > That's not really the same dual loop when you have LinuxCNC and a > Closed > > > Loop Stepper/Servo Driver. > > > > If you only have one feedback source, how can you have a dual feedback > > loop? With the feedback closed on the driver, your joint will be treated > as > > if its open loop by linuxcnc. > > Yes, Linuxcnc will use a pid but its generally not aware of the drive's > > encoder. Its just dealing with step and direction pulses. > > > > That is exactly the point I was trying to make. > I guess the closed loop on the driver will do a decent job. > But such a system does not really seem to be in the full spirit of LinuxCNC > being in control. > > ___ > 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
Re: [Emc-developers] curious about the ethernet protocol
> > That said - that's a dual loop with two different encoders. > > That's not really the same dual loop when you have LinuxCNC and a Closed > > Loop Stepper/Servo Driver. > > If you only have one feedback source, how can you have a dual feedback > loop? With the feedback closed on the driver, your joint will be treated as > if its open loop by linuxcnc. > Yes, Linuxcnc will use a pid but its generally not aware of the drive's > encoder. Its just dealing with step and direction pulses. > That is exactly the point I was trying to make. I guess the closed loop on the driver will do a decent job. But such a system does not really seem to be in the full spirit of LinuxCNC being in control. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
Gentlemen, Of the 5 machines I have put LinuxCNC on every one was closed loop servo with LinuxCNC tuning the already tuned closed loop. The machines all ran just fine. One of them was configured using the 'encoder' feedback connected to the P and D and a linear scale connected to I. This machine ran and moved just fine tuning using P and D and final position using I. I have always wondered what it would be like to tune using a dumb amp and only LinuxCNC in the loop. Probably not much better than I had. The only stepper experience was a six axis robot. Chris Radek configured three axes, we clamped a sharpie to the end effector and drew the LinuxCNC example program with me holding a piece of cardboard up to the sharpie. I drew the tool path on the cardboard. thanks Stuart On Wed, Apr 20, 2022 at 3:28 PM Torsten Curdt via Emc-developers < emc-developers@lists.sourceforge.net> wrote: > > > Could you do e.g. rigid tapping when there is a LinuxCNC and another > PID > > > loop on the motor driver? > > > > Granite devices has a good description of dual feedback loops (and a > > mention for linuxcnc). The inner velocity feedback loop is normally > closed > > on the drive and the outer position loop by Linuxcnc > > https://granitedevices.com/wiki/Dual-loop_feedback_position_control > > > Wow! That's great. Very interesting. Thanks for the link. > > That said - that's a dual loop with two different encoders. > That's not really the same dual loop when you have LinuxCNC and a Closed > Loop Stepper/Servo Driver. > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > -- Addressee is the intended audience. If you are not the addressee then my consent is not given for you to read this email furthermore it is my wish you would close this without saving or reading, and cease and desist from saving or opening my private correspondence. Thank you for honoring my wish. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > That said - that's a dual loop with two different encoders. > That's not really the same dual loop when you have LinuxCNC and a Closed > Loop Stepper/Servo Driver. If you only have one feedback source, how can you have a dual feedback loop? With the feedback closed on the driver, your joint will be treated as if its open loop by linuxcnc. Yes, Linuxcnc will use a pid but its generally not aware of the drive's encoder. Its just dealing with step and direction pulses. Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Thu, 21 Apr 2022 at 06:26, Torsten Curdt via Emc-developers < emc-developers@lists.sourceforge.net> wrote: > > > Could you do e.g. rigid tapping when there is a LinuxCNC and another > PID > > > loop on the motor driver? > > > > Granite devices has a good description of dual feedback loops (and a > > mention for linuxcnc). The inner velocity feedback loop is normally > closed > > on the drive and the outer position loop by Linuxcnc > > https://granitedevices.com/wiki/Dual-loop_feedback_position_control > > > Wow! That's great. Very interesting. Thanks for the link. > > That said - that's a dual loop with two different encoders. > That's not really the same dual loop when you have LinuxCNC and a Closed > Loop Stepper/Servo Driver. > > ___ > 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
Re: [Emc-developers] curious about the ethernet protocol
> > Could you do e.g. rigid tapping when there is a LinuxCNC and another PID > > loop on the motor driver? > > Granite devices has a good description of dual feedback loops (and a > mention for linuxcnc). The inner velocity feedback loop is normally closed > on the drive and the outer position loop by Linuxcnc > https://granitedevices.com/wiki/Dual-loop_feedback_position_control Wow! That's great. Very interesting. Thanks for the link. That said - that's a dual loop with two different encoders. That's not really the same dual loop when you have LinuxCNC and a Closed Loop Stepper/Servo Driver. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > Could you do e.g. rigid tapping when there is a LinuxCNC and another PID > loop on the motor driver? Granite devices has a good description of dual feedback loops (and a mention for linuxcnc). The inner velocity feedback loop is normally closed on the drive and the outer position loop by Linuxcnc https://granitedevices.com/wiki/Dual-loop_feedback_position_control Ethercat is an industry standard from Beckhoff https://www.beckhoff.com/ that allows slave devices to be daisy chained via ethernet cables and coordinated by an ethercat master. There is a driver interface for linuxcnc to the IgH Etherlabmaster master https://etherlab.org/en/ethercat/ that is installed on your linuxcnc PC. Linuxcnc works in much the same way as if the ethercat master was any other external device like mesa. Ethercat can span a whole factory so the added complexity and cost may not be warranted for a much smaller cnc machine. Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Thu, 21 Apr 2022 at 04:46, andy pugh wrote: > On Wed, 20 Apr 2022 at 17:55, Torsten Curdt via Emc-developers > wrote: > > > > > 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. > > > > I am falling short on finding those. > > Do you have a link? > > https://pico-systems.com/motion.html > > There is also all the stuff listed here: > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_Supported_Hardware > > -- > 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
Re: [Emc-developers] curious about the ethernet protocol
On Wed, 20 Apr 2022 at 17:55, Torsten Curdt via Emc-developers wrote: > > > 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. > > I am falling short on finding those. > Do you have a link? https://pico-systems.com/motion.html There is also all the stuff listed here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_Supported_Hardware -- 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
Re: [Emc-developers] curious about the ethernet protocol
On Wed, 20 Apr 2022 at 17:53, Torsten Curdt wrote: > Does the HAL get the absolute Positions? And that gets translated into > velocities? It actually gets target feedback values, after homing. ie positions scaled according to the encoder counts or step counts that applied when it was homed. It needs to be this, or the PID wouldn't work. Then it's the HAL stepper drivers that calculate the required step frequency to achieve the position. > But to me the whole idea breaks down when using a Closed Loop Stepper or a > Servo. > At least unless you feed the encoders into LinuxCNC it seems to heavily > weaken the idea. It still means that you can send axis positions calculated from spindle encoder position, for tapping and threading, for example. Or, for that matter, other fun things like drilling hexagonal holes: https://youtu.be/PtD9w6lp8n8 -- 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
Re: [Emc-developers] curious about the ethernet protocol
> > But to me the whole idea breaks down when using a Closed Loop Stepper or > a > > Servo. > > At least unless you feed the encoders into LinuxCNC it seems to heavily > > weaken the idea. > > Yes, that's the whole idea! The encoder is read by > LinuxCNC, PID processes the difference between commanded and > actual position, and sends out commands to the motor drive > to minimize error. LinuxCNC originally came from the servo > world, and various stepper "back ends" were later applied. > You make it sound so common :) Are there boards where you can just connect the 4 encoder pins and turn that into two signals to read by LinuxCNC? (as Gene suggested) And let's say the closed loop driver tries to fix the difference between commanded and actual position - you would still also feed the encoders through to LinuxCNC? Couldn't the two loops cause problems? cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On 4/20/22 11:53, Torsten Curdt via Emc-developers wrote: But to me the whole idea breaks down when using a Closed Loop Stepper or a Servo. At least unless you feed the encoders into LinuxCNC it seems to heavily weaken the idea. Yes, that's the whole idea! The encoder is read by LinuxCNC, PID processes the difference between commanded and actual position, and sends out commands to the motor drive to minimize error. LinuxCNC originally came from the servo world, and various stepper "back ends" were later applied. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> Also, the interpreter is a pluggable module, it doesn't have to be G-code. > That's a great design. Every 1mS the tc calculates new positions for all axes, and puts those > positions on to HAL pins. > Does the HAL get the absolute Positions? And that gets translated into velocities? I am asking because Peter said that the Mesa card receives velocity information. 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. > Andy, thank you so much for taking that time to write that up. This is a fantastic explanation. This should go into the docs like this. 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. > ...and that's why the smoothstepper would not work with LinuxCNC. IIUC? (Unless there is a different firmware for it. Similar to what Remora does.) I think I get the idea of having as much motion feedback on the host to be able to do flexible planning. (I am thinking of rigid tapping here.) But to me the whole idea breaks down when using a Closed Loop Stepper or a Servo. At least unless you feed the encoders into LinuxCNC it seems to heavily weaken the idea. It should give a stable and high step frequency - sure. But is it really such a big win there is at best a "following error" alarm as feedback to the tp? (better than nothing I guess) Could you do e.g. rigid tapping when there is a LinuxCNC and another PID loop on the motor driver? I totally get that it is much better to have the stepgen on card that does this in real time. Almost synchronized steps with a fast MCU, or completely synchronized with a FPGA. But as soon as there is another PID loop involved - I am wondering if it's worth "the fuss". LinuxCNC would never have the full information for the planning. Hence I brought up the question whether a plain stepper with an external encoder would actually be more in the spirit of LinuxCNC. cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > 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. > That is indeed very cool. > 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. I am not even sure the encoder count is actually available. What is available is a way to poll the following error in steps. The question is how to give that feedback to the motion planner. Given the UART connection it would certainly need some kind of buffering (eek!). I guess the next best thing would be if the servos was able to give the "following error" alarm to the host, but have them not go into "stop the world" error mode. So the host could slow down and the servo would recover. I need to check if that is possible. That would make that just be a single bit per motor. Could that information be used in the planning? > 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. > I am falling short on finding those. Do you have a link? It's not really that I "want" an alternative to Mesa ;) I just don't think I'll see a 7i76E available any time soon. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Mon, 18 Apr 2022, andy pugh wrote:
Date: Mon, 18 Apr 2022 00:59:07 +0100
From: andy pugh
Reply-To: EMC developers
To: EMC developers
Subject: Re: [Emc-developers] curious about the ethernet protocol
On Sat, 16 Apr 2022 at 00:42, Torsten Curdt via Emc-developers
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?
Snip-
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.
An external card with a TC probably has multiple levels of buffers...
(back when we made some MACH 3 compatible hardware, it was in fact buffered
PVTA motion so Mach3 did the trajectory planning and the external hardware
just played out a PVTA sequence from a FIFO)
--
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
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
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 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 wrote: > > > On Sat, 16 Apr 2022 at 00:42, Torsten Curdt via Emc-developers > > 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 > > design
Re: [Emc-developers] curious about the ethernet protocol
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 wrote: > On Sat, 16 Apr 2022 at 00:42, Torsten Curdt via Emc-developers > 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
Re: [Emc-developers] curious about the ethernet protocol
On Sat, 16 Apr 2022 at 00:42, Torsten Curdt via Emc-developers 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
Re: [Emc-developers] curious about the ethernet protocol
> > Unfortunately that circles back to the mesa availability problems :-( > > 5i25's are not available? I haven't checked recently. > You can almost replace the Mesa store by an out-of-stock sign ;) > Would a 7i92 also work? > > It looks like it would, its basicaly a 5i25 with a cat connector > replacing the pci interface of the 5i25 and if the H version is available > that would simplify cable making, db-25's have been problematic as the > cable can work loose in the center of the cap, losing 1 or more > connections. Urgh. Even when screwed in? I have not had similar problems with the 26 pin header style > and you can easily get both cables out to their respective bobs with only > one style of common connector. I also would prefer the H. But you guessed it - not in stock :-( Up to 5 feet, I don't worry about it. > Should be less - but good to know. I consider that just as > important, and explains why I went with a 7i90 on the pi, reflashed to an > SPI interface. Which on the pi's, writes a 32 bit serial data packet to > the 7i90 at 42 megabaud, and reads back at 25 megabaud. Apparently > without interference from the net port. That could probably be done with > a bash script, making it relatively painless. > I find SPI also quite interesting. But I am not aware of a PCI(e)-SPI card. I don't want to be tied to using the RPi. > Seems I either need to go with Remora or a Parallel BOB. > > And I would probably have to get a PCI/PCIe Parallel Port. > > I don't get any hits for cnc stuff out of a DDG search for Remora. link > url? > https://github.com/scottalford75/Remora-NVEM And the NVEM boards are at around 60-80 USD. Not a Mesa but... > > How come the 5i25 is faster? > > mobo parports are usually accessed thru the bios, which generally takes > some number of microseconds just to wade thru the bios code and do it. > The 5i25, sitting on the pci bus can update its outputs or read its > inputs in sub-microsecond time frames. > The parallel port I'd be getting would also be PCI/PCIe. So I guess that would be fine then. The old PC should arrive on Tue/Wed. Not sure what I will find. Fingers crossed :) So the advantage of a single 7I92 vs getting two PCI(e) Parallel Ports is that the Mesa holds the stepgen. Other than that it would be about the same - just connecting a simple 15 USD BOB. Right? ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sun, 17 Apr 2022, Torsten Curdt via Emc-developers wrote:
Date: Sun, 17 Apr 2022 13:47:40 +0200
From: Torsten Curdt via Emc-developers
To: EMC developers
Cc: Torsten Curdt
Subject: Re: [Emc-developers] curious about the ethernet protocol
Maybe finding an old parallel port machine might still be the easier
route
:-/
Better yet, a pci-e buss and a 5i25 card.
5I25 is PCI
6I25 is PCIE
7I92 is Ethernet
Mesa still has 6I25s and 7I92s
a 5I25, 6I25 or 7I92 are basically interchangable
Ethernet is especially good If there is a long distance between the
control PC and the drive box (larger machines)
Unfortunately that circles back to the mesa availability problems :-(
Would a 7i92 also work?
Seems I either need to go with Remora or a Parallel BOB.
And I would probably have to get a PCI/PCIe Parallel Port.
two parports lots faster than a mobo parport.
mobo = motherboard?
How come the 5i25 is faster?
cheers,
Torsten
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sunday, 17 April 2022 11:00:31 EDT Jérémie Tarot wrote: > Le dim. 17 avr. 2022 à 13:50, Torsten Curdt via Emc-developers < > > emc-developers@lists.sourceforge.net> a écrit : > > > > Maybe finding an old parallel port machine might still be the > > > > easier > > > > route > > > > > > > > :-/ > > > > > > Better yet, a pci-e buss and a 5i25 card. > > > > Unfortunately that circles back to the mesa availability problems :-( > > Would a 7i92 also work? > > 7i92+7i76 would surely do wonders! I'm using a 5i25+7i76 and a bob on two of my 4 machines, works quite well. The major diff is the cat5 interface at udp speeds. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sunday, 17 April 2022 07:47:40 EDT Torsten Curdt via Emc-developers wrote: > > > Maybe finding an old parallel port machine might still be the > > > easier > > > route > > > > > > :-/ > > > > Better yet, a pci-e buss and a 5i25 card. > > Unfortunately that circles back to the mesa availability problems :-( 5i25's are not available? I haven't checked recently. > Would a 7i92 also work? It looks like it would, its basicaly a 5i25 with a cat connector replacing the pci interface of the 5i25 and if the H version is available that would simplify cable making, db-25's have been problematic as the cable can work loose in the center of the cap, losing 1 or more connections. I have not had similar problems with the 26 pin header style and you can easily get both cables out to their respective bobs with only one style of common connector. That reduces you to only one db25 per cable unless you can find a bob that takes the 26 pin header. Those bob's are rare indeed. Because of the lack of termination resistors on a typical parport bob, if the cables are more than 5 feet, the data integrity would be improved by src terminating at the 7i92 by adding a nominally 120 ohm resistor in series as the ribbon cables impedance is nominally 120 to 130 ohms. The resistor absorbs a large part of the echo from the unterminated bob. Up to 5 feet, I don't worry about it. Note: I'm talking terminations not in the sense of screw terminal's but in terms of a transmission line's characteristic immpedance. VSWR IOW. However, unless your mobo has two ethernet ports, you'll have to disconnect the 7i92, plug in a cat6 to your switch/router and reconfigure the network to get online and update the pc. I consider that just as important, and explains why I went with a 7i90 on the pi, reflashed to an SPI interface. Which on the pi's, writes a 32 bit serial data packet to the 7i90 at 42 megabaud, and reads back at 25 megabaud. Apparently without interference from the net port. That could probably be done with a bash script, making it relatively painless. The huge disadvantage to that is that the 7i90 is those 50 pin scsi connectors are connected directly to the fpga, and needs 3 of the 7i42TA's to serve as fpga destroying noise absorbers, and gives you its 72 i/o's on the usual green termination facilities, while raising the cost to around $200 for all 4 pieces. The ease of wiring it up pays for the 7i42TA's IMO. At the time I built it, that was all that was available if you wanted a pi to talk to your machinery. That 7i90HD card can also be driven from a parport, and comes that way so must be reprogrammed with mesaflash to use the SPI. > Seems I either need to go with Remora or a Parallel BOB. > And I would probably have to get a PCI/PCIe Parallel Port. I don't get any hits for cnc stuff out of a DDG search for Remora. link url? > two parports lots faster than a mobo parport. > > > mobo = motherboard? Yup. > How come the 5i25 is faster? mobo parports are usually accessed thru the bios, which generally takes some number of microseconds just to wade thru the bios code and do it. The 5i25, sitting on the pci bus can update its outputs or read its inputs in sub-microsecond time frames. > cheers, > Torsten Take care and stay well. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
Le dim. 17 avr. 2022 à 13:50, Torsten Curdt via Emc-developers < emc-developers@lists.sourceforge.net> a écrit : > > > Maybe finding an old parallel port machine might still be the easier > > > route > > > :-/ > > > > Better yet, a pci-e buss and a 5i25 card. > > > Unfortunately that circles back to the mesa availability problems :-( > Would a 7i92 also work? > 7i92+7i76 would surely do wonders! ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > Maybe finding an old parallel port machine might still be the easier > > route > > :-/ > > Better yet, a pci-e buss and a 5i25 card. Unfortunately that circles back to the mesa availability problems :-( Would a 7i92 also work? Seems I either need to go with Remora or a Parallel BOB. And I would probably have to get a PCI/PCIe Parallel Port. two parports lots faster than a mobo parport. > mobo = motherboard? How come the 5i25 is faster? cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sunday, 17 April 2022 05:57:07 EDT Torsten Curdt via Emc-developers wrote: > > BUT my ballscrews are 05mm and planned for servo speeds. > > > > > I don't really want to go from the idea of the dynamic servo driven > > > machine to the stepper turtle :) > > > > All my stuff is steppers, but I wouldn't call a g0 move at 250 ipm a > > turtle. The whole steel framed table its on shakes. > > /me converts - that's 6.35 meter per minute - that's about 10.5cm per > second. > > I would suspect the dynamic movement (acc/dec) of a servo might > actually shake it less. Thats with accell/decel controls, steppers do that too, in LinuxCNC. > It seems like 500 ipm should be easily doable with a servo. But that's > still just reading/watching knowledge here. > > > Mach3's bob's can be used but my being a "CET" means they're not OOTB > > > CET means central european time to me - what does it mean to you? :) Certified Electronics Technician. Registered in Nebraska in 1972 as NEB-118, but the 118 was the count in the whole country. > > For folks who aren't comfy with a hot air rework soldering iron > > > surgically implanted in a right hand, that need does remove those $20 > > boards from consideration. Mesa and cnc4pc both make better bobs, but > > bring more money. > > Not an EE - but I had my first soldering iron when I was 7y :) Good, I think I was 9 yo. > > But,if you are going to use it to drive a spindle, which is "CCS" > > service. be sure and tell Jon when you order it. he'll change the > > toroid filters from ICAS to CCS, the ICAS version gets hot, the CCS > > versions doesn't. > > Why would they not be CCS? Servo's at rest don't use a lot of power. > > > Which made me curious and I started digging - down the rabbit hole > > > ;) > > > > Locally, that hole is more likely a gopher or ground hog hole. ;) > > Got more gophers than rabbits? :) Locally yes. > > > Hope that explains the status quo. > > > > Somewhat, but the ball screws at 5mm pitch is pretty much stock in > > what's commonly available. > > People usually build this CNC with 10mm pitch ball screws and open loop > 2.5Nm steppers with a parallel BOB. > I could go 2Nm or 3Nm closed loop steppers - but are still not much > wiser in terms of the boards. > > Maybe finding an old parallel port machine might still be the easier > route > :-/ Better yet, a pci-e buss and a 5i25 card. two parports lots faster than a mobo parport. > Happy Easter! > > cheers, > Torsten Back at you. > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> BUT my ballscrews are 05mm and planned for servo speeds. > > > > I don't really want to go from the idea of the dynamic servo driven > > machine to the stepper turtle :) > > All my stuff is steppers, but I wouldn't call a g0 move at 250 ipm a > turtle. The whole steel framed table its on shakes. > /me converts - that's 6.35 meter per minute - that's about 10.5cm per second. I would suspect the dynamic movement (acc/dec) of a servo might actually shake it less. It seems like 500 ipm should be easily doable with a servo. But that's still just reading/watching knowledge here. Mach3's bob's can be used but my being a "CET" means they're not OOTB CET means central european time to me - what does it mean to you? :) For folks who aren't comfy with a hot air rework soldering iron > surgically implanted in a right hand, that need does remove those $20 > boards from consideration. Mesa and cnc4pc both make better bobs, but > bring more money. > Not an EE - but I had my first soldering iron when I was 7y :) > But,if you are going to use it to drive a spindle, which is "CCS" > service. be sure and tell Jon when you order it. he'll change the toroid > filters from ICAS to CCS, the ICAS version gets hot, the CCS versions > doesn't. Why would they not be CCS? > > Which made me curious and I started digging - down the rabbit hole ;) > > Locally, that hole is more likely a gopher or ground hog hole. ;) > Got more gophers than rabbits? :) > > Hope that explains the status quo. > > Somewhat, but the ball screws at 5mm pitch is pretty much stock in what's > commonly available. People usually build this CNC with 10mm pitch ball screws and open loop 2.5Nm steppers with a parallel BOB. I could go 2Nm or 3Nm closed loop steppers - but are still not much wiser in terms of the boards. Maybe finding an old parallel port machine might still be the easier route :-/ Happy Easter! cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Saturday, 16 April 2022 18:03:47 EDT Torsten Curdt via Emc-developers wrote: > > > > > The splitting would not work for the servos that have the > > > > > driver > > > > > integrated though. > > > > > > > > Why not? > > > > > > There are no pins to connect to :) > > > > That I should point out, is generally NOT a problem for a CET. > > LOL ... I agree. > > > At least not until one would "fix" that inside the driver itself. And > > I> > > > am not so eager to do that. > > > > It might be difficult mechanically, but the points to grab ARE in the > > circuit. Generally useing a scope probe to help in identify them. > > I am pretty sure I *could* do it - but I am pretty sure I don't want to > make things more complicated than they already are :) > And you are right. There isn't much space mechanically. > > > > So that would NOT be a recommended setup? > > > > I think it would be good, given that todays hardware is considerably > > faster, Nyquist (time delay phase shifts) caused instability stuff > > s/b > > much less of a problem and I expect it would be quite easy to do > > today. > Except for the problems you are mentioning it would kind of make sense > - to me at least. At least for steppers. > (Not sure this would work for servos. I guess they usually always come > with their own PID loop?) > > > Particularly if you pay attention to the addf order in the hal file. > > > /me doesn't understand that yet, but makes a note for later :) > > > I am slowly running out of ideas what is :) > > > > Tell us what you want to do? Probably not me, but there are folks > > here > > with far more knowledge than I've experience with, that can give you > > an idea how to do it. > > Well, this is the dev list - so I rather wanted to focus on the > protocols and how things are supposed to work conceptually to > understand my options. But since you are asking that directly I am > happy to share... > > I've built a smallish CNC (1000x700mm) and I still have some JMC 180W > Servos (V5) that I wanted to use on the machine. > Now I am looking at my options for driving them. > > The options for the controller: > - old GRBL board (nah) > - RPi3 with a Protoneer GRBL hat (maybe until I find something better) > - Esp32 GRBL (didn't find good boards, price difference to a Mesa is > getting smaller) > - Teensy GRBL (sounds pretty good for a GRBL, maybe, price difference > to a Mesa is getting smaller) > - Some old PC with a Parallel Port (but it seems hard find and I am not > such a fan of the idea, I rather have the stepgen on a board) - Some > old PC with a Mesa 7i96e (would probably have been my choice but not > going to happen due to availability, at least in the EU) > - Some old PC with a Nvem and Remora (not so super eager as Remora > seems still to be a one man project and still quite beta) > > ...and I think I really want to go with LinuxCNC :) > > As for the motors. People are bitching how hard it is to parameterize > those servos. > I am told the two motors on the Y axis can become a real problem. > But I am still tempted to at least give that a try. > > It would be nice if I could write some LinuxCNC integration that talks > via modbus to help with the configuration. That will also need 4 > UARTS/RS232 on the PC though. > Icing on the cake would be if the LinuxCNC could monitor the modbus and > slow down the motion if the following error becomes too big. > > That said In retrospect I am also not such a fan of the integrated > servo drivers anymore - and with all the things still in limbo... > ...it also crossed my mind to just get some closed loop steppers and > probably be done with it. As long as they are 3 phase, I think thats decent advice. Those I have used so far have had the fault outputs wired into the e-stop circuit. Works well when tested, but has never actually occured while running a program. So "nuisance" trips have not ever occurred. > BUT my ballscrews are 05mm and planned for servo speeds. > > I don't really want to go from the idea of the dynamic servo driven > machine to the stepper turtle :) All my stuff is steppers, but I wouldn't call a g0 move at 250 ipm a turtle. The whole steel framed table its on shakes. > Bottom line: If the Mesa wasn't out of stock for the unforeseen future > I would have probably just gotten one and tried. > Now I have to come up with a plan B and was wondering about the > alternatives. > So I find myself looking through mach3 boards and wondering about the > reasons they cannot be used with LinuxCNC. Mach3's bob's can be used but my being a "CET" means they're not OOTB when they go into service, the opto's are often bypassed in order to get the needed, repeatable speeds. That back of the spindle motor encoder on my GO704 comes in thru such a 5 axis board, but the noise filtration of that board has been removed. I bought that board specifically because it didn't claim slow opto's in its 5 inputs, turns out it had 470 ohm and .1 uf monol
Re: [Emc-developers] curious about the ethernet protocol
> > > It sounds like the ideal LinuxCNC setup would be a very dump driver > > (without encoder support) and a stepper/servo with just an exposed > encoder. > > And then have LinuxCNC take care of everything. > > > But, then, you would be running blind, with no actual > position available at the computer. > Why is that? LinuxCNC would get the data from the stepper/servo encoder of course. It's just that the Driver would not interfere. It would be up to LinuxCNC to compensate based on the measure error. This will work, of course, and is simpler, but you are > trusting the servo drives to ALWAYS have the machine at the > commanded position.The advantage of closing the loop in > the computer is that you can always graph the following > error to determine if the machine is accurately following > the G-code program. > Tracking the error would then also become the task of LinuxCNC. It would not only generate all steps, but also receive all encoder information. It's basically moving the loops from the driver to the host. I guess my question is whether that's the vision of LinuxCNC or not. cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On 4/16/22 12:17, Torsten Curdt via Emc-developers wrote: But this feedback loop decouples the real position from the meant-to-be position. (expressed in the following error) And I don't see how the real position could be reported back to LinuxCNC so it's still in full control of the movement. ...unless you connect the encoder directly to the Mesa instead of the Closed Loop Stepper driver. You can send the encoder feedback to lcnc as well as the drive using splitter. Ah, interesting. The encoders on closed loop steppers seem to usually have 4 pins. (EA+,EB+,EB-,EA-) Does that mean it requires 4 inputs per motor? Or would this somehow be normalized into STEPs and DIRs? Or what does LinuxCNC expect? The +/- indicate a differential pair, for noise rejection. The conversion to a single signal would be done in a comparator IC at the input. The splitting would not work for the servos that have the driver integrated though. For example JMC Servos can only provide feedback via modbus for example. So I guess they wouldn't be really ideal to work with unless LinuxCNC could also poll the modbus as a feedback channel. It sounds like the ideal LinuxCNC setup would be a very dump driver (without encoder support) and a stepper/servo with just an exposed encoder. And then have LinuxCNC take care of everything. But, then, you would be running blind, with no actual position available at the computer. This will work, of course, and is simpler, but you are trusting the servo drives to ALWAYS have the machine at the commanded position. The advantage of closing the loop in the computer is that you can always graph the following error to determine if the machine is accurately following the G-code program. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > > > The splitting would not work for the servos that have the driver > > > > integrated though. > > > > > > Why not? > > > > There are no pins to connect to :) > > That I should point out, is generally NOT a problem for a CET. > LOL ... I agree. > At least not until one would "fix" that inside the driver itself. And I > > am not so eager to do that. > > It might be difficult mechanically, but the points to grab ARE in the > circuit. Generally useing a scope probe to help in identify them. I am pretty sure I *could* do it - but I am pretty sure I don't want to make things more complicated than they already are :) And you are right. There isn't much space mechanically. > > So that would NOT be a recommended setup? > > I think it would be good, given that todays hardware is considerably > faster, Nyquist (time delay phase shifts) caused instability stuff s/b > much less of a problem and I expect it would be quite easy to do today. > Except for the problems you are mentioning it would kind of make sense - to me at least. At least for steppers. (Not sure this would work for servos. I guess they usually always come with their own PID loop?) Particularly if you pay attention to the addf order in the hal file. > /me doesn't understand that yet, but makes a note for later :) > I am slowly running out of ideas what is :) > > Tell us what you want to do? Probably not me, but there are folks here > with far more knowledge than I've experience with, that can give you an > idea how to do it. > Well, this is the dev list - so I rather wanted to focus on the protocols and how things are supposed to work conceptually to understand my options. But since you are asking that directly I am happy to share... I've built a smallish CNC (1000x700mm) and I still have some JMC 180W Servos (V5) that I wanted to use on the machine. Now I am looking at my options for driving them. The options for the controller: - old GRBL board (nah) - RPi3 with a Protoneer GRBL hat (maybe until I find something better) - Esp32 GRBL (didn't find good boards, price difference to a Mesa is getting smaller) - Teensy GRBL (sounds pretty good for a GRBL, maybe, price difference to a Mesa is getting smaller) - Some old PC with a Parallel Port (but it seems hard find and I am not such a fan of the idea, I rather have the stepgen on a board) - Some old PC with a Mesa 7i96e (would probably have been my choice but not going to happen due to availability, at least in the EU) - Some old PC with a Nvem and Remora (not so super eager as Remora seems still to be a one man project and still quite beta) ...and I think I really want to go with LinuxCNC :) As for the motors. People are bitching how hard it is to parameterize those servos. I am told the two motors on the Y axis can become a real problem. But I am still tempted to at least give that a try. It would be nice if I could write some LinuxCNC integration that talks via modbus to help with the configuration. That will also need 4 UARTS/RS232 on the PC though. Icing on the cake would be if the LinuxCNC could monitor the modbus and slow down the motion if the following error becomes too big. That said In retrospect I am also not such a fan of the integrated servo drivers anymore - and with all the things still in limbo... ...it also crossed my mind to just get some closed loop steppers and probably be done with it. BUT my ballscrews are 05mm and planned for servo speeds. I don't really want to go from the idea of the dynamic servo driven machine to the stepper turtle :) Bottom line: If the Mesa wasn't out of stock for the unforeseen future I would have probably just gotten one and tried. Now I have to come up with a plan B and was wondering about the alternatives. So I find myself looking through mach3 boards and wondering about the reasons they cannot be used with LinuxCNC. Which made me curious and I started digging - down the rabbit hole ;) Hope that explains the status quo. cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Saturday, 16 April 2022 14:33:25 EDT Torsten Curdt via Emc-developers wrote: > > > Does that mean it requires 4 inputs per motor? Or would this > > > somehow be normalized into STEPs and DIRs? Or what does Linuxcnc > > > expect?> > > The encoders are quadrature, so the diff is low, but the splitter > > could easily turn that signal pair into a TTL level signal. In fact, > > and not for a 3 phase setup, I'm doing that conversion mid-cable on > > my Go704. Using $2.50 rs485 interfaces solder programmed for 1 way > > only signaling. > You provide the encoder signals via RS485 to LinuxCNC? > No. I am a CET, (Certified Electronics Technician) I simply used the ready made cheapest gizmo I could find for a differential to TTL translator, two of them making love in a teeny hammond diecast box was exactly what I needed. The fact that they were designed to do that in an RS485 circuit, and made in qty's resembling Orville R's popcorn made them ultra cheap. Orville Redenbacher being the premier brand of popcorn here in the states. > > > The splitting would not work for the servos that have the driver > > > integrated though. > > > > Why not? > > There are no pins to connect to :) That I should point out, is generally NOT a problem for a CET. > At least not until one would "fix" that inside the driver itself. And I > am not so eager to do that. It might be difficult mechanically, but the points to grab ARE in the circuit. Generally useing a scope probe to help in identify them. > > > It sounds like the ideal LinuxCNC setup would be a very dump driver > > > (without encoder support) and a stepper/servo with just an exposed > > > encoder. And then have LinuxCNC take care of everything. > > > > > > Does that sound about right? > > > > See wiki.linuxcnc.org, > > Anything in particular? I've been browsing there for a while. > > > its been done around a decade ago. Nyquist related > > phase errors I believe limited the speed, but might work better > > feeding mesa stepgens and encoders since they're much faster than > > software. > Now I am confused. > > So that would NOT be a recommended setup? I think it would be good, given that todays hardware is considerably faster, Nyquist (time delay phase shifts) caused instability stuff s/b much less of a problem and I expect it would be quite easy to do today. Particularly if you pay attention to the addf order in the hal file. But, what the vendors are supplying today is 20x faster than early x86 stuff when that wiki article was written. About the only thing that might be a problem today is software stepping, and where my first mill ran all software on a shoelace budget and was hard put to move that mill about 8" a minute, that same driver kit is now moving a different mill at 200 ipm. That was then running on an intel atom board at 1.4 ghz, but currently has an off-lease dell with a 3ghz i5 in it, lots faster. Speed limit is the opto-isolators in the drivers, which are slow and start smearing the step pulses at about 250 kilohertz. So they are limited to around 200 kilohertz so they don't miss a step. > I am slowly running out of ideas what is :) Tell us what you want to do? Probably not me, but there are folks here with far more knowledge than I've experience with, that can give you an idea how to do it. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > > Does that mean it requires 4 inputs per motor? Or would this somehow be > > normalized into STEPs and DIRs? Or what does LinuxCNC expect? > > The encoders are quadrature, so the diff is low, but the splitter could > easily turn that signal pair into a TTL level signal. In fact, and not > for a 3 phase setup, I'm doing that conversion mid-cable on my Go704. > Using $2.50 rs485 interfaces solder programmed for 1 way only signaling. > You provide the encoder signals via RS485 to LinuxCNC? > > > The splitting would not work for the servos that have the driver > > integrated though. > > Why not? > There are no pins to connect to :) At least not until one would "fix" that inside the driver itself. And I am not so eager to do that. > > It sounds like the ideal LinuxCNC setup would be a very dump driver > > (without encoder support) and a stepper/servo with just an exposed > > encoder. And then have LinuxCNC take care of everything. > > > Does that sound about right? > > See wiki.linuxcnc.org, Anything in particular? I've been browsing there for a while. > its been done around a decade ago. Nyquist related > phase errors I believe limited the speed, but might work better feeding > mesa stepgens and encoders since they're much faster than software. > Now I am confused. So that would NOT be a recommended setup? I am slowly running out of ideas what is :) ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Saturday, 16 April 2022 13:17:16 EDT Torsten Curdt via Emc-developers wrote: > > > But this feedback loop decouples the real position from the > > > meant-to-be position. (expressed in the following error) > > > And I don't see how the real position could be reported back to > > > LinuxCNC> > > so > > > > > it's still in full control of the movement. > > > ...unless you connect the encoder directly to the Mesa instead of > > > the > > > Closed Loop Stepper driver. > > > > You can send the encoder feedback to lcnc as well as the drive using > > splitter. > > Ah, interesting. > > The encoders on closed loop steppers seem to usually have 4 pins. > (EA+,EB+,EB-,EA-) For noise considerations, the Lichuan motors and drivers (LCDA357H) are differential. > Does that mean it requires 4 inputs per motor? Or would this somehow be > normalized into STEPs and DIRs? Or what does LinuxCNC expect? The encoders are quadrature, so the diff is low, but the splitter could easily turn that signal pair into a TTL level signal. In fact, and not for a 3 phase setup, I'm doing that conversion mid-cable on my Go704. Using $2.50 rs485 interfaces solder programmed for 1 way only signaling. > The splitting would not work for the servos that have the driver > integrated though. Why not? > For example JMC Servos can only provide feedback via modbus for > example. So I guess they wouldn't be really ideal to work with unless > LinuxCNC could also poll the modbus as a feedback channel. > > It sounds like the ideal LinuxCNC setup would be a very dump driver > (without encoder support) and a stepper/servo with just an exposed > encoder. And then have LinuxCNC take care of everything. > Does that sound about right? See wiki.linuxcnc.org, its been done around a decade ago. Nyquist related phase errors I believe limited the speed, but might work better feeding mesa stepgens and encoders since they're much faster than software. > cheers, > Torsten Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > Now if the motor has an encoder LinuxCNC could read the position every > 1ms > > and make it a host based closed loop system. And I get the appeal. > > But people are also using LinuxCNC with a BOB and Open Loop Steppers > > without an encoder. > > So it sounds like the feedback is missing there. > Some setups, have "synthetic" feedback from counting stepper > pulses. > But what's the point of that? Isn't that just faking the position information? It seems like LinuxCNC could calculate that position even itself (time+velocity => position) It's just the position the motor should be at - not the position the motor really is. I make a hardware stepper board that has step generators > that are sent a velocity, and counters that can count the > steps or read an encoder. So, by flipping a switch on the > board, you can select open-loop or closed-loop mode. The > position counter is read back by the computer and LinuxCNC's > PID component computes the next velocity to send out, based > on the difference between commanded and actual position. I > also make a servo board that is very similar to the above, > except that it sends a PWM pulse train to the drives > proportional to desired velocity. The rest of the setup is > the same. > That's the "Universal Stepper Controller"? cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Saturday, 16 April 2022 12:13:37 EDT Torsten Curdt via Emc-developers wrote: > > > I can see this to be super useful when there is an external encoder > > > - so linuxcnc is in full control. > > > But what's the benefit with e.g. Servos and Closed Loop Stepper > > > that have their internal encoder and control loop? > > > > Sending out position instead of velocity also work. > > You mean LinuxCNC can be set up to send either - but Mesa has chosen to > use velocity for their integration? > > > Use encoder sending position using external feed back loop for > > position, following error and display also work as usual. > > Could you expand on that? > > I assume with "external feedback loop" you mean the feedback loop of > the servo or CL stepper. > > But this feedback loop decouples the real position from the meant-to-be > position. (expressed in the following error) > And I don't see how the real position could be reported back to > LinuxCNC so it's still in full control of the movement. > ...unless you connect the encoder directly to the Mesa instead of the > Closed Loop Stepper driver. > > > > (Another crazy(?) thought I had was to have an acceleration sensor > > > as > > > incoming feedback. To help with servo parameterization.) > > > > Should help at least then there is elasticity in between motor and > > position feed back. > > Yes, there would be some lag for sure. > But this isn't possible right now, is it? > > Could this be added as a component? > Either to feed into the motion control loop - or just to monitor it? > > > ... > > > > > It feels like sending the velocity commands over ethernet also > > > means some kind of buffering, but I guess the 1kHz feedback loop > > > is the big> > > difference > > > > > here. > > > > NML is for the non real time stuff so no 1kHz feedback loop there. > > I thought Mesa is reporting back the position in a 1kHz feedback loop - > no? > Yes, but while the huge majority of the stepper systems read the stepgen position as the feedback, this is only valid if the axis has been homed, there is a new tech that I consider an improvement. The usual two phase stepper has no way to notify linuxcnc of a lost step, and that can be and has been a problem. The even newer stepper/servo's, are 3 phase, and have an encoder on the rear of the motor that only feeds the the driver, AND they have a fault output wihich can be used to stop LCNC anytime the steps received by the driver have not been done because the tool has hit something and cannot reach the commanded position. I have 2 of those new 3 phase motors on that Sheldon now, and while its possible for noise to be interpreted as a step, it has not occured. I don't even use PID's, the motors are getting commands directly from motion. And doing EXACTLY what I tell it to do. The only errors are errors I introduced to test the fault stops. Like parking a carbide tool .010" from a chuck jaw and jogging it into the jaw, the chip hits the jaw, the fault triggers, which kills the motor psu's and the spring in the steel or iron bounces back to about .01" clear of the chuck jaw. Pull the tool off the post, re-enable motion, rehome the machine, put the tool back on the post and its ready to do it again. No damage to the carbide chip or the chuck. And I'm very pleased. They are very quiet, the whole machine doing a job is as quiet as it would be with casper the ghost turning the cranks. An advantage they ae not advertising (and should be) for the 3 phase family is the improved power efficiency, the error detected in the driver controls the motor current. 2 phase steppers need full or half power depending on moving or holding, so they can run burn your hand hot. These 3 phaser's run just barely warm at the end of an hours work. If the motor isn't working hard, they run at room temp. If I don't fall over and miss role call first, I'll replace all of my steppers with them in due time. Take care and stay well everybody. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > > > I get the general idea. But I am still a little shy on the details. > > > > It sounds on a LPT port setup the host sends every individual step to the > > port. > > Now if the motor has an encoder LinuxCNC could read the position every > 1ms > > and make it a host based closed loop system. And I get the appeal. > > But people are also using LinuxCNC with a BOB and Open Loop Steppers > > without an encoder. > > So it sounds like the feedback is missing there. > > Its still there but internal to the stepgen component > But without an encoder this can only be the meant-to-be position - not the real position. > You said they are velocity commands. So it should be something along the > > lines of: > > > > "x+1000 steps in 1500ms" > > "y-100 steps in 500ms" > > > > Simpler that that, linuxCNC simply sends the step rate > (scaled for the hardware) > I guess with the feedback loop that is indeed enough. I would love to just have a look. Is this the right place to dig in? https://github.com/LinuxCNC/linuxcnc/tree/2e75b091a23e3312b9e57a88941714701f3709b8/src/hal/drivers/mesa-hostmot2 > > > On top of that the Mesa card will report back the position of the motors > > (steps from 0?) every 1ms to the host. > > > Not steps from 0 but rather relative position as a signed 32 bit number > 16.16 (whole steps.fractional steps) > > (LinuxCNCs position is a FP double) > Relative position since when? The last motion command? Thanks for bearing with all my questions :) cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > But this feedback loop decouples the real position from the meant-to-be > > position. (expressed in the following error) > > And I don't see how the real position could be reported back to LinuxCNC > so > > it's still in full control of the movement. > > ...unless you connect the encoder directly to the Mesa instead of the > > Closed Loop Stepper driver. > > > > You can send the encoder feedback to lcnc as well as the drive using > splitter. > Ah, interesting. The encoders on closed loop steppers seem to usually have 4 pins. (EA+,EB+,EB-,EA-) Does that mean it requires 4 inputs per motor? Or would this somehow be normalized into STEPs and DIRs? Or what does LinuxCNC expect? The splitting would not work for the servos that have the driver integrated though. For example JMC Servos can only provide feedback via modbus for example. So I guess they wouldn't be really ideal to work with unless LinuxCNC could also poll the modbus as a feedback channel. It sounds like the ideal LinuxCNC setup would be a very dump driver (without encoder support) and a stepper/servo with just an exposed encoder. And then have LinuxCNC take care of everything. Does that sound about right? cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On 4/16/22 11:09, Torsten Curdt via Emc-developers wrote: I get the general idea. But I am still a little shy on the details. It sounds on a LPT port setup the host sends every individual step to the port. Yes, with software-generated steps, that's right. A fast real-time thread generates the steps, and a slower (1ms) thread sends interpolated positions to the step generator. Now if the motor has an encoder LinuxCNC could read the position every 1ms and make it a host based closed loop system. And I get the appeal. But people are also using LinuxCNC with a BOB and Open Loop Steppers without an encoder. So it sounds like the feedback is missing there. Some setups, have "synthetic" feedback from counting stepper pulses. I make a hardware stepper board that has step generators that are sent a velocity, and counters that can count the steps or read an encoder. So, by flipping a switch on the board, you can select open-loop or closed-loop mode. The position counter is read back by the computer and LinuxCNC's PID component computes the next velocity to send out, based on the difference between commanded and actual position. I also make a servo board that is very similar to the above, except that it sends a PWM pulse train to the drives proportional to desired velocity. The rest of the setup is the same. I also make an analog velocity servo interface that sends an analog voltage to the servo amps, this is how the original EMC from NIST in 1997 worked. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sat, 16 Apr 2022, Torsten Curdt wrote:
Date: Sat, 16 Apr 2022 18:09:08 +0200
From: Torsten Curdt
To: Torsten Curdt via Emc-developers
Cc: Peter C. Wallace
Subject: Re: [Emc-developers] curious about the ethernet protocol
How come you send the velocity commands and not target positions? Size of
the positioning data I assume?
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.
I get the general idea. But I am still a little shy on the details.
It sounds on a LPT port setup the host sends every individual step to the
port.
Now if the motor has an encoder LinuxCNC could read the position every 1ms
and make it a host based closed loop system. And I get the appeal.
But people are also using LinuxCNC with a BOB and Open Loop Steppers
without an encoder.
So it sounds like the feedback is missing there.
Its still there but internal to the stepgen component
Now for the Mesa card setup.
IIUC LinuxCNC does not send every individual step over ethernet. Instead it
sends motion controls commands.
You said they are velocity commands. So it should be something along the
lines of:
"x+1000 steps in 1500ms"
"y-100 steps in 500ms"
Simpler that that, linuxCNC simply sends the step rate
(scaled for the hardware)
On top of that the Mesa card will report back the position of the motors
(steps from 0?) every 1ms to the host.
Not steps from 0 but rather relative position as a signed 32 bit number
16.16 (whole steps.fractional steps)
(LinuxCNCs position is a FP double)
Is that correct?
cheers,
Torsten
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Saturday, 16 April 2022 08:15:56 EDT Torsten Curdt via Emc-developers wrote: > > Manual on page 3 > > http://linuxcnc.org/docs/devel/pdf/LinuxCNC_Developer.pdf > Thanks for that link. I somehow missed those docs. > > > NML should work over TCP/IP networks including Ethernet but think it > > is currently out of order and only work using shared memory buffers. > What's NML? > > > Main problem with Ethernet is then connected to an ordinary network. And the fact that its not sharable, was why I used the SPI interface to run the sheldon lathe with an rpi, 3b at first, now a 4b. Most of my machines run thru a simulated parport in the form of a Mesa 5i25 + daughter cards, and I don't know how fast that is, Peter s/b able to address that, but the SPI, driven by the pi's gpio's, is amazingly fast, sending data in 32 bit packets to the mesa 7i90 card at 41 megabaud, and getting replies back fron the mesa card at 25 megabaud, If thats not realtime enough I don't know what is. That does require treating the interconnect cable, in my case an inch long, as the transmission line it is. So my rpi still has a normal net connected to it, and ATM has two shells logged into it from this machine. I can fire up firefox and tour the planet, on the pi. > I would expect to connect an ethernet board directly - and not share > the network. > So that should help. > cheers, > Torsten > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
Le sam. 16 avr. 2022 à 18:15, Torsten Curdt via Emc-developers < emc-developers@lists.sourceforge.net> a écrit : > > > > Use encoder sending position using external feed back loop for position, > > following error and display also work as usual. > > > > Could you expand on that? > > I assume with "external feedback loop" you mean the feedback loop of the > servo or CL stepper. > > But this feedback loop decouples the real position from the meant-to-be > position. (expressed in the following error) > And I don't see how the real position could be reported back to LinuxCNC so > it's still in full control of the movement. > ...unless you connect the encoder directly to the Mesa instead of the > Closed Loop Stepper driver. > You can send the encoder feedback to lcnc as well as the drive using splitter. You can also add encoders on the axis like linear scales for the most accurate position feedback > > > > (Another crazy(?) thought I had was to have an acceleration sensor as > > > incoming feedback. To help with servo parameterization.) > > > > Should help at least then there is elasticity in between motor and > > position feed back. > > > > Yes, there would be some lag for sure. > But this isn't possible right now, is it? > > Could this be added as a component? > Either to feed into the motion control loop - or just to monitor it? > > > ... > > > It feels like sending the velocity commands over ethernet also means > some > > > kind of buffering, but I guess the 1kHz feedback loop is the big > > difference > > > here. > > > > NML is for the non real time stuff so no 1kHz feedback loop there. > > > > I thought Mesa is reporting back the position in a 1kHz feedback loop - no? > > ___ > 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
Re: [Emc-developers] curious about the ethernet protocol
Le sam. 16 avr. 2022 à 17:26, Peter C. Wallace a écrit : > > > 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. > These few lines deserve to appear on the front page of LinuxCNC! Seriously. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > I can see this to be super useful when there is an external encoder - so > > linuxcnc is in full control. > > But what's the benefit with e.g. Servos and Closed Loop Stepper that have > > their internal encoder and control loop? > > Sending out position instead of velocity also work. You mean LinuxCNC can be set up to send either - but Mesa has chosen to use velocity for their integration? > Use encoder sending position using external feed back loop for position, > following error and display also work as usual. > Could you expand on that? I assume with "external feedback loop" you mean the feedback loop of the servo or CL stepper. But this feedback loop decouples the real position from the meant-to-be position. (expressed in the following error) And I don't see how the real position could be reported back to LinuxCNC so it's still in full control of the movement. ...unless you connect the encoder directly to the Mesa instead of the Closed Loop Stepper driver. > > (Another crazy(?) thought I had was to have an acceleration sensor as > > incoming feedback. To help with servo parameterization.) > > Should help at least then there is elasticity in between motor and > position feed back. > Yes, there would be some lag for sure. But this isn't possible right now, is it? Could this be added as a component? Either to feed into the motion control loop - or just to monitor it? > ... > > It feels like sending the velocity commands over ethernet also means some > > kind of buffering, but I guess the 1kHz feedback loop is the big > difference > > here. > > NML is for the non real time stuff so no 1kHz feedback loop there. > I thought Mesa is reporting back the position in a 1kHz feedback loop - no? ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > How come you send the velocity commands and not target positions? Size of > > the positioning data I assume? > > > 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. > I get the general idea. But I am still a little shy on the details. It sounds on a LPT port setup the host sends every individual step to the port. Now if the motor has an encoder LinuxCNC could read the position every 1ms and make it a host based closed loop system. And I get the appeal. But people are also using LinuxCNC with a BOB and Open Loop Steppers without an encoder. So it sounds like the feedback is missing there. Now for the Mesa card setup. IIUC LinuxCNC does not send every individual step over ethernet. Instead it sends motion controls commands. You said they are velocity commands. So it should be something along the lines of: "x+1000 steps in 1500ms" "y-100 steps in 500ms" On top of that the Mesa card will report back the position of the motors (steps from 0?) every 1ms to the host. Is that correct? cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Saturday, 16 April 2022 08:15:30 EDT Torsten Curdt via Emc-developers wrote: > > ...and 87 years old. > > Wow! ...and still going strong on CNC mailing lists :) Not much else to do, the missus passed from COPD back on Pearl Harbor Day 2020, so I've been alone since. Tested at 147 in 1947, I quit school and went to work fixing tv's as soon as there was tv's to fix. Next thing I know I'm 23 finally found a good woman & started making babies, she had a stroke and died at 34, and the babies have all passed at middle age from cancer or booze related wrecks, I picked up the glasshopper at the local bar for 17 years of hell, then a local music teacher for 31 years. I switched from consumer electronics to broadcasting in the early 60's and was the C.E. at a couple tv stations for the last 24 years I worked. I had a pulmonary embolism at 79 that slowed the thinker a bit, survival rates for those are only 2%, and a chest full of hardware keeps me going these days. They do very good work at Ruby Memorial in Morgantown. A new aortic valve, installed thru the vein in my groin has my ticker working normally, triggered by a pacemaker. Barring cerebral accidents I s/b good for the life of the battery in the pacemaker. So I'm stuck here. Someone once suggested he wasn't ready for me, cuz he'd send me down, I'd fix the stoker, rewind the generator, and open an air conditioned bar. And niether could tolerate that. :o) So here I am, still doing, albeit slower, what I like to do. Like make something work better than new. Teaching it new dance steps etc. > > Welcome to the list, Torsten Curdt. Enjoy, take care and stay well. > > Thanks for the warm welcome. Your welcome, thanks for the flowers. Stay well now. > > cheers, > Torsten Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sat, 16 Apr 2022, Torsten Curdt via Emc-developers wrote:
Date: Sat, 16 Apr 2022 14:15:14 +0200
From: Torsten Curdt via Emc-developers
To: Torsten Curdt via Emc-developers
Cc: Torsten Curdt
Subject: Re: [Emc-developers] curious about the ethernet protocol
The way the Mesa stepgen works currently is basically copied from the
software
stepgen component. The host PC sends velocity commands to the stepgen
hardware
(a 48 bit DDS) and reads the stepgen current position (all at the nominal
1 KHz
servo thread rate) Then a feedback loop in LinuxCNC or hal corrects for
the
minor position errors due to differences in timebases, delays between
position
reads and velocity writes, velocity setting resolution limits etc. This
feedback
loop keeps the position error each sample time to a small fraction of an
external step.
How come you send the velocity commands and not target positions? Size of
the positioning data I assume?
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.
I can see this to be super useful when there is an external encoder - so
linuxcnc is in full control.
But what's the benefit with e.g. Servos and Closed Loop Stepper that have
their internal encoder and control loop?
I guess some Servos allow you to read the position error via e.g.
serial/modbus - but that will be all but real time at maybe 57k baud.
Thought it would still be nice if LinuxCNC could use that information
coming in.
But I bet this is already possible :)
(Another crazy(?) thought I had was to have an acceleration sensor as
incoming feedback. To help with servo parameterization.)
And now I hope I don't get lynched for asking:
How is that ethernet protocol different from the Mach3 ethernet protocol?
Are there significant differences between the protocols that would
prohibit
LinuxCNC speaking the Mach3 ethernet protocol?
Mach is not real time so needs buffered hardware/software in the remote
device
that stores a series of moves (perhaps PVT segments) and plays them out
while
the host keeps the buffer full. This is not compatible with LinuxCNC's
motion
model where all motion hardware access is real time.
It feels like sending the velocity commands over ethernet also means some
kind of buffering, but I guess the 1kHz feedback loop is the big difference
here.
But then again I am wondering how this helps with a system that doesn't
have encoder feedback as such.
Will the mesa card just report back where the motor should be? That seems
to defeat the intent.
Much appreciate the details, Peter.
I would probably not ask these devil's advocats/learning questions if I
could get my hands on a 7i96E ;)
cheers,
Torsten
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> ... > How come you send the velocity commands and not target positions? Size of > the positioning data I assume? > > I can see this to be super useful when there is an external encoder - so > linuxcnc is in full control. > But what's the benefit with e.g. Servos and Closed Loop Stepper that have > their internal encoder and control loop? Sending out position instead of velocity also work. Use encoder sending position using external feed back loop for position, following error and display also work as usual. > ... > (Another crazy(?) thought I had was to have an acceleration sensor as > incoming feedback. To help with servo parameterization.) Should help at least then there is elasticity in between motor and position feed back. > ... > It feels like sending the velocity commands over ethernet also means some > kind of buffering, but I guess the 1kHz feedback loop is the big difference > here. NML is for the non real time stuff so no 1kHz feedback loop there. Nicklas SB Karlsson ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sat, 16 Apr 2022 14:15:56 +0200 Torsten Curdt via Emc-developers wrote: > > Manual on page 3 http://linuxcnc.org/docs/devel/pdf/LinuxCNC_Developer.pdf > > > Thanks for that link. I somehow missed those docs. > > > > NML should work over TCP/IP networks including Ethernet but think it is > > currently out of order and only work using shared memory buffers. > > > What's NML? NML is some kind of communication protocol used internally in Linuxcnc, supposed also to work over ordinary TCP/IP network. It may make sense to separate user interface from real time computer but with good real time performance in an ordinary computer it is not very important, the RT kernel have been available for som years but not vary many. Nicklas Karlsson ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> I would expect to connect an ethernet board directly - and not share the network. > So that should help. Insofar as I know the 7i92 and cousins *ONLY* work on a dedicated port. -Original Message- From: Torsten Curdt via Emc-developers Sent: April 16, 2022 8:16 AM To: EMC developers Cc: Torsten Curdt Subject: Re: [Emc-developers] curious about the ethernet protocol > Manual on page 3 > http://linuxcnc.org/docs/devel/pdf/LinuxCNC_Developer.pdf Thanks for that link. I somehow missed those docs. > NML should work over TCP/IP networks including Ethernet but think it > is currently out of order and only work using shared memory buffers. What's NML? > Main problem with Ethernet is then connected to an ordinary network. I would expect to connect an ethernet board directly - and not share the network. So that should help. cheers, Torsten ___ 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
Re: [Emc-developers] curious about the ethernet protocol
> Manual on page 3 http://linuxcnc.org/docs/devel/pdf/LinuxCNC_Developer.pdf Thanks for that link. I somehow missed those docs. > NML should work over TCP/IP networks including Ethernet but think it is > currently out of order and only work using shared memory buffers. What's NML? > Main problem with Ethernet is then connected to an ordinary network. I would expect to connect an ethernet board directly - and not share the network. So that should help. cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > The way the Mesa stepgen works currently is basically copied from the > software > stepgen component. The host PC sends velocity commands to the stepgen > hardware > (a 48 bit DDS) and reads the stepgen current position (all at the nominal > 1 KHz > servo thread rate) Then a feedback loop in LinuxCNC or hal corrects for > the > minor position errors due to differences in timebases, delays between > position > reads and velocity writes, velocity setting resolution limits etc. This > feedback > loop keeps the position error each sample time to a small fraction of an > external step. > How come you send the velocity commands and not target positions? Size of the positioning data I assume? I can see this to be super useful when there is an external encoder - so linuxcnc is in full control. But what's the benefit with e.g. Servos and Closed Loop Stepper that have their internal encoder and control loop? I guess some Servos allow you to read the position error via e.g. serial/modbus - but that will be all but real time at maybe 57k baud. Thought it would still be nice if LinuxCNC could use that information coming in. But I bet this is already possible :) (Another crazy(?) thought I had was to have an acceleration sensor as incoming feedback. To help with servo parameterization.) > And now I hope I don't get lynched for asking: > > How is that ethernet protocol different from the Mach3 ethernet protocol? > > Are there significant differences between the protocols that would > prohibit > > LinuxCNC speaking the Mach3 ethernet protocol? > > > > Mach is not real time so needs buffered hardware/software in the remote > device > that stores a series of moves (perhaps PVT segments) and plays them out > while > the host keeps the buffer full. This is not compatible with LinuxCNC's > motion > model where all motion hardware access is real time. > It feels like sending the velocity commands over ethernet also means some kind of buffering, but I guess the 1kHz feedback loop is the big difference here. But then again I am wondering how this helps with a system that doesn't have encoder feedback as such. Will the mesa card just report back where the motor should be? That seems to defeat the intent. Much appreciate the details, Peter. I would probably not ask these devil's advocats/learning questions if I could get my hands on a 7i96E ;) cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > ...and 87 years old. > Wow! ...and still going strong on CNC mailing lists :) > Welcome to the list, Torsten Curdt. Enjoy, take care and stay well. > Thanks for the warm welcome. cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
Manual on page 3 http://linuxcnc.org/docs/devel/pdf/LinuxCNC_Developer.pdf NML should work over TCP/IP networks including Ethernet but think it is currently out of order and only work using shared memory buffers. Try to get it started using ordinary TCP/IP over ordinary Ethernet network a few years ago, might be axis which is the problem. Ethernet is not well suited for real time control, it is however possible in a controlled environment or if some missed dead lines may be accepted. There is a difference between video and machine control, amount of data is relatively small in machine control but with control loop over network it have to be sent very often. Interestingly old ATM for telephone network send many small messages, read something about 48 bytes. Main problem with Ethernet is then connected to an ordinary network. Other messages may arrive at any time and if they are sent first real time communication is delayed. Have not yet figured how to tell Linux to not send other communication then used as a real time controller though probably not very hard, then listening with Wireshark there are coming out arp request and other request on the Ethernet port. Nicklas Karlsson Den 2022-04-16 kl. 01:23, skrev Torsten Curdt via Emc-developers: Hey there, I was wondering the following - and mainly really to understand how LinuxCNC works. Since I couldn't get a proper answer in the user chat I thought I would try here. 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? Are the steps compressed into instructions and then applied on the Mesa cards? Poking around it seems like there are motion commands and status commands? So it probably sends "go there" and "where are you" and the card generates the steps required and reports back. Does that sound right? Is there a definition of the protocol to look at? I assume the code of what gets pushed to the Mesa's must be somewhere, too. And now I hope I don't get lynched for asking: How is that ethernet protocol different from the Mach3 ethernet protocol? Are there significant differences between the protocols that would prohibit LinuxCNC speaking the Mach3 ethernet protocol? Or maybe no one knows or cares? But I was wondering if implementing the protocol could be another alternative to flashing Remora to supported boards. While waiting for Mesa stocks to recover, I am really just curious to understand the technical side of the LinuxCNC vs Mach3 comparison. cheers, Torsten ___ 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
Re: [Emc-developers] curious about the ethernet protocol
On Friday, 15 April 2022 19:23:49 EDT Torsten Curdt via Emc-developers wrote: > Hey there, > > I was wondering the following - and mainly really to understand how > LinuxCNC works. > Since I couldn't get a proper answer in the user chat I thought I would > try here. > > 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? > > Are the steps compressed into instructions and then applied on the Mesa > cards? > Poking around it seems like there are motion commands and status > commands? So it probably sends "go there" and "where are you" and the > card generates the steps required and reports back. Does that sound > right? Is there a definition of the protocol to look at? > I assume the code of what gets pushed to the Mesa's must be somewhere, > too. > > And now I hope I don't get lynched for asking: > How is that ethernet protocol different from the Mach3 ethernet > protocol? Are there significant differences between the protocols that > would prohibit LinuxCNC speaking the Mach3 ethernet protocol? > > Or maybe no one knows or cares? But I was wondering if > implementing the protocol could be another alternative to flashing > Remora to supported boards. > > While waiting for Mesa stocks to recover, I am really just curious to > understand the technical side of the LinuxCNC vs Mach3 comparison. > > cheers, > Torsten > First, I'll say I know very little about ethernet, other than I get the impression that it is not well suited to realtime control. That doesn't mean I don't use it, theres 6 machines here on my home net, but I don't use it for machine control. Second, the only thing I know about mach3 is that it came in a starter version with a 6040 4 axis gantry mill I bought, and it only half worked in fits and spurts. I wound up junking the entire electronics control box because the whole thing stank of built by lowest bidder stuff. The power supply was rated at about 1/3rd of the amps it needed and was folding back from its nameplate 24 volts to around 13 volts when the 4th axis was plugged in. That was not enough to pick up the spindle motor when it was down. The vfd was not controllable by mach3, only by separate knobs on its own front panel, and even that was not a reliable method of starting or stopping it. Zero docs on the vfd unless you can read Chinese. It had a terminal marked rev but actually tossed a coin to see which way it ran this time. So I pitched the whole box in the trash trailer and built my own, using mesa parport driven hardware. Spindle motor was water cooled but a lightweight two bearing model, and the bearings started howling at about 5 hours. It was a 120 volt motor that flickered the garage lights, so I bought a 240 volt vfd and a decent 4 bearing motor. Wired that up 2 years ago. The vfd had an rs485 interface and runs better than direct control using that interface. ATM its torn down, getting the z and b drivers and motors replaced with 3 phase stuff. XY runs at better than 200 ipm now, and the new spindle is about a kg heavier than the old one so I'm hoping the 3 phase motor can pick it up faster than 20 ipm. The A/B rotary wasn't able to hold against any cutting forces, so that was worthless right OOTB, so I designed and printed a miniature harmonic drive with a 50/1 ratio. Slow, but holds, or turns under load, like you would expect it to. Linuxcnc is all synchronized, so when a fast axis and it moves at the same time, the fast axis slows down to stay in perfect synch when cutting threads and other such operations. I paid $1350 for it, and I've put another thou+ in it making it a usable machine. Had I stuck with mach3, I probably would have junked it all. One of the things you've got on this list is support for LinuxCNC from the people that have been writing it and improving it for at least 25 years now. Development is active. Very active. I now have 4 machines, all 4 basicly assembled from old raw materiel, 2 lathes, two mills. The big lathe, an elderly Sheldon 11x54, now about 80 years old, is actually being run by a raspberry pi, and doing tricks it could NOT do when shipped in the 1950 time frame. Why the pi? I wanted to see if it could be done, and its doing it quite well. Who am I? A 20 year retired television engineer with an odd history. I've an 8th grade education, but I'm also a CET, and I can discuss the theory of relativity with anybody that cares. Now a widower, and 87 years old. My mother was the only girl in the 1929 class on Aviation Technology at Des Moines Tech High school, and if she didn't know the answer, she knew where the county library was, so in the 2nd grade, I asked her what gravity was, so I was doing McGuffies Readers in school, and reading high school physics textbooks at home after school. And we still can't merge gravity into a Theory of Ever
Re: [Emc-developers] curious about the ethernet protocol
On Sat, 16 Apr 2022, Torsten Curdt via Emc-developers wrote: Date: Sat, 16 Apr 2022 01:23:49 +0200 From: Torsten Curdt via Emc-developers To: emc-developers@lists.sourceforge.net Cc: Torsten Curdt Subject: [Emc-developers] curious about the ethernet protocol Hey there, I was wondering the following - and mainly really to understand how LinuxCNC works. Since I couldn't get a proper answer in the user chat I thought I would try here. 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? Are the steps compressed into instructions and then applied on the Mesa cards? Poking around it seems like there are motion commands and status commands? So it probably sends "go there" and "where are you" and the card generates the steps required and reports back. Does that sound right? Is there a definition of the protocol to look at? I assume the code of what gets pushed to the Mesa's must be somewhere, too. The way the Mesa stepgen works currently is basically copied from the software stepgen component. The host PC sends velocity commands to the stepgen hardware (a 48 bit DDS) and reads the stepgen current position (all at the nominal 1 KHz servo thread rate) Then a feedback loop in LinuxCNC or hal corrects for the minor position errors due to differences in timebases, delays between position reads and velocity writes, velocity setting resolution limits etc. This feedback loop keeps the position error each sample time to a small fraction of an external step. And now I hope I don't get lynched for asking: How is that ethernet protocol different from the Mach3 ethernet protocol? Are there significant differences between the protocols that would prohibit LinuxCNC speaking the Mach3 ethernet protocol? Mach is not real time so needs buffered hardware/software in the remote device that stores a series of moves (perhaps PVT segments) and plays them out while the host keeps the buffer full. This is not compatible with LinuxCNC's motion model where all motion hardware access is real time. Or maybe no one knows or cares? But I was wondering if implementing the protocol could be another alternative to flashing Remora to supported boards. While waiting for Mesa stocks to recover, I am really just curious to understand the technical side of the LinuxCNC vs Mach3 comparison. cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers Peter Wallace Mesa Electronics ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] curious about the ethernet protocol
Hey there, I was wondering the following - and mainly really to understand how LinuxCNC works. Since I couldn't get a proper answer in the user chat I thought I would try here. 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? Are the steps compressed into instructions and then applied on the Mesa cards? Poking around it seems like there are motion commands and status commands? So it probably sends "go there" and "where are you" and the card generates the steps required and reports back. Does that sound right? Is there a definition of the protocol to look at? I assume the code of what gets pushed to the Mesa's must be somewhere, too. And now I hope I don't get lynched for asking: How is that ethernet protocol different from the Mach3 ethernet protocol? Are there significant differences between the protocols that would prohibit LinuxCNC speaking the Mach3 ethernet protocol? Or maybe no one knows or cares? But I was wondering if implementing the protocol could be another alternative to flashing Remora to supported boards. While waiting for Mesa stocks to recover, I am really just curious to understand the technical side of the LinuxCNC vs Mach3 comparison. cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
