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 <emc-developers@lists.sourceforge.net>
To: Torsten Curdt via Emc-developers <emc-developers@lists.sourceforge.net>
Cc: Torsten Curdt <tcu...@vafer.org>
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
