Mach 3 behaving badly?

[Davek0974]

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

[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]

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.

[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

[Davek0974]

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 ;)