Advanced Search

tommylight wrote:

spincycle wrote:

I assume the procedure is similar for newer drives if running analog?
Yes.

spincycle wrote:

I would tune the velocity/torque in the drive software, then tune position through Linuxcnc.

Yes.

spincycle wrote:

It looks like a few of the modern servo drives I've looked at have encoder outputs. Those will just run back into a Mesa card like the 7I97?
Yes.
3 for 3, nice!
New drives can also be controlled by step/dir and also have encoder outputs, and those can again be used in LinuxCNC.
And there are several boards from Mesa that can be used, not just 7i97, a lot of combos there so when you are ready to order stuff, ask here first as we have the Mesa Master with us here, always, in the form of PCW.

Ace! Thanks Tommylight.

I have a 7i96 kicking around from a machine that never got off the ground, but I assume the lack of encoder inputs means I should use a different card.

This machine originally had rapids of 32,000mm/min with 16mm pitch ballscrews - 2000rpm on the axis. Would there be any benefit of analog over step/dir or even ethercat, to maintain such rates of speed and precision?

I just got off a 10hr flight. I took the original Bridgeport machine schematics with me to asses the control side of things. It looks like the Heidenhain output a 24v (sourcing?) signal to a bank of relays to control the solenoids, enables, mag motors, contractors etc. I assume a Mesa card, like the 7i84U could take this role?

It'd be bloody awesome if I could just retain these original distribution/control boards and halve the amount of wiring required!

Did you try, if the GUI updates changes in tooldata this way? Be aware it uses toolradius

G10 L1 P#5400 R


linuxcnc.org/docs/2.9/html/gcode/g-code.html#gcode:g10-l1


otherwise i have no idea

Yes,

programmer pinout is:

1  VPP
2  +3.3V
3  PGD
4  PGC
5  GND

Full (base and user part) R16 file is:

 

Sorry I could not get the remote update working with
the older base part. I will look into this when I have more time.
 

I've took additional measurements using the debug mode and terminal output. Attached is a video containing two following measurements.

In the first measurement, the feedrate value was constant throughout the probing. In the second measurement, the value was deliberately changed by feedrate potentiometer.



The terminal output shows that in the second measurement, the following lines were added:
[DEFAULT.QTVCP.QT_ACTION][DEBUG]  CALL_MDI Command: G91 (qt_action.py:182) 

The command M64 P4 at the beginning and M65 P4 at the end were added and are necessary for "turn on" and "turn off" of my probe.

Terminal output also in attachment:

Moved to "EtherCAT" section.

Farzad wrote:

Do we have input shaping in Linux CNC as Klipper in 3d printers ??

No, not yet, nor am i aware of anyone working on it.