Mach 3 behaving badly?

Setup - Manual Bridgeport mill converted to CNC with Mach3, CSMIP-IP/A controller, Servo's on all axes, ballscrews etc.

Todays mess - 30 minute job takes over 3 hours.

Simple job - two setups, total of 5 tool changes, 8mm thick motor mount/adaptor plate for my new drive motor, basically a 250mm circle with 110mm hole in the middle, plus some bolt holes, tabs etc. A nice fun part to play with?

First tool/pass goes well, then the Z gets the command to go home for tool change - this triggers a (soft) limit switch, right on the tool change. Reset pressed, tool changed, Z ref is now wrong, reset, pass runs ok, tool-change time - (soft) limit triggers again, same routine.

Offsets look odd but maybe correct, i haven't figured out the numbers yet - pictures below.

The screen tells me max-z is something like 220mm? A bit tricky as i only have something like 130mm to play with? Surely my Z-Max has to be Zero?

Then i start a run and as soon as it hits the first X/Y G1 line it throws an ePid fault, and again, reset, swear, go indoors and re-cam the part for a single tool in the file and it runs OK ?

Its just winding me up something terrible as I am not 'fiddling' with stuff or editing macros etc, I just went out, booted up and tried to do some work. I have no idea what to fix or what to post up here so other can chime in but boy is it pissing me off.

It also suffers the bug where you get the "Script compile error in M3.m1s" - this seems pretty common on the 'net but again a real PITA.

I'm new to CNC relatively and having to double-check everything so i don't crash the machine is one thing but when it does not do what its told it makes things really uncomfortable ;)

Attachment 19383

Attachment 19382

Attachment 19381

If you know you are not going to run off the table then switch the soft limits off. They are a pain in the arse as they have to be reset for every job if X0.0 and Y 0.0 changes
If you have limit switches fitted then you don't need soft limits.

They were only put into Mach to satisfy the people who couldn't or didn't want to fit limit switches but wanted piece of mind.

Yeah but no but....

I use them a lot, my stuff is all over the table and I'm often jogging around to get positions etc and run into them a lot. Hitting the limits on my build kills all power to the drives so would not want to do it too often plus it means re-homing etc.

This is a commanded soft limit thats being triggered - seems to be a CS_Labs thing i think - if the code tells it to go somewhere it can't it simply throws an instant "limit switch triggered" error and puts Mach into reset.

Trouble is - WHY is it doing it - it seems it was always the Z axis this time, Z Max, which on my machine should never be more than zero as home is at zero.

I really would not want to run without soft limits IMHO.

Dave You do realise that soft and hard limits are two different things when jogging around are you hitting the soft or hard limits?

Soft, if i hit the hard limits all the power goes off on the drives etc - you can certainly tell when that happens :)

What version of Mach3 are you running?
3.042.020 or close to it is what seem to be the least buggy,

- Nick

That was the last version that Art Fenerty supported, after that it went downhill fast...................

This was the last one i installed...


Mach3Version3.043.062

I think it is a must to install latest version, especially if you use third party plugins, which typically are made for latest version. Except if plugin maker expressly says what version of mach3 is made for. You should not use tool length offsets at all, especially with the plugins that do probing.

Welcome to Mach3

This is where we have problems -

Most forum admins and long term supporters of Mach3 admit that many things are broken in new version of Mach3 and will never be fixed. I was strongly advised to use that version by a respected admin.

CS-LAbs do not seem to have any preference at all, at least none is mentioned.

Yes probing with a TLO in play is seriously bad news - i discovered that one by myself when i wrecked my Z-axis. I have blocked all probing from running unless tool zero is selected.

Its more welcome to the bad side of Mach3 - I have used it for a couple of years now on my plasma cutter but that has parallel port connection - Mach was built for this.

I have it on my Mini-Mill and it works ok - that is USB connection but does suffer occasionally from the "Script compile error in M3.m1s" bug which is widely known on the 'net.

This is the first install with ethernet control and servo motors and seems to be being a bit naughty.

Quote:

---

Originally Posted by Boyan Silyavski

I think it is a must to install latest version, especially if you use third party plugins

---

It is a must to install a version supported by any third party hardware you use, if that isn't a requirement then the version quoted above is what most of the very experienced Mach3 Forum Admins recommend.

The latest version of Mach3 is not best, it's buggy, and knowing this then unless you need it to support something you are using or doing why on earth would you use the latest version of Mach3?

There are some things that other versions do best, the Mach3 forum is the place to find out the best version for any specific requirements you have, sometimes it's a slightly older version than 020! Again, assuming that latest is greatest is a recipe for problems.

Errors generated only when third party hardware is used cannot be laid at the door of Mach3, it is the sole responsibility of the third party to ensure their plugin runs seamlessly with Mach3 and it is entirely the fault of the third party if they do not,

- Nick

Quote:

---

Originally Posted by magicniner

Errors generated only when third party hardware is used cannot be laid at the door of Mach3, it is the sole responsibility of the third party to ensure their plugin runs seamlessly with Mach3 and it is entirely the fault of the third party if they do not,

- Nick

---

This is a problem - first you have to discover what is causing the issue - is it the Software (mach3), the plugin (cs-labs), the hardware (me), the g-code (Vectric, Fusion, Sheet-Cam), the operator, so many issues can be triggered by any combination of one or more of these sources.

The plasma controller i use only works with ONE version of Mach3, nothing else and no it's not the latest ;)

Apparently the CSMIO controller creates a log file - "CSMIO_IP_A.log" on the PC, it should contain data on what switches have triggered etc.

Will have a look tonight.

Here we go, the log file is a mine of information :)

It seems the machine started up fine, ran fine until 2016-10-02 | 09:52:21.375 where we get the first "Software limit switch activated!" error - this would be when it sent the Z axis home for a tool-change.

So, as i said, its not a real limit switch thats getting hit, its some sort of software limit.

Its also the Z axis throwing the following ePid fault - 2016-10-02 | 09:56:24.625 -> ePID Fault on Axis(2) : FAULT
This is always after the software limit switch trigger

Question is - why?

2016-10-02 | 09:17:24.718 -> CSMIO-IP class initialized OK.
2016-10-02 | 09:17:24.734 -> InitUDPSock -> OK.
2016-10-02 | 09:17:24.734 -> piInitControl: Module filename: C:\Mach3\PlugIns\CSMIO_IP_A_plugin.dll
2016-10-02 | 09:17:24.734 -> piInitControl: GetFileVersionInfoSize = 1716
2016-10-02 | 09:17:24.734 -> piInitControl: ProductName: CSMIO-IP-A Mach3 plugin
2016-10-02 | 09:17:24.734 -> piInitControl: ProductVersion: 2.8.5.1
2016-10-02 | 09:17:25.687 -> Our IP address : 10.1.1.1
2016-10-02 | 09:17:25.687 -> Our subnet mask : 255.255.255.0
2016-10-02 | 09:17:25.687 -> Calculated broadcast : 10.1.1.255
2016-10-02 | 09:17:25.687 -> Sending discover message to broadcast.
2016-10-02 | 09:17:26.359 -> All network interfaces checked...
2016-10-02 | 09:17:26.359 -> Discover finished. Found 1 CSMIO-IP device(s).
2016-10-02 | 09:17:26.359 -> Connecting to CSMIO-IP at IP:10.1.1.2
2016-10-02 | 09:17:26.359 -> Connected.
2016-10-02 | 09:17:27.109 -> llComm(c:45): Rx time-out. retry = 0
2016-10-02 | 09:17:27.109 -> llComm(c:45): NAck with nackTRREP received. (no retry).
2016-10-02 | 09:18:05.171 -> Sending reset to idle state request.
2016-10-02 | 09:18:07.218 -> Homing start axis:2
2016-10-02 | 09:18:12.296 -> ClrAxisPos: Axis:2 / DeRef: NO.
2016-10-02 | 09:18:12.296 -> Axis 2 homing ok.
2016-10-02 | 09:18:12.359 -> Homing start axis:1
2016-10-02 | 09:18:15.546 -> ClrAxisPos: Axis:1 / DeRef: NO.
2016-10-02 | 09:18:15.546 -> Axis 1 homing ok.
2016-10-02 | 09:18:15.640 -> Homing start axis:0
2016-10-02 | 09:18:22.515 -> ClrAxisPos: Axis:0 / DeRef: NO.
2016-10-02 | 09:18:22.515 -> Axis 0 homing ok.
2016-10-02 | 09:52:21.375 -> Software limit switch activated!
2016-10-02 | 09:52:58.843 -> Sending reset to idle state request.
2016-10-02 | 09:55:34.437 -> Software limit switch activated!
2016-10-02 | 09:55:42.453 -> Sending reset to idle state request.
2016-10-02 | 09:56:24.625 -> ***********************************
2016-10-02 | 09:56:24.625 -> ePID FAULT! (State = 105)(Alarms=0x00000002)
2016-10-02 | 09:56:24.625 -> (ThreadSt=5) (RTappSt=0)
2016-10-02 | 09:56:24.625 -> ePID MaxError on Axis(0) : 156
2016-10-02 | 09:56:24.625 -> ePID MaxError on Axis(1) : 1
2016-10-02 | 09:56:24.625 -> ePID MaxError on Axis(2) : 681
2016-10-02 | 09:56:24.625 -> ePID MaxError on Axis(3) : 0
2016-10-02 | 09:56:24.625 -> ePID MaxError on Axis(4) : 0
2016-10-02 | 09:56:24.625 -> ePID MaxError on Axis(5) : 0
2016-10-02 | 09:56:24.625 -> ePID Fault on Axis(0) : ok
2016-10-02 | 09:56:24.625 -> ePID Fault on Axis(1) : ok
2016-10-02 | 09:56:24.625 -> ePID Fault on Axis(2) : FAULT
2016-10-02 | 09:56:24.625 -> ePID Fault on Axis(3) : ok
2016-10-02 | 09:56:24.625 -> ePID Fault on Axis(4) : ok
2016-10-02 | 09:56:24.625 -> ePID Fault on Axis(5) : ok
2016-10-02 | 09:56:24.625 -> ***********************************
2016-10-02 | 09:56:34.296 -> Sending reset to idle state request.
2016-10-02 | 09:58:19.750 -> Sending STOP request.
2016-10-02 | 09:58:19.812 -> ***********************************

Just got a reply from cs-labs, it seems its probably an internal issue between mach and the plugin, i need to downgrade to v022 as that is the recommended one.

Something is telling mach to move beyond a soft-limit - clearly this should never happen but is.

The ePid fault is caused by mach telling the motors to move faster than it should - the motor cannot keep up and a the following error hits the ePid limit and trips.

Will try v022

3.043.022 does not work with the 2010 tool change macros. There's a bug in Mach3 versions 3.043.000 up to .022 that will cause mach3 to lock up when it gets to an M6.

Not all M6's, and when I found the bug, there was no rhyme or reason on what actually caused the issue. The default macros worked fine, but I could get it to lock up with a single line of code in the M6 macro.
It was fixed in 3.043.028 I believe.

Thanks Gerry, it seems Mach3 is a minefield of issues from version to version.

I do use the M6 so I will not downgrade to the very early version.

Not really sure what to do now TBH.

I will be back up and running this weekend, I will re-run the same code that failed and see what happens, only the motor has been changed so nothing that will alter the code execution. This might work or fail, if it fails I will try V028 instead.

I did ask CS-Labs about Mach4 but they advised holding fast until their new re-written plugin is published in the not too distant future.

Quote:

---

Originally Posted by Ger21

3.043.022 does not work with the 2010 tool change macros. There's a bug in Mach3 versions 3.043.000 up to .022 that will cause mach3 to lock up when it gets to an M6.

Not all M6's, and when I found the bug, there was no rhyme or reason on what actually caused the issue. The default macros worked fine, but I could get it to lock up with a single line of code in the M6 macro.
It was fixed in 3.043.028 I believe.

---

I've just set up all the auto tool change stuff in your screenset and it wasn't working, just sat there waiting for me to press start again without doing the move to tool change position and then the probing....just been looking into why and just come across this so will see what version of Mach I'm using.

Don't hold your breath with Mach4. It's been out four plus years and still not a release candidate. Without an external controller like CS Labs, Pokeys, Hicon etc it can't stand on its own and so far all the effort is going Pokeys way and even this way behind. Unless you have a system where software and hardware is under the same roof you will have support problems.
Mach3 could do it with the parallel port as it was all in Art's domain but then the rot set I'm with the G-Rex and original smooth stepper. The current smooth stepper is weeks away from threading but it's the same weeks away that they quoted 4 years ago.

Quote:

---

Originally Posted by John S

Don't hold your breath with Mach4.

---

Yeah, it was just a passing thought really. I'm still using Mach3 on two other machines so adding a new flavour to the mix would not aid my learning curve i think.

;)

That's why I'm moving to UCCNC....
I bought a Mach4 license two years ago, but haven't even looked at it in over a year. Probably another 4-5 years until it's completely finished. Maybe...

Yeah, linuxcnc not an option here I'm afraid - too much £££ in the CSMIO controller and they don't support Linux

After hitting the problem today with both G28 and G53 moves, I switched to single block and stepped it, it triggered at the M6 command.

Next i pulled the M6macros out and it worked ok (to that point), a coffee and a sit-down with the macro open showed the problem. It was connected with the screen-set and the M6Start macro, a variable and DRO called "Clearance Plane" - this is used in the 2010 screen-set tool-change routines.

But as I cannot use them on the Bridgeport and do not need them due to the fixed length tooling, the already edited M6Start macro was still using the values and trying to send the Z to a position beyond home when triggered - the system said no and triggered the soft limit.

This is why the code always ran fine as a single-tool job - the first line in the M6Start skips the routine if the current tool = selected tool so the dodgy code was never hit :)

I have now edited the M6Start to remove all references to clearance planes, offsets etc and just issue a straight G53 G0 Z0 style home move.

The code i was struggling with has now been air-cut 6 times with 100% success.

Thanks for all the tips.

Quote:

---

I've just set up all the auto tool change stuff in your screenset and it wasn't working, just sat there waiting for me to press start again without doing the move to tool change position and then the probing....just been looking into why and just come across this so will see what version of Mach I'm using.

Neil...

---

Neil, email me if your having issues with the screenset and I should be able to find out what's causing your issues.

Looks like I've stumbled into the same issue. I'm running (I think) .066 with a CSMIO-IP/M. I've been writing some tool height/tool change macros plus doing a bit of screen editing. I wanted an excuse to have a fiddle with the code and this looked like a nice little project. I freely acknowledge that a lot of it is based on various sources found on the web for tool-height setting. Basic Z height setting works fine - double-touch and everything, and based on the CS-Labs M31 macro. Under ideal conditions, repeatable to within a microstep or two even with some random rapids thrown in between measurements. On to "initial tool setting" - sets Z height in usual way, then touches off fixed touchpad to establish a reference. After a few problems involving work/machine coordinate settings, this seems pretty solid. Then the tool-change height setting, which just uses the fixed touchplate slotted in between m6start and m6end. I'm now seeing the soft limits issue, plus ePid errors.

Sounds like first thing to try is drop back to .028 - but I can't find anywhere to download it? Is there a standard place to go for this?

Thanks,

Edit - found it eventually. Hadn't thought of looking in Mach3 ftp download area before!

You found the link before I could send it this morning. Shamefully I've still not rolled mine back, been using the simple zero and just doing one op at a time. Let me know how you get on and if it solves your issues. When the machine has a slack period I'll back up the files and roll it back...

Sent from my HUAWEI VNS-L31 using Tapatalk

Thanks, Neil - as ever, asking the question helped me find the answer!

Quick answer is that upgrading to the older version has fixed the problem, as far as I can tell. I've done a few tests, including air cuts of a previous job, and all goes well. Anyway, well enough for me to find a bug or two in my code. If you save the fixed touchplate height in one macro, then it makes sense to use the same variable in the next macro. Fortunately, e-stop saved my bacon and another hole in the bed. I've tweaked the 1024 screen to replace a couple of things in the tool offset area with new buttons that execute my new macros; the first picks up the movable touchplate of the surface of the work in the usual way then goes off to find the relative height of the fixed touchplate and the second is used for subsequent tool changes by setting off the fixed touchplate. Nowt very original but it's quite satisfying to have done it, and I've learnt a fair bit about macros in Mach3 and the need for a short pause after certain operations, for example. All the code uses the native IP/M probing functions rather than G31. I've tested this with tool changes while running real gcode so it seems to work correctly with the M6 macros. Happy to share code if you're interested, on a strict YMMV basis!

That's good to know, cheers Neale. I'm using Gerry's 2010 screenset so the macros you've done are already in it. Always fancied having a dabble at macros but I'm not a natural coder and am always time poor....

Sent from my HUAWEI VNS-L31 using Tapatalk