link two different signals to the same output

I'm sorry for renaming the topic, but I'll keep your note in mind.

I'd prefer a parrallel of the 3 axes, but after home-all activity that doesn't disturb me. i don t need any pauses or confirmations or turning off the carousel homing function.

the most simple is good for me

Are you still in the building/fiddling phase of your ATC, or have you tried it out yet in meat-space?

Reason I ask is that carousel.comp will automatically home the carousel to position-1 the first time it's enabled (when carousel.comp is in INDEX or COUNTS mode).

So unless there's another reason (see below), you can just run your first tool change and it'll take slightly longer.  Carousel will home, then go to the commanded pocket, and then set carousel.N.ready HIGH so that your toolchange macro sequence can use the 'ready' signal to make the next move (whatever that is in your tool change choreography).

If you really want it to home during the axis homing sequence, we'll have to cook up a connection scheme using something like halui and a user M-code.

Mine looks like this in hal:
And the mdi-command-02 calls M13. 

M13 is mapped to m13.ncg, which sets the carousel destination pocket to 1 (M68), then carousel enable (M64), then checks for carousel ready (M66), then disables (M65).

The above results in the ATC homing immediately after all the axes are homed, or I press a button because I want to fiddle with the ATC and I need it to home without screwing around homing the whole mill.

There's other stuff in M13, but the only reason I don't just let carousel do it's thing automatically is that I'm using the Probe Basic GUI... and the on-screen ATC animation is controlled through some secret-code gibberish contained in the M13 macro.  It's all there to keep the screen dingus synchronized with the meat-space ATC.

 

I think I can see the procedure, we create a macro and activate it using the mdi, but I've validated the mandatory home condition, I don't think I can use the mdi when the homing is not done. Can I create a macro that doesn't respect these conditions?

As with everything in LCNC, there's a bunch of ways to skin the cat.

You can activate a macro before homing if you have [TRAJ] NO_FORCE_HOMING = 1 in your INI file.

Another way is to use classic ladder.  This gets a little complicated, but:

• connect your buton-in (physical or GUI button) to a classic ladder bit-in pin
• set up ladder to trigger an out-bit pin using whatever conditions you want
  • can add some interlock logic with other pins - machine-on, mode-is-manual, etc.
• A ladder out-bit pin is connected to an or2.N.in0 pin
  • can use a rising or falling edge coil to 'blip' the out pin so it doesn't stay high if you're using a toggle
• The other or2.N.in1 pin is connected to your existing carousel enable signal
• or2.out is connected to carousel.N.enable
  • Even if you blip the enable pin it'll complete the homing routine

There are other ways to do it, but those are the first couple off the top of my head.

I tried with macros.

To try this, I configured my config like this

INI

[RS274NGC]
REMAP= M901  modalgroup=10  ngc=home_carousel

[HALUI]
MDI_COMMAND = M900 (it is for other thing)
MDI_COMMAND = M901

[TRAJ] NO_FORCE_HOMING = 1

NGC - home_carousel
hal
But no movement from my carousel when I press the home-all button. I presume that halui.home-all is not correct, what can I replace it with?

 

Does the 901 macro run from the MDI screen? (not calling it with hal signal)

If so, can you watch the pins and signals in halshow and see if they all do what you expect?  That's the best way to diagnose this sort of thing.

I'd also run LCNC from the command prompt in a terminal and watch for an error when you run the 901 macro - either from MDI or via the halui.home-all button.

Basically trying to figure out if it's the macro or the hal connections.