Advanced Search

Hello Andypugh,

This modification was really helpful in last machine I made. I'm now trying to achieve similar but Linuxcnc has changed a alot. Also changed a lot in kinematics. I tried to modify kinematics as per this thread but as expected it's failing with errors.

I want to use XZ and B axis with TCP along with tool length probing. Setup in this thread is working in older version.. I'm struggling to getit worli with Debian 13 rt 2.9.8 Any help or suggestions would be appreciated,


Thanks

Hello Aceiera,

I'm also trying to achieve similar 4Axis TCP kinematics. I want to use Rotating spindle head and XZ gantry with fixed table. No B or C axis. I tried to compile 5Axiskins by removing C axis values but not accepting compilation. Any help would be appreciated.


Thanks

djdelorie wrote:

or if there's some magic to restore it only if the next move is anything other than a G0XnYn move (i.e. G1 or G0Zn)?

You could consider adding the required magic with a Gcode filter that is applied when files are opened...

I suspect the next thing (that causes intermitent latency spikes) is energy efficient Ethernet (EEE) disable it.
Also set the governor to performance.

Warxcell wrote:

MB: P5g41t-m lx
CPU: Intel Core2Duo E7600
Memory: 4GB Ram.

2 cores is not enough anymore. You need 4 cores, 8 gb might be better but 4 gb will work.

This sounds like an autorepeat issue I've experienced in the past.

To test if it is, open a terminal window, and enter the following command:



Launch LinuxCNC and jog around. If the problem goes away, that's the issue and we can come up with a more permanent solution.

To turn autorepeat back on:

Definitely 2.7.

Hallo zusammen, 

da ich aktuell etwas an meiner Maschine abändern möchte, muss ich mal wieder alles nachschlagen. War ja klar, dass ich mir nichts merken kann. Das wäre ja zu schön. Spaß beiseite. 

Mir ist aufgefallen, dass Google zwar viele Einträge hat, die Seiten aber nicht mehr existieren.
Z. B. bei der Suche nach „PyVCP”:
Ergebnis: linuxcnc.org/docs/devel/html/de/gui/pyvcp.html

Das ist mir nun schon öfter aufgefallen, daher wollte ich fragen, woran das liegt. Wird gerade viel umgebaut? 

Gruß
Mücke 
 

The manual for your drive (pages 27–28) shows that Digital Output 5 (pins 19–20) and Digital Output 6 (pins 21–22) are digital output pairs rated to switch loads up to 200 mA. Output 6 can be used to send a stop signal to your system, indicating that the drive has entered stop mode.If your goal is to feed an external E‑stop signal into the drive, you must wire that signal to  digital input IN1 (Servo Enable) as shown in the wiring diagram on page 26.The reference to “differential input” in the documentation is simply a translation error and can be disregarded.

MB: P5g41t-m lx
CPU: Intel Core2Duo E7600
Memory: 4GB Ram.

Thanks Rod!

I have done all that already except using dkms driver. It is an Intel NIC (e1000e) not realtek... Now time will show if it is fixed

With Z0 and Y0 both sitting on the center of rotation in CAM, the G52 Y correction only compensates for the actual clamping offset of the stock, and the orbit problem doesn't arise. The part isn't referencing a point on the stock that moves with it — it's referencing the fixed axis center.

I still fail to understand the point of probing and using an offset.  What exactly are you offsetting?

• If the actual CoR position is not known and you probe the part - you don't know how far to offset.
• If the actual CoR position is known and you probe the part, you know how much to offset, but
  • the CAM doesn't know how far you've offset, so features will be machined in relation to the CoR, but not to the stock position
  • In the case of a profile-type toolpath - depending on how far offset the stock is from actual CoR - you will need extra material on one side and risk taking an extra-heavy cut on the other

If you position the part mostly in-line with the actual CoR and program a bit of extra stock in CAM, you will never need to probe and you will never plow in to unexpected material.

Yeah, I didn't think there would be any magic, but I figured I'd ask. My files come from various sources so "do it in post" is not reliable enough unless EVERY post does a G0XY before any GZ.

Oh, right,
I use the CIA402 and CIA402_homecomp by Colin Bardini. It works very well on XYZ machines.
However, there are generally issues with XYYZ machines.
It can happen that during homing, only one gantry axis moves. The other one stays still or starts moving late. It’s a known issue. 
@Marcos DC has taken on the problem. The current status of the work is unknown.
forum.linuxcnc.org/ethercat/58592-cia402...ation-easier-debuggi
There may also be issues with jitter.
Read more here:
forum.linuxcnc.org/ethercat/58103-ethercat-random-jitter-fix
@rodw has already incorporated all of this into his repositories and created installation instructions. I can’t find the link right now.

regards

andrax

Thanks so much for the detailed response and the PathPilot macro — really appreciated!

You're absolutely right that blindly setting G52 Y without accounting for Z would cause the orbit problem you described. That's an important warning and worth highlighting.

The key assumption I should have stated more clearly upfront: the CAM origin must be placed on the rotary axis itself — not on the stock surface. With Z0 and Y0 both sitting on the center of rotation in CAM, the G52 Y correction only compensates for the actual clamping offset of the stock, and the orbit problem doesn't arise. The part isn't referencing a point on the stock that moves with it — it's referencing the fixed axis center.

With that setup in place, I think TCP isn't needed either — Fusion pre-computes all positions for a table-type A-axis, so the controller just executes straight X/Y/Z/A moves.

Thanks again for pushing back on this — it forced a much clearer explanation of the preconditions.