Advanced Search

A new homing method, external_homing. Can box in motion with limits and time.
A variant could be external_synchronized_homing for gantry homing.
With additional limits on start positions maybe and max difference in position.
And so on. Done by motion/motmod. Communicates with pins to the drive component as usual.

Maybe also a new freewheeling mode and pin for motion/motmod.
For opmodes that disconnects the position.
Position is usually right from the drive even when opmode changes.
But you don't need to control the position, just follow it.
I think one need to go over all  opmode switches and see which situations can appear.
 

mmm. interesting

I may wind up making it self contained, as not all my customers will use linuxcnc.

it could run linuxcnc self contained. or we could make it much more simplistic on an arduino.

The way the system is now its down to 2 coordinated linear axes, one fixes linear axis (most likely to be an air cylinder) and one for rotating, which might be best served with a servo axis. not sure yet.

thanks

Okay. Once you get a crash, post the output here and we can try to work it through together. Please ensure that you have some print statement in place of the commented out assert call, so if it fails there, we know about it. Something like:

Because the OP is on the Ethercat bandwagon (as are the commenters),
I have wondered about a seperate Ethercat component that does not consume an axis. I was mostly thinking about spindles but it might be able to morph into something with position control.


EDIT Running it on a seperate thread may give you enough independence...

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.