Will updating my install of Avid CNC Mach4 version to the newest from their website break any of my customizations?
I’m still using version 2.2.0 from Dec 2020. I’m only think of upgrading because the revision history shows you can have it warm you to home prior to runing G-code. Im sure there are other benefits to upgrading after 2 years.
Kenny
I would copy the the AvidCNC profile and rename it something for yourself and live in there. AvidCNC owns that profile and they are free to makes changes to that at any time. Until I learned to stay in my own profile they would hose my setup every update.
Updated Mach4 using the AVID version. I was already using a copied version of the AVID profile that was renamed originally. I also backed up the Mach4Hobby directory just in case something went terribly wrong.
Well, didn’t go as smoothly as I hoped. Right away, I got an error message about XY Velocity PWM and Laser Gate error. I don’t use a laser on my AVID. Looks like the update made some changes to my ESS settings. Also found my spindle wouldn’t turn on.
I was able to at least fix the two problems above by loading the AVID profile and checking out the ESS setting. After about an hour of snooping around and making changes to the ESS in my profile, I get both the error message to disappear and my spindle working again.
I will be watching my AVID like a hawk the next time I run it since I’m not sure what other problems might pop up.
BTW, I have a CNCDepot S30C setup with ATC rack so upgrading mach4 probably wasn’t the greatest idea since everything did work fine. I probably should have just tried to figure out how to add the warning myself to home the machine before running the CNC. Almost had a bad crash when I forgot to home the CNC recently before doing a tool change. That is what took me down this path!
Kenny
Yep, they will routinely hose your entire ATC setup. I back up the entire system before upgrading.
Then I spend the next month trying to figure out what they decided to meddle in next. They are trying to add features for their base users, I get that. But they are slowly wandering into the space we have already customized and that get frustrating.
So, in the end, i had to go back to the original mach4 and ESS i started with.
I had a problem using my tool length setter and G31.1 to work after the update. After much research and a broken end mill, glad my tool length setter is built tough, i contacted NFS for help. They said there is nothing wrong with my CNC or Mach4. Apparently, ESS isn’t playing nice with G31.1 probing command.
So I’m back where I started…everything working again.
I was hoping try Corbin Dunn’s ATC setup but I still want my tool length setter to work.
Kenny
How were you using the G31.1? Where you using the AvidCNC screen and the button on the screen? That button does a G43 H1 before the probe and then resets the old G43 before doing a rapid above the touch-off point. If your probe is longer than your T1 then it will drive the probe down instead of lifting it.
I have my permanently mounted tool setter with it hooked up probe #2 input. It is a different input than the AVID work offset tool input. It worked perfectly fine. I created a G code macro to measure tool length that uses the G31.1 with a fast touch and back off, and then a very slow touch to get accurate tool length.
It worked perfectly prior to updating. When I contacted Mach4 support, they immediately told me the issue wasn’t with my setup or Mach4 but the ESS.
Now thinking about it, after updating, I never tried using the AVID touch user interface. I never got far enough to actually run a job after updating. I wonder if the issue that I hear Corbin Dunn talk about with the AVID macro is actually an issue with how the ESS handles G31 commands.
Before the update, I never had any of my tools rapid after touching the plate after using the AVID touch macro. I did have to activate the tool length offset with G43 H# and I also set my Z zero to the distance of the retract amount setup by AVID.
I posted about a few years ago on Facebook.
Kenny
I have a tool setter and a probe and I have no problems using them with the ESS or AvidCNC’s install.
The only issues I have are the AvidCNC scripts and the difference of opinion between Warp9 and Newfangled on how to handle a no-strike G31.
Perhaps you are referencing that last part? Newfangled and Warp9 don’t like each other and that is a sore spot for them. Does the G31 fail with a no-strike error?
I’m communicating with Warp9 about the issue and waiting for a second reply from them about the issue.
Everything worked fine with ESS v260 but when I updated both Mach4 and ESS v.283. That is when the problem started.
I think it has to do with the way my TLO G Code script works. It does a double touch to get accurate tool length measurements. It does a faster feed for the initial hit and then backs off .125" and does a slower feed for the second hit. I will have to check it again but I think it has to do with the ESS not responding to the second tap fast enough or at all.
I assume that the only reason the damage isn’t worst(only a broken 1/16 endmill) is because the Z parameter in the G31.1 was set to .250".
Hopefully, I will get some time and I can test again. I have a backup before the update so I’m OK right now. I did make a mistake by not realizing when I started using the backup the Mach4 it showed the wrong tool in the spindle and crashed into the tool rack when doing a tool change :(. At least now, I know to check the current tool number when switching between mach4 installations.
Oh gosh! Over 60% of my tool change code is error checking. It will probably get higher in the coming weeks as I get ready for release.
On my system I use the tool setter for breakage and I have a sensor on the carousel to tell if there is a tool in the pocket before I dock it.
The breakage means you never use the wrong tool because it if isnt the exact size as stated in the tool table you error out. So that happens on tool load and before tool unload.
It will save you not only when you have the wrong tool in the wrong pocket but also when you lose steps for whatever reason. Actual broken tools are also caught of course.
I just don’t have the errors you are talking about. It sounds like a flaky cable or something.
Emailed Warp9 and they think they found the problem. Apparently, there is a delay after the touch that is causing the problems with my G-Code TLO subroutine. Below is the response I received from Greg at Warp9. They are going to do some testing but it sounds like they might have a fix soon so I’m not going to mess with it anymore.
I have some good news, which is that we have identified the reason for the long delay. Turns out a couple of different threads were both trying to read and write some variables to make them available for the user, and it was causing some deadlock that made for a really long delay. 0.8 seconds! Now it completes in a millisecond and retracts soon after that (there will be delay in comms with Mach to sync to the current position and to receive a trajectory of points to retract).
Kenny
I’m planning on adding support for this at some time. What input pin(s) do you have it setup to? What particular setter are you using? If you have some time, also email me your custom macros and I can base something off of them. (corbin at corbinstreehouse dot com)
I’m hoping to officially “release” my ATC screen set in a few days; I’m currently working on a video that describes how to use it.
Corbin
Wrap all your mc calls around a method that checks for an error and throws an exception. Then catch the exception at whatever point you want.
I do this in:
See MCCntlGcodeExecuteWait.
So, the error checking is just a few lines. Use a pcall to catch the exception:
function ToolChange.DoToolChangeFromTo(currentTool, selectedTool)
local result, errorMessage = pcall(ToolChange._TryDoToolChangeFromTo, currentTool, selectedTool)
if not result then
– try to cycle stop!
mc.mcCntlCycleStop(ToolChange.internal.inst)
ToolForks.Error(errorMessage)
end
end
For the TLO, I use a G-Code subroutine. Worked wonderfully until I updated Mach and the ESS. I’m not the original writer…I found it on the NFS Mach4 support forum.
As for the tool length setter, I don’t remember who made it. Ordered it from Europe before COVID. It isn’t labeled on the outside. I used the AUX2 jack on the bottom of the AVID control box. The ESS says Port2 Pin 8 (P2-8).
%
O9001
(------------------------------------------------)
(--Machine Variables--)
(#1231 = Current Tool)
(#5063 = G31 User Position Z)
(#5073 = G31 Machine Coordinate Position Z)
(#[11000 + #1231] = Tool Length Offset to be set.)
(------------------------------------------------)
(--User Variables--)
#5063 = 0
#5073 = 0
#501 = 0.9717 (Tool Setter X Position, Machine Position)
#502 = 47.0263 (Tool Setter Y Position, Machine Position)
#503 = 8.00 (Fast Probe Z Machine Position)
#507 = 0.1250 (Re-Probe Lift Height)
#504 = 75.000 (Fast Probe Feedrate)
#506 = 2.00 (Slow Probe Feedrate)
(Safe Code)
G90 G20 G80 G49 G40
(Turn off Spindle and Coolant)
M5
M9
(Orient the Spindle)
;M19
(Raise Dust Hood)
#1107 = 1
(Move to Safe Z)
G91 G00 G28 Z 0.00
(Move to X & Y Tool Setter Position)
G90 G53 G00 X #501 Y #502
(Fast probe tool, on probe strike, raise Z 0.375")
M49 (Disable Feedrate Override)
/G90 G53 G31.1 Z -[#503] F#504
/G91 G00 Z #507
(Probe for tool length offset)
/G91 G31.1 Z -[#507 + .125] F#506
/G04 P250
/G91 G00 Z #507
(Move to safe Z)
G91 G00 G28 Z 0.00
G90
(Set the current tool's offset in the tool table.)
/#[11000 + #1231] = #5073
(Enable Feedrate Override)
M48
(Activate TLO for current tool)
G43 H #1231
(Lower Dust Hood)
#1107 = 0
(Disable Spindle Orient)
;M20
M99
%```Awesome, thanks Kenny, I think that gives me enough to go on! It’s on my list of stuff to add at some point.
Corbin
You mean function. I am “Captain Pedantic” 
You are making an awfully huge assumption that the native binaries you are calling are well written.
Not sure what you mean…but you said 60% of your code is error checking; you can still check the error from each mc* method call, but it really should only be about 1% of your code, if it is written right.
Mach 4 sure has a lot of idiosyncrasies, but most all of it seems to be working for me, once I figured out what I could do and when I could do it. Part of it is making sure you don’t let exceptions escape from certain areas; this isn’t odd…a lot of UI frameworks have issues with exception handling.
That is a massive, huge, green, bug-eye’d monster statement, sir
I’m not really here to discuss computer science :). I did that for many years at Borland doing compiler and IDE work on Windows and Linux, and then Apple, working extensively on UI frameworks, giving talks on the subjects at BorCon and WWDC.
01 function ToolChange.DoToolChangeFromTo(currentTool, selectedTool)
02 local result, errorMessage = pcall(ToolChange._TryDoToolChangeFromTo,
-- currentTool, selectedTool)
03 if not result then
-- –- try to cycle stop!
04 mc.mcCntlCycleStop(ToolChange.internal.inst)
05 ToolForks.Error(errorMessage)
06 end
07 end
Of the 7 lines of code you presented, 4 are in fact handling errors. That is NOT 1%.