Mach 3 behaving badly?

[magicniner]

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

- Nick

[John S]

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

[Davek0974]

This was the last one i installed...


Mach3Version3.043.062

[Boyan Silyavski]

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

[Davek0974]

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.

[Davek0974]

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.

[Davek0974]

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 -> ***********************************

[Davek0974]

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.

[Ger21]

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.

[magicniner]

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