> > 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
> > 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
> > 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 comma
> 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 aski
>
> 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 v
> > 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
>
> > 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 wo
> 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.
>
> > 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 com
> > > > 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 insi
>
> > 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
> > 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 ther
>
>
> > 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. A
> > 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 direct
> > 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
> > 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
> 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 pr
>
> 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 Li
>
> ...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@li
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.
20 matches
Mail list logo
