Advanced Search

Affordable and 4500 rpm may not go together! Anything over 3000 rpm is hard to find and not affordable by many standards!

One other possibility I considered, if it is possible to run just one at a time?
Could it then be done pausing the one and temporarily switching kinematics to run the other set of axis... say, toolchanger?

I've been thinking about this for some time.

Obviously the easiest way is probably going to be to run a second LinuxCNC pc. (Assuming I'm doing everything in LinuxCNC.)

Then I was thinking about the possibility of running a custom multi-instance capable tp component consisting of something like:
GUI <-hal-> [tp.0, tp.1, tp.2] <-hal-> [trivkins.0, scarakins.0, scarakins.1] <-hal-> I/O (mesa, lcec, etc)

Definately re-inventing most of the wheel. Can we make it any harder?

Thanks, that's basically what I thought

LinuxCNC has a single realtime motion module (motmod).
All coordinated motion and joint updates go through that one trajectory planner and queue.
Even if you configure additional axes (U/V/W etc.), they still belong to the same motion instance.
There is no concept of a second independent motion channel inside one LinuxCNC process.

Industrial controllers sometimes give the impression that this should be possible because they support true multi-channel motion. For example, platforms like Omron Sysmac can run multiple independent motion groups or program contexts in parallel within the same controller. That capability is built directly into the motion kernel.

LinuxCNC, however, is architected around a single motion instance per process.

If you need the tool robot to move while the main machine is cutting, the practical solutions are:

• Run a second LinuxCNC instance / second controller for the tool robot and handshake via IO/fieldbus.

• Use an external PLC/MCU/drive sequencer for the robot and trigger it from LinuxCNC via M-codes or IO.

A “HAL-only second planner” is technically possible, but then you own all the safety, limits, interlocks and coordination logic yourself — and it tends to become fragile fast.

So i had a craaazy idea for a little robot tool library.
Wondering how you would implement it in linuxcnc.

So we have our XYZA on our cnc. lets reserve B just in case we ever need a 5th.

That leaves 4 more axes available.
Our little tool robot will have an x2 y2 z2, and a x3 (fixed motion, likely air) and C do pivoting the gripper - again fixed motion.

Basically it is a cnc of its own, and needs to operate while the main machine is cutting so it can sort and stage tools. This is different from using C for an atc platter that is actually coordinated with the main machine.

How could we do this?can we decouple these new axes from the main motion as a "channel" ?



 

I already have a pure SIM validation setup working (HAL adapter + drive stub). The goals there were to make the logic deterministic and debug wiring/handshake issues before touching real EtherCAT hardware. In SIM I’ve validated:

6060/6061 opmode handshake

bit4 start pulse generation

done mask/value detection

stable statusword behavior (no flicker)

basic “homed” behavior (latched)

So the current work is no longer “does it wire up?”, but refining the architecture to match industrial semantics.

@rodw — yes, exactly: your procedure returning 1 at Operation Enabled is the clean gate. I’m using your barebone logic as the base for a dedicated PDS manager layer: until op_enabled == 1, nothing else (homing or motion modes) is allowed to run. Once op-enabled is reached, then we proceed with homing / CSP.

@Hakan — I also really like your point about not blaming the drive for moving during internal homing. That’s actually the main remaining behavior I’m refining now: instead of freezing targets in a hacky way, it seems cleaner to make the controller follow feedback during drive-internal homing.

So while homing is active:

motion/target follows feedback (pos_cmd := pos_fb)

when homing completes, CSP can resume with zero discontinuity (no jump)

Next steps:

implement the separate PDS manager (based on rodw’s barebone + timeouts + fault reset pulse)

implement mode modules (homing/CSP/etc.) gated by op_enabled and 6060/6061 confirmation

once the layers are solid in SIM, re-integrate with lcec + real hardware

If either of you sees a pitfall in the “motion follows feedback during internal homing” approach, I’d love to hear it — but it looks like the cleanest way to avoid discontinuities when returning to CSP.

Das sind die A6-400EC 400 Watt EtherCat Treiber. Laufen mit einphasig 230V AC. Da die das cia402 Profil nutzen lassen die sich ganz normal mit LinuxCNC und der cia402 Komponente ansteuern. Beispiele für die ethercat-conf.xml gibts hier im Forum ja genug zu den A6 Treibern.

An sich stören mich die IOs der Treiber nicht aber ich finde das übersichtlicher/sauberer wenn alles auf die Beckhoff Module geht. Keine Lust da jetzt noch irgendwelche d-sub stecker zu löten für die Treiber. Habe durch mein Bedienpult nen haufen Digitalein- und ausgänge und mit den Beckhoff Modulen hab ich das schön sortiert.

Ich nutze die Treiber im inkrementalen Modus und referenziere nur über linuxcnc und nicht über den Treiber selber

How about if we don't blame the drive for moving by itself during homing,
and instead make "motion" understand that it should follow the position feedback?

For several days now I’ve been getting the error “Motor 0 position error” whenever I try to move Motor 0 (X-axis). At the moment, only this motor is connected.The setup uses a DM556Y driver with a NEMA 23 motor.

I’ve attached the .hal and .ini files.

I hope someone can help me figure this out.

thanks everyone

  [/code][/code]

Still trying to learn exactly where in the code it fails.
It doesn't reconnect, that's for sure. If it had, it wouldn't have been an issue.
I overwrite the log and, alas, no saved useful log.
"Unfortunately" I didn't get a crash today when I worked with the machine.
I like the whb04b a lot.It's worth spending some time improving stability.

 

There's hope yet 

I'm trying to set up the DB25 board to connect to a geckodrive G540 and running into some confusion. Currently reading the byte2bot guide on this and I'm confused about the hal_gpio pin naming. Where are these pin numbers for "pi5 2025" coming from?  They don't seem to match any pin mapping I've seen in any other online source. Do I use the 2023 or 2025 one? 

Image of pinout naming matrix below.

Hallo @nichtAlex, 

welche Treiber sind das von StepperOnline? 
Ich überlege, die A6-Serie (AC) zu nehmen, doch die von StepperOnline konnten mir nicht versichern, dass diese mit LinuxCNC funktionieren. Sie glauben es zwar, getestet haben sie es aber noch nie. 

Was mich noch interessieren würde: Was stört dich an den IOs der Motortreiber, sodass du sie nicht nutzen möchtest?
Hast du den Home-Eingang dann nicht in Benutzung? 
Sind das AC- oder DC-Motortreiber bei dir? 

Gruß Mücke 

I think that's a good thought, however, I've found M19 is not available to directly remap according to this .
14.1. Existing codes which can be remapped
The current set of existing codes open to redefinition is:
Tx (Prepare)
M6 (Change tool)
M61 (Set tool number)
M0 (pause a running program temporarily)
M1 (pause a running program temporarily if the optional stop switch is on)
M60 (exchange pallet shuttles and then pause a running program temporarily)
S (set spindle speed)
F (set feed)