Advanced Search

No. The tool change position has to be commanded in the Gcode. The tool change on this mill is manual.

Thank You!
-Steve

This might be still related to the fact the Yaskawa does not support LRW

github.com/sittner/linuxcnc-ethercat/issues/121

forum.linuxcnc.org/ethercat/48110-etherc...-responding?start=20 (there seems to be a patch / experimental code further in the thread)

Not sure if this was ever resolved in any linuxcnc-ethercat version.

I have these snippets right now. The first is the original behaviour and the next one is after a full day of tweaking the PID values and acceleration. In both the axis moves very slowly.   

You could send them one of the sample programs that is installed with LCNC.  Like chips.ngc.

Keep in mind that your tool changer is going to be specific to your machine and LCNC configuration, especially if the tool change sequence requires anything beyond "M6 Tn G43" in it.

Example - does your machine require the post to raise the head to a safe point before the tool change M-code is commanded, or is that part of the internal change sequence?

Same for any custom or machine-specific M-codes.

Ich wuerde sagen du schaust dir Parameter P04.04 an. Laut Chinglischer Anleitung steht da sowas wie: "3 ： When any frequency arrives, it will be powered, otherwise it will lose power (related to the setting of P02-10)"

Frei Plattdeutsch bedeutet das soviel wie:

Wenn P04.04 = 3 (Frequenzvorgabe erreicht) dann schaltet das Relay.

Verdrahtung:

Du nutzt NO (normally open):
• VFD CM → 24V Versorgung (+) anlegen
• VFD NO → Mesa Input (z.B. IN05)
• Mesa GND bleibt wie gehabt

Waehle einen freien Input an der Mesa und verdrahte.

In deiner HAL kannst du das dann verbinden:

net spindle-at-speed hm2_7i96.0.7i96.0.0.input-05 => spindle.0.at-speed

Der Input ist nur ein Beispiel. Schau was du frei hast bzw. wie genau der Input bei der 7i96 heisst. 

Can you plot (with halscope) the C axis commanded and feedback positions?

That would help diagnose the issue.

I do not use RPI but 126000ns is 126us or 0.126ms, so should still be OK for mesa boards.

No not that old. But maybe I lack some general understanding.
1. my raspi4 gets an base thread may jitter of 126 ms (126000 ns), which is supposed to be not usable for linuxCNC ( so why is there an image for that?)
2. or is the mesacard exactly there to address that problem with it's FPGA?

Sorry for the somewhat below rookie-level questions

Do the old PC's have a parallel port on the back side, the violet/pink colored 25 pin one?

ballscrews ar primary because the original threads in brass nuts have quite some deadway. But yes, it is all metal and the swallow tail rails are even adjustable. Plus it is the same model the other guy was using for years.
Only difference so far: He used a setup, where the motor was separated from the machine with a belt transmission and the z-axe was only moving the milling bit.

Also: I thought I might use one of my older PC standing around, but the latency test told me other wise (150ms and above).
Next try raspi4...

Al that seems fine, but, is the machine stiff enough so it justifies ballscrews?
Is that the really small mill with metal ways? That should be OK.

Die 10V muss auf dem FU an Mesa 7i96S gehen, da sind klemme fuhr GND, AI, und +10V an die FU.
Edit:
My bad, missed the part where spindle works, sorry.

Good Afternoon,

I am in need of a 3 axis milling sample program. I am converting my Anilam Crusader M 3 axis mill to LinuxCNC. I use Gibbscam and in order to help me with the post processor they need a sample program that contains gcode that generate lines, circles, tool changes, etc. I sent them a link to the LinuxCNC G Code catalog. Any help is greatly appreciated.

Thank You,
Steve in Indy

I was thinking that 1:1.45 overdrive of the spindle could be an issue, but it just doesn't make sense that it would also misbehave without encoder feedback, when it's just an open loop system.

The motor is rated 5.5kW. It's on the slower side but the torque should be plenty I'd think. I've spent the last night rolling around thinking of this and I'm pretty sure it must be something to do with step scaling, accel values or something like that. Maybe there is too many steps? 10k per revolution and it's causing issues for unknown (to me) reason. I will try to test that next and see if that makes any difference.

Thank you, it was the analog line of the Z axis, it was switched around. Switching it and inverting the output scale from 60 to -60 did the trick.

Now I wonder how it worked in the first place. I think the GND of that connection must have been bad, and when I added the index lines, it got connected.