> > 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