Machsupport Forum

Mach Discussion => Mach4 General Discussion => Topic started by: roebling on April 09, 2021, 11:02:36 AM

Title: mcSignalWait issue
Post by: roebling on April 09, 2021, 11:02:36 AM
I am trying to home axes within a macro, and need to base subsequent action based on whether the axes homed successfully. OSIG_HOMED_X (or other axis) gives me the signal I need for the macro to proceed, but mcSignalWait doesn't seem to operate on Mach 4 output signals, although I can't find any documentation that confirms that.

Any ideas on how to confirm that an axis successfully homed?
Title: Re: mcSignalWait issue
Post by: Bill_O on April 09, 2021, 11:14:15 AM
I set a register after a home and then look at that register.
I am sure it is not the best way but it works well.

Title: Re: mcSignalWait issue
Post by: GOOMBA on April 09, 2021, 11:21:19 AM
homed, rc= mc.mcAxisIsHomed(
      number mInst,
      number axisId)

This should report back to the var true or false
Hopefully this helps.
Registers also work, and it's easy to look at a register from a macro :)
Title: Re: mcSignalWait issue
Post by: roebling on April 09, 2021, 11:51:15 AM
Thanks for both suggestions. I have to have the macro run some G-code after confirming the axes are homed. I'll reveal my ignorance by asking how to make use of either the register or mcAxisIsHomed state to make the G-code execution conditional, without something like mcSignalWait. Use a loop that keeps checking for axis homed state before proceeding?

mcSignalWait does just what I want when I've used it with input signals, and it has both timeout and returns error codes. I was hoping to avoid going to far into lua scripting to get what I want, but I will go whither thou goest :)
Title: Re: mcSignalWait issue
Post by: smurph on April 09, 2021, 02:40:30 PM
You can home with code.  See G28.1 in the manual.  Homing with G28.1 is the ONLY way to home the machine in automatic mode (not idle). 

G28.1 X0 Y0
G00 X1 Y1 (Both X and W will be homed by this point). 

If you are homing the machine from a script, you have to start the script from the idle state.  Otherwise the home operation will fail and you will wait on a signal forever or timeout.  But you would know this if you checked you API function return code, right?  :)  Because the mc.mcAxisHomeAll() function would return mc.MERROR_NOT_NOW if you are not in the idle state. 

There are a few ways to check when the home op is done
1. mc.mcSignalWait() for each axis you are interested in.
2. mc.mcAxisIsHomed in a loop for each axis you are interested in.
3. mc.mcCntlGetState() in a loop.  Once you start the home operation in the idle state, the state will no longer be idle.  So you can wait on the state to go from idle to non-idle and back to idle if you want. 

Code: [Select]
local rc = mc.MERROR_NOERROR
rc = mc.mcAxisHomeAll(inst)
if (rc ~= mc.MERROR_NOERROR) then
    -- the mc.mcAxisHomeAll() function failed and we must NOT wait on a signal
--  now you can use mc.mcSignalWait() or mc.mcCntlGetState() or mc.mcAxisIsHomed() to find when the home operation is finished.

Title: Re: mcSignalWait issue
Post by: roebling on April 10, 2021, 11:25:20 AM
Wow--I did not know about G28.1 for Mach 4--thank you. I've only used G28 before, and since I want to home the axes in the sense that I want to each to go through their homing routine (programmed feed rate to home sensor; back off sensor; zero axis; apply offset, if necessary),  G28 doesn't work, since it's only sending the axes to their assigned home positions.
    However, G28.1 seems to work strangely for me: each axis assignment seems to require a location (G28.1 X0, for instance; G28.1 X not allowed). The axis appears to rapid to that coordinate, then rapid to the home position, rather than using the programmed feed in the Homing/Soft Limits setup (or in the Homing section of the ESS plugin setup, in my case). The rapid movement causes to the homing to fail. (This is a custom assembly machine, and some high-speed axes need to approach the home sensor at only 3% of their max, or rapid, rate).
    G28.1 was the perfect answer for me, but I'm puzzled by its behavior, and the Mach 4 Mill Programming Manual didn't shed any more light on how it works, or what other arguments it takes. Does this rapid motion to home (or the intermediate position) make sense, and is it possible to modify that behavior?
    I think I'm headed to the checking "mc.mcAxisIsHomed in a loop route", since I had no luck getting mc.mcSignalWait() to work with OSIG_HOMED_X as an argument.
Title: Re: mcSignalWait issue
Post by: smurph on April 11, 2021, 08:22:02 PM
All position words (XYZABCUVW) require a position, otherwise there would be a G code syntax error.  The manual states that the positions given on the G28.1 block are ignored.  "G28.1 X0" or "G28.1.X150" should be no different than just pressing the Ref X button on the diagnostics tab.  All homing, whether from a button or via G28.1 is done on the motion controller.  Meaning all Mach does is ask the motion controller to home the axis.  So...  if you are experiencing strange homing behavior, check with your motion controller vendor. 

I tried mc.mcSignalWait() and it worked flawlessly.  Make sure you are not running an ancient build.  And are you checking your API return codes?  Because if mcAxisRefAll() returned mc.MERROR_NOT_NOW, then you would be waiting on a signal that would never come.  But if you didn't check the API return code, well... 

The GUI uses mc.OSIG_HOMED_X, mc.OSIG_HOMED_Y, mc.OSIG_HOMED_Z, mc.OSIG_HOMED_A, mc.OSIG_HOMED_B, and mc.OSIG_HOMED_C output signals to light up the axis homed LEDs on the screen, so they are working.