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 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] [Emc-users] Why not have a trivkins setup with a slave axis
On 2022/04/16 08:55, Marius wrote: On 2022/04/15 18:58, Andy Pugh wrote: On 15 Apr 2022, at 12:52, Marius wrote: Just wondering why is it not possible to have a standard three axis trivkins setup with a possibility to slave a stepgen to any one of the axis. You can do that. In fact it is very easy. net joint.0.motor-pos-cmd stepgen.0.position-cmd stepgen.4.position-cmd ie pass the position command to two stepgens. I discovered that eventually. It works very well. ___ Emc-users mailing list emc-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
