Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: mhackney on May 09, 2022, 10:01:02 AM
-
I'm a 15+ year long Mach3 user on 2 CNC mills and now bringing up a router with Mach4. This issue is driving me crazy and is behavior I have not seen on mach3. Let me describe my workflow, then the behavior followed by what I've done to diagnose/solve the issue.
I'm on Mach4 build 4612, using the WxRouter.set screen.
I have a simple 3 axes router with home switches and soft limits enabled.
The way I like to work is this:
Home (Reference All Axes (hom) the machine after I turn everything on to make some cuts.
Clamp my work piece to my bed. I typically make onsies or twosies
Jog to the datum on the work piece and touch off the tool old-school using rolling paper
Zero X, Zero Y, Zero Z
Now I load and run my gcode.
Observed Behavior:
(unless I zero out the G54 section of the View->Fixture Offsets... table)
When I do the Reference All Axes (home) the machine homes as it should, I see the DROs turn green and set to "0" but then the machine immediately moves to the position set in the G54 of the Fixture Offsets table. I do NOT want this behavior. Many times, after the first job, I jog the tool out of the way to move my work and setup for another job. This new job will likely be in a different location on my router's bed and may be a thicker workpiece. Once I have the new workpiece clamped, I do another Reference All Axes (home) and expect the tool to stay at 0,0,0 so I can then jog to the new datum Zero the axes, load the gcode and run. But, it goes to the fixture offset and that might cause a crash into the material or a clamp.
I've used the above workflow on my milling machine for 15+ years and have never had an issue. I've never used fixture offsets and don't really have a need. If I zero out the G54 row of the fixture offset before homing, I get the expected behavior.
What I've done to Diagnose:
I notice when I launch Mach4 that the status line shows a string of gcodes that includes G54. In my case that line is:
G0 G17 G90 G91.1 G94 G20 G40 G49 G80 G50 G67 G97 G54 G64 G69 G15 G40.1
So I thought the logical thing to do is remove the G54, but I can't find where this string is created! I've looked at the load screen script, the Ref All Axes button scripts, etc. I've also looked at the Mach Config dialog and don't see where G54 is added. I've also looked at the Probing and Offsets tabs on the screen and don't see anything that can help.
My ideal scenario would be to have the workflow that I've used for 15 years. But, if there is an alternative workflow that works with this automatic fixture offset I'd consider changing if there were advantages.
thanks!
-
While exploring the Screen Editor I found where these gcodes are defined. I didn't realize that the line that shows these gcodes is dedicated to that task and the field on the screen is called Modal Gcodes. I then googled Modal Gcodes and learned that these are in the ModalWizard. I opened ModalWizard.mcs in an editor and sure enough, there they are:
local groupNames = {
"01: Feed mode",
"02: Plane selection",
"03: Absolute or incremental",
"04: Arc center mode",
"05: Feed rate mode",
"06: Units",
"07: Cutter compensation state",
"08: Height offset state",
"09: Active canned cycle",
"10: Retract Z level selection",
"11: Scale mode",
"12: Modal macro",
"13: Spindle mode",
"14: Active coordinate system",
"15: Cutting mode",
"16: Coordinate system rotation mode",
"17: Polar mode",
"18: Compensation mode"
}
This is the ordered list and item 14 is the one that inserts the G54. Is it safe to edit this macro? Is it as "easy as" removing row 14 and renumbering the other rows?
-
Well, I guess the this is not what the Modal Gcodes wizard does. Apparently, it reads the modal gcodes already set in the system and displays them with more detail in a nice table. Removing a row from the wizard table does not change what the modal gcodes are. But at least now I know that these are called modal gcodes so I can continue searching for that.
-
Ack, searching the entire mach directory did not get any other hits for modal or modal gcode. So back to square one.
-
Make a copy of your Mach4Hobby folder in case you mess something up before editing the screen.
If it is moving to the G54 position after a Reference All Home it is in the function RefAllHome() in the Screen Load Script.
You will need to edit the Screen Load Script
Go to Operator then Edit Screen
Under the Screen Tree Manager click the top listed wx4
Under properties select the middle icon (Events)
Next to Screen Load Script click on the words to the right then the button with 3 dots
Find RefAllHome and make your edits.
After your edits go to Screen then Save Screen.
Go to Operator then Edit Screen to exit screen edit mode.
-
Bill_O thanks. I had looked at the load script RefAllHome and it is not calling G54. Here is the code:
-- Ref All Home() function.
---------------------------------------------------------------
function RefAllHome()
mc.mcAxisDerefAll(inst) --Just to turn off all ref leds
mc.mcAxisHomeAll(inst)
coroutine.yield() --yield coroutine so we can do the following after motion stops
----See ref all home button and plc script for coroutine.create and coroutine.resume
wx.wxMessageBox('Referencing is complete')
end
I'm trying to track down mc.mcAxisHomeAll to see if there is something there but haven't found it yet.
-
I'll verify this later but I am fairly certain that after I click Reference All Axes (Home) that it displays the message "Referencing is complete" before moving to the table offset location.
-
It would not call G54 it would have a move command.
I do not see it in the code.
Are you positive it is moving after a Reference All Home?
-
Yes I am absolutely positive! I'll shoot a quick video of the behavior this evening.
And, if I clear the G54 row ( to 0s) in the fixture table before calling Reference All Axes, the move does not take place.
If I then jog to position on my workpiece and click the Zero axis buttons with the fixture table open, I see the G54's axis immediately updated with the offset. Then, doing another Reference All Axes will home and now move to that "fixture" location.
-
While in Screen Edit Mode click on the Reference all Axes button.
Under Properties on the left click the middle icon.
What is in the Left Up Script?
-
I've checked that and the Zero axis buttons. Here's what's in the Reference all Axes:
wait = coroutine.create (RefAllHome) --Run the RefAllHome function as a coroutine named wait.
--See RefAllHome function in screen load script for coroutine.yield and PLC script for coroutine.resume
-
I should say that I did a completely fresh Mach 4 install on a Windows 10 machine that had not previously had mach installed. This was in preparation to migrate to ESS smooth stepper. But, the old installation on the other computer also has this same behavior. Is this normal behavior?
-
Well i am lost.
I can not see where it would actually move.
-
Do you know where or how the modal gcodes are defined or set? And is this unusual behavior for mach4?
-
Not usual behavior at all as far as i know.
Go to Configure then Control
On the right side of the Defaults tab is a section Initialization Codes.
Put G53 in it to be in machine coordinates.
-
Go to Configure then Control.
Click on the Homing/Softlimits tab
Do you have any values in the Home Offset for x and y?
-
I don’t have any home offsets defined. And the movement after homing is exactly to the fixture offsets. I’ve done enough tests to verify that. I’ll try the G53 tonight. Thanks again.
-
You could enable logging and then look to see if something is executing GCode or MDI that's moving the machine after homing.
-
Hello,
So, what you're saying is you do the following.
1: Select ref-all-home
2: The homing routine causes the axes to hit the switches then retract
3: Your machine cords are now zero and you get a message stating referencing completed.
4: Now you're saying the machine physically moves after this....?
-
Yes that is exactly what I see. And it only moves to the offsets defined on the G54 line of the fixture table. If this is all 0s it doesn’t move. However this table gets automatically updated when I jog to my work start position and zero the axes.
-
Ok, sorry for the delay - life has a way of slowing down things!
I enabled debugging and here is the log. I watched the machine very closely and was able to "tag" the line where ref all home should have completed. But the machine then continued to move to the fixture offset position as I've described in the first post. Here's the log file with comments. Further down I've commented a line that asserts a G0 X0 Y0 Z0 F30 move - that might be the issue? Since G54 has been issued in the machine startup then, might this move be performed in the work offset space? That at least would explain the behavior. But, how to stop this from happening?
I haven't tried adding a G53 to the Mach configuration General tab.
2022-05-15 18:19:46.923 - API: mcAxisDerefAll(inst = 0) (unknown caller)
2022-05-15 18:19:46.923 - API: mcAxisDeref(inst = 0, axis = 0) (unknown caller)
2022-05-15 18:19:46.923 - Signal id 1129, (X Homed), changed from HIGH to LOW.
2022-05-15 18:19:46.924 - API: mcAxisDeref(inst = 0, axis = 1) (unknown caller)
2022-05-15 18:19:46.924 - Signal id 1130, (Y Homed), changed from HIGH to LOW.
2022-05-15 18:19:46.924 - API: mcAxisDeref(inst = 0, axis = 2) (unknown caller)
2022-05-15 18:19:46.924 - Signal id 1131, (Z Homed), changed from HIGH to LOW.
2022-05-15 18:19:46.924 - API: mcAxisHomeAll(inst = 0) (unknown caller)
2022-05-15 18:19:46.924 - Attempt transition from "Idle" on event "Home" command.cpp:1248
2022-05-15 18:19:46.925 - S_IDLE_on_exit
2022-05-15 18:19:46.925 - Signal id 1172, (Machine Idle), changed from HIGH to LOW.
2022-05-15 18:19:46.925 - ACION_start_homing
2022-05-15 18:19:46.925 - S_HOMING_on_entry
2022-05-15 18:19:48.687 - Signal id 65, (Motor 0 Home), changed from LOW to HIGH.
2022-05-15 18:19:48.687 - Signal id 1002, (X Home), changed from LOW to HIGH.
2022-05-15 18:19:48.688 - Signal id 66, (Motor 1 Home), changed from LOW to HIGH.
2022-05-15 18:19:48.688 - Signal id 1005, (Y Home), changed from LOW to HIGH.
2022-05-15 18:19:48.689 - Signal id 67, (Motor 2 Home), changed from LOW to HIGH.
2022-05-15 18:19:48.689 - Signal id 1008, (Z Home), changed from LOW to HIGH.
2022-05-15 18:19:49.257 - Signal id 65, (Motor 0 Home), changed from HIGH to LOW.
2022-05-15 18:19:49.257 - Signal id 1002, (X Home), changed from HIGH to LOW.
2022-05-15 18:19:49.257 - Signal id 66, (Motor 1 Home), changed from HIGH to LOW.
2022-05-15 18:19:49.257 - Signal id 1005, (Y Home), changed from HIGH to LOW.
2022-05-15 18:19:49.258 - Signal id 67, (Motor 2 Home), changed from HIGH to LOW.
2022-05-15 18:19:49.258 - Signal id 1008, (Z Home), changed from HIGH to LOW.
2022-05-15 18:19:49.498 - API: mcMotorSetHomePos(inst = 0, motor = 2, count = 0) (PMDX-SmartBOB-USB)
2022-05-15 18:19:49.498 - API: mcAxisHomeCompleteWithStatus(inst = 0, axis = 2, success = TRUE) (PMDX-SmartBOB-USB)
2022-05-15 18:19:49.498 - Signal id 1131, (Z Homed), changed from LOW to HIGH.
2022-05-15 18:19:49.499 - API: mcMotionSync(inst = 0) (PMDX-SmartBOB-USB)
2022-05-15 18:19:49.499 - SyncPosition()! Clearing planner.
2022-05-15 18:19:54.341 - Signal id 65, (Motor 0 Home), changed from LOW to HIGH.
2022-05-15 18:19:54.341 - Signal id 1002, (X Home), changed from LOW to HIGH.
2022-05-15 18:19:54.342 - Signal id 66, (Motor 1 Home), changed from LOW to HIGH.
2022-05-15 18:19:54.342 - Signal id 1005, (Y Home), changed from LOW to HIGH.
2022-05-15 18:19:54.343 - Signal id 67, (Motor 2 Home), changed from LOW to HIGH.
2022-05-15 18:19:54.343 - Signal id 1008, (Z Home), changed from LOW to HIGH.
2022-05-15 18:19:55.663 - Signal id 65, (Motor 0 Home), changed from HIGH to LOW.
2022-05-15 18:19:55.663 - Signal id 1002, (X Home), changed from HIGH to LOW.
2022-05-15 18:19:55.664 - Signal id 66, (Motor 1 Home), changed from HIGH to LOW.
2022-05-15 18:19:55.664 - Signal id 1005, (Y Home), changed from HIGH to LOW.
2022-05-15 18:19:55.664 - Signal id 67, (Motor 2 Home), changed from HIGH to LOW.
2022-05-15 18:19:55.665 - Signal id 1008, (Z Home), changed from HIGH to LOW.
2022-05-15 18:19:55.846 - API: mcMotorSetHomePos(inst = 0, motor = 0, count = 0) (PMDX-SmartBOB-USB)
2022-05-15 18:19:55.846 - API: mcAxisHomeCompleteWithStatus(inst = 0, axis = 0, success = TRUE) (PMDX-SmartBOB-USB)
2022-05-15 18:19:55.846 - Signal id 1129, (X Homed), changed from LOW to HIGH.
2022-05-15 18:19:55.847 - API: mcMotionSync(inst = 0) (PMDX-SmartBOB-USB)
2022-05-15 18:19:55.847 - SyncPosition()! Clearing planner.
2022-05-15 18:20:00.072 - Signal id 65, (Motor 0 Home), changed from LOW to HIGH.
2022-05-15 18:20:00.073 - Signal id 1002, (X Home), changed from LOW to HIGH.
2022-05-15 18:20:00.073 - Signal id 66, (Motor 1 Home), changed from LOW to HIGH.
2022-05-15 18:20:00.073 - Signal id 1005, (Y Home), changed from LOW to HIGH.
2022-05-15 18:20:00.074 - Signal id 67, (Motor 2 Home), changed from LOW to HIGH.
2022-05-15 18:20:00.074 - Signal id 1008, (Z Home), changed from LOW to HIGH.
2022-05-15 18:20:01.390 - Signal id 65, (Motor 0 Home), changed from HIGH to LOW.
2022-05-15 18:20:01.390 - Signal id 1002, (X Home), changed from HIGH to LOW.
2022-05-15 18:20:01.391 - Signal id 66, (Motor 1 Home), changed from HIGH to LOW.
2022-05-15 18:20:01.391 - Signal id 1005, (Y Home), changed from HIGH to LOW.
2022-05-15 18:20:01.392 - Signal id 67, (Motor 2 Home), changed from HIGH to LOW.
2022-05-15 18:20:01.392 - Signal id 1008, (Z Home), changed from HIGH to LOW.
<< This is where homing appeared to be complete and the reference all home dialog popped up.
<< But then the machine moved to the Fixture Offset position that's stored in the G54 line of the Fixture Table
2022-05-15 18:20:01.588 - API: mcMotorSetHomePos(inst = 0, motor = 1, count = 0) (PMDX-SmartBOB-USB)
2022-05-15 18:20:01.588 - API: mcAxisHomeCompleteWithStatus(inst = 0, axis = 1, success = TRUE) (PMDX-SmartBOB-USB)
2022-05-15 18:20:01.588 - Signal id 1130, (Y Homed), changed from LOW to HIGH.
2022-05-15 18:20:01.589 - Attempt transition from "Homing" on event "Stop Home" command.cpp:1387
2022-05-15 18:20:01.589 - S_HOMING_on_exit
2022-05-15 18:20:01.589 - ACTION_stop_homing
2022-05-15 18:20:01.589 - SyncPosition()! Clearing planner.
2022-05-15 18:20:01.589 - S_IDLE_on_entry
2022-05-15 18:20:01.595 - Signal id 1172, (Machine Idle), changed from LOW to HIGH.
2022-05-15 18:20:01.595 - API: mcMotionSync(inst = 0) (PMDX-SmartBOB-USB)
2022-05-15 18:20:01.595 - SyncPosition()! Clearing planner.
<< This line may be the culprit
2022-05-15 18:20:01.606 - API: mcCntlGcodeExecute(inst = 0, commands = 'G0 X0 Y0 Z0 F30') (unknown caller)
2022-05-15 18:20:01.810 - Attempt transition from "Idle" on event "MDI Start" controller.cpp:2364
2022-05-15 18:20:01.810 - S_IDLE_on_exit
2022-05-15 18:20:01.810 - Signal id 1172, (Machine Idle), changed from HIGH to LOW.
2022-05-15 18:20:01.810 - ACTION_start_mdi
2022-05-15 18:20:01.810 - SoftSync()! Clearing planner.
2022-05-15 18:20:01.832 - S_MDI_RUNNING_on_entry
2022-05-15 18:20:01.832 - SoftSync()! Clearing planner. stateinterface.cpp:1351
2022-05-15 18:20:01.832 - S_MDI_RUNNING2_on_entry
2022-05-15 18:20:01.832 - Signal id 1114, (Gcode Running), changed from LOW to HIGH.
2022-05-15 18:20:01.844 - Waiting on planner to drain before waiting on SetStill... runcanon.cpp:92
2022-05-15 18:20:04.759 - Waiting on SetStill...
2022-05-15 18:20:04.759 - Controller::RunCanonBuffer called AddStopReportRequest() runcanon.cpp:101
2022-05-15 18:20:04.759 - Requesting a stopped report for axis 0 motors.
2022-05-15 18:20:04.759 - Requesting a stopped report for motor 0.
2022-05-15 18:20:04.759 - Requesting a stopped report for axis 1 motors.
2022-05-15 18:20:04.759 - Requesting a stopped report for motor 1.
2022-05-15 18:20:04.759 - Requesting a stopped report for axis 2 motors.
2022-05-15 18:20:04.759 - Requesting a stopped report for motor 2.
2022-05-15 18:20:05.006 - API: mcMotionSetStill(inst = 0, motor = 2) (PMDX-SmartBOB-USB)
2022-05-15 18:20:05.006 - SetStill(): Motor 2 last position reported = -6581.0000 controller.cpp:1400
2022-05-15 18:20:05.006 - Axis 0 reports that it is still moving! controller.cpp:1407
2022-05-15 18:20:05.020 - API: mcMotionSetStill(inst = 0, motor = 0) (PMDX-SmartBOB-USB)
2022-05-15 18:20:05.020 - SetStill(): Motor 0 last position reported = 27833.0000 controller.cpp:1400
2022-05-15 18:20:05.020 - Axis 1 reports that it is still moving! controller.cpp:1407
2022-05-15 18:20:05.020 - API: mcMotionSetStill(inst = 0, motor = 1) (PMDX-SmartBOB-USB)
2022-05-15 18:20:05.020 - SetStill(): Motor 1 last position reported = 24192.0000 controller.cpp:1400
2022-05-15 18:20:05.021 - All motors marked as still.
2022-05-15 18:20:05.021 - Waiting on SetStill is Done!
2022-05-15 18:20:05.021 - Attempt transition from "MDI Running" on event "Stop" gcodeexec.cpp:1359
2022-05-15 18:20:05.021 - S_MDI_RUNNING2_on_exit
2022-05-15 18:20:05.021 - Signal id 1114, (Gcode Running), changed from HIGH to LOW.
2022-05-15 18:20:05.021 - S_MDI_RUNNING_on_exit
2022-05-15 18:20:05.022 - ACTION_stop
2022-05-15 18:20:05.079 - S_IDLE_on_entry
2022-05-15 18:20:05.084 - Signal id 1172, (Machine Idle), changed from LOW to HIGH.
-
This is not default Mach4 behaviour as far as I'm aware. Best thing to do is package your profile (go to Help > Support > Package Current Profile..) and then upload it here
-
One thing for sure, it's not G54s fault. Something, your RefAllHome script or something, is telling the machine to move. The telling thing is the F30 in that line you "suspect". Nothing would put F30 just pulled from thin air.
I'd go into the Mach4Hobby directory, find screenscript.lua, open it in Notepad or something, and search for the exact line that's moving the machine.
Just remember you can't edit screenscript.lua, it's compiled every time Mach4 starts from all the places Mach4 has scripts. You'd have to find where it is, screen load script, or whatever.
Like SwiftyJ says, package your profile and post it here and maybe someone can figure it out.
-
Thanks gents. I'm working from home today so I'll do the suggestions above and report back.
-
Have you checked for a setting in the PMDX that might send the machine to a point after homing.
-
Ok, I think I found the culprit. My Ref All Home left buttonup script calls a new function (in the screenstartupscript) called RefAllHomeWithOffset() that looks like this:
---------------------------------------------------------------
-- Ref All Home() function.
---------------------------------------------------------------
function RefAllHome()
mc.mcAxisDerefAll(inst) --Just to turn off all ref leds
mc.mcAxisHomeAll(inst)
coroutine.yield() --yield coroutine so we can do the following after motion stops
----See ref all home button and plc script for coroutine.create and coroutine.resume
wx.wxMessageBox('Referencing is complete')
end
---------------------------------------------------------------
-- Ref All Home with Offset() function.
---------------------------------------------------------------
function RefAllHomeWithOffset()
mc.mcAxisDerefAll(inst) --Just to turn off all ref leds
mc.mcAxisHomeAll(inst)
coroutine.yield() --yield coroutine so we can do the following after motion stops
----See ref all home button and plc script for coroutine.create and coroutine.resume
mc.mcCntlGcodeExecute(inst, "G0 X0 Y0 Z0 F30")
wx.wxMessageBox('Referencing and offset completed')
end
So there is the suspect move line. Apparently I had added this back in 2018 when there was discussion here about how to back off the home switches by a specified amount. At the time I was backing off .5" but later I realized the I got more build area by just letting it clear the switch, so I changed these to "0"s. However, the behavior seems to be different than it was when I implemented this. I don't ever recall the machine moving to the set x,y,z position in the table fixture table. Maybe that is a change with later Mach releases (last few years) as I have not used the machine much in 18 months or so.
I have not tested this yet but I'm hopeful it might be the culprit.
-
Thats it.
you can remove it from the left up or comment out the code
-
Yeah, I removed it from left up but have not tested yet. I can do that later tonight.
-
Yeah, I removed it from left up but have not tested yet. I can do that later tonight.
You might have to change the left up script to call the original RefAllHome, but I s'pose that's obvious.
-
Yup, that's exactly what I did. I had commented out the original call when I added the new call so I just had to swap the comment characters.