Advanced Search

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.

Hello! I need 1 piece. Can I buy it separately or do you only sell them together? Please let me know how I can buy it. How much does shipping to Hungary cost?

Good morning, I need cards MESA 5I20 FPGA PCI Anything I/O Card LinuxCNC 12 Axis. Does anyone have one available for sale?

Sudo apt --fix-broken install didn´t work. I used the Synaptic Package Manager. I used Broken Filter, deinstalled it.
Then sudo dpkg -i linuxcnc-uspace_2.9.8_amd64.deb again and after it sudo apt install linux-image-rt-amd64 and restart.
Now i have the Preempt Kernel and Linuxcnc 2.9.8 installed

Seems to work now

Das ist ja so wie eine Deckel FP1 ein Motor und dann über Schalthebel
die Achse zuschalten….
Das erfordert ein etwas komplexen Mechanichen Eingriff !!!!


Gruß
Juergen

Ja ein Seperater RCD ist eine gute Wahl dann aber den richtigen
Nicht den 08 15 das Schütz soll stören seltsam dann müssten die
Störungen weg sein wenn man es brückt oder die Störung tritt nur auf beim ein und Ausschalten…
Ich habe nach wie vor das Netzteil im Verdacht erzeugt ja keine echte 5 V sonder eine PWM das läst sich aber rausfinden Netzteil weg und das Raspbery mit anderen 5 V versorgen ….


Gruß
Jürgen

ja der ich möchte sie gern "ursprünglich" halten 1 Servo 3 Kupplungen

It is relatively easy to have a halpin execute the current mdi command in gmoccapy.py:

create the pin:


Create the handler:

As mentioned above, you would want to remove all other events in 'hal_mdihistory.py' that currently execute the 'submit()' function (eg. double clicking on an entry):
github.com/LinuxCNC/linuxcnc/blob/master...l_mdihistory.py#L151

GUI development in LinuxCNC has, generally speaking, not been driven by industry standards but by what is convenient and the easiest way forward, which is also what most lower end users want.
Personally I would welcome a GUI that could at least be configured to only allow initiation of physical machine movement through hal pins. This would also remove the possibility to start a tool change by mouse click from the GUI.

Hi, 
@3404gerber
I am using this configuration and it works so far. There are only massive problems with security issues. But that's another matter.
Provided that homecomp.comp has not been changed, it should work.

@Konstatin
You have massive EMC problems. dmesg shows a bunch of errors even before Linuxcnc is loaded.
1. CAT5 cables are unsuitable > use CAT6
2. Use short cables, no loops!!!
3. Lay cables away from other wires
4. Attach Feritt cores
5. Servo interference suppression EMC filter

6. Only when “dmesg | grep ethercat” shows no more errors before starting lcnc can you focus on the lcnc configuration.

 

tar_san wrote:

And I think .. sometimes updating new ESI to older software version device is a little bit risky..
I'm considering a little bit about it.

Yes, the ESI file must agree with the firmware in the drive.
I thought about warning for that, but since you were in contact
with Yaskawa support I thought they must know, they should know.

I think the data looks okay for you Hannes, and it seems likely that the firmware on your pendant doesn't support the F/S indications. I am not setup to build linuxcnc on this machine right now, but here is a screenshot from Wireshark showing the same type of data as your terminal output:
 
The highlighted line is the last part of the report, where the feed and spindle overrides are given. For me, both were at 100% = hex 0x64. My pendant also shows the F/S values in auto mode when a program is running. Many different firmware variants, I suppose...

I've had LinuxCNC simulation running a long G-code program a couple of nights to see if I can find some issues with my dongle firmware. So far, no disconnects nor any other meaningful issues. Sometimes (around 0.0035% of the time) it send a zero-length package, which is not correct, but neither is it harmful. I will try to look over the USB handling to see if I can get rid of that one.

Das einzige ähnliche Umbau der ich kenne ist This Old Tony's Video Series, aber er hat sein MH400 umgebaut auf 3 getrennte Achsen Motoren, und KUS.