Advanced Search

The tool path needs to be plotted relative to the work piece. (tool -> world -> work)

The problem is that your tool position is plotted in World coordinates (tool -> world) which works if only the tool moves because the Work coordinate system remains identical to the World coordinates.
However on a machine like yours where the tool AND the work move in space the plotter needs to track both the tool tip as well as the work piece.
This is why the 'vismach' tool needs the capture() function for the tooltip as well as for work.

Not sure but maybe the backplot in ProbeBasic only plots tool position in world coordinates instead of plotting tool position in Work coordinates?

Hi, What piece You need?

If you don't mind updating LinuxCNC, you might be better off with more current replacements for the 5I20:

PCIE --> 6I24-16
Ethernet --> 7I80HDT

The 5I20 is a 20 year old card...

Do you have the step/dir pinout information for the drive?

It does look like it may be single ended from the pictures of the
step/dir modes.

Also in your .ini file, you have the PID P term set to 0.
This should be 1000 (for a 1 ms servo thread period)
A 0 P term will cause position drift

See GIF file I have uploaded. The tool marker from view port is moving in opposite direction. I want it should be below spindle tooltip. As it moves while jogging in X or Z direction. But Y jogging time, table is moving correctly. But tool marker is moving in opposite direction.

How can I resolve this?

The problem is that the backplot needs to move with the table.

I suspect that is already in the works. 

its not wrong, which direction is the "TOOL" moving through the work?

great! glad you got everything setup! now ONLY use the apt install for the rest of the probe basic install!

   


As per your instructions I have made vismach file for my small cnc.But CNC movement if GUI is correct. But Tool movement in Y direction is wrong.My yaml file.
 

Hallo Leute,

da dieses Thema bei mir in Kürze ansteht (ebenfalls unter Probe Basic), versuche ich mich hier schon mal schlau zu machen.
Soweit meine Suche aktuell ergeben hat, gibt es zum Thema ATC mit Rack keine wirkliche Anleitung?

Ich finde leider irgendwie immer nur Schnippsel z.B. zum Thema Remap.
Woanders habe ich dann die benötigten Variablen gefunden.
Dein Toolchange-ngc - Skript scheint auch sehr interessant zu sein.

Was mir jedoch fehlt, ist hier einfach mal eine Art roter Faden wie man sich hier strukturiert durcharbeiten soll.
Was muss ich in der HAL wohin mappen (MESA 7i96s) um die Steuersignale raus und die Sensoren rein zu bekommen.
Was in der INI (gut den Tab habe ich aktiviert), wo passe ich z.B. die Anzahl der Pockets an ....

Hat hier evtl. jemand einen Info, Link, Anleitung oder finde ich das einfach nur nicht?

Danke Euch schon mal

Hi PCW,

I hope this is what you are talking about. We have our pn200 setting set at 5. Let me know if there is anything else I'm missing. Thank you for your time.

 

I’m currently restructuring my CiA402 integration to make it more modular and deterministic before going back to real EtherCAT hardware.
Instead of debugging everything at once (LinuxCNC motion + EtherCAT + CiA402 + drive behavior), I decided to isolate the CiA402 logic layer and validate it independently inside AXIS SIM.
Overall Structure (3 Layers)
I’m organizing the system into three logical layers:
1) Motion Layer (LinuxCNC)
Standard LinuxCNC motion/joint layer. No changes here.
2) CiA402 Adapter Layer (custom HAL component)
This is a dedicated HAL component responsible for:

• Mode request (6060), e.g. Homing = 6, CSP = 8
• Waiting for 6061 (opmode_display) confirmation before proceeding
• Generating controlword transitions (6040), including homing start (bit 4)
• Mask/value-based evaluation of statusword (6041) for homing done
• Optional mask/value error detection
• Slaving pos_cmd to pos_fb during internal drive homing

This layer does not know about EtherCAT transport.
It only works with abstract CiA402 objects (6040, 6041, 6060, 6061, 6064).The idea is that this logic should work identically whether the transport is:

• lcec (EtherCAT)
• some other fieldbus
• or a simulated drive

3) Drive Stub (Simulated CiA402 Drive in HAL)
Since I don’t have EtherCAT hardware connected right now, I implemented a simple CiA402 drive stub as a HAL component.
It simulates:

• Opmode request → opmode_display with delay
• Rising edge detection of controlword bit 4
• Homing runtime (configurable cycles)
• Statusword “homing done” pattern (e.g. 0x1400 by default)
• Actual position feedback

This allows me to validate:

• Proper gating on 6061
• Correct controlword sequencing
• Deterministic servo-thread behavior
• Statusword mask handling
• HAL wiring correctness

All running inside AXIS SIM.

Relation to Existing Work (rodw, dbraun, EL8)I’ve reviewed:

• dbraun’s hal-cia402 implementation
• rodw’s cia402 component used with lcec
• The Leadshine EL8 integration example

All of them are valid and functional in their intended context.However, my goal here is slightly different:I want a clearly separated CiA402 logic layer that:

• Can be tested without EtherCAT
• Is not tightly coupled to lcec internals
• Can support both internal drive homing and CSP cleanly
• Can later be extended for tandem gantry supervision (Y/Y0 squaring)

This isolation makes debugging much more controlled and avoids mixing transport issues with state-machine issues.

Why Mask-Based Statusword Evaluation?
Instead of hard-coding something like “bit 12 = homing done”, I’m using:(statusword & mask) == valueExample:0x1400 (bits 10 + 12)The reason is simple:CiA402 allows vendor-specific interpretation and combination of bits.
Different drives report homing completion differently (sometimes bit 12 only, sometimes 10+12, sometimes additional bits).A mask/value approach allows:

• Drive-specific configuration
• Future-proofing
• Cleaner abstraction

If mask = 0, the adapter falls back to default CiA402-style bit interpretation.

Long-Term GoalThe final architecture should support:

• CSP as primary motion mode
• Internal drive homing
• Tandem gantry (Y/Y0) with squaring
• Optional gantry delta supervision during homing
• Clear separation between CiA402 state logic and EtherCAT transport

So conceptually:Motion → CiA402 Adapter → Transport (lcec) → DriveAnd currently:Motion → CiA402 Adapter → HAL Drive StubOnce validated, I’ll replace the stub with real lcec + cia402.If anyone has feedback regarding:

• Best practices for controlword sequencing in CSP
• Clean homing mode transitions
• Gantry homing supervision patterns
• Mask-based statusword handling

I’d appreciate technical input.

@Andrax
I’m currently restructuring my CiA402 integration to make it more modular and deterministic before going back to real EtherCAT hardware. My goal is to formalize the state handling and timing assumptions first, instead of patching behavior incrementally.

I think studying industrial PLC CiA402 homing FBs is a good idea conceptually. Even if the source code is compiled, the documented state diagrams and the Execute/Busy/Done/Error behavior usually define the real logic contract.

If you have access to an EtherCAT PLC with CiA402 homing FBs, could you share the documented state diagram or the Execute/Busy/Done/Error sequence? That would help us model a proper state machine for LinuxCNC.

I plan to open a separate thread focused specifically on formalizing the homing state machine. If you're interested in contributing your PLC perspective there, I think that would be very valuable.