Mach3 Screensets

[Ger21]

I suspect the problem with Mach and external motion controllers is to do with how oem/userDROs are allocated and updated.

Not from my experience. It usually has to do with how the plugins work with macros. For instance, most chinese controllers do not support Mach3's GetVAR()function, which is usually used to find the trip point.

Most plugins don't really on any specific DRO's.

DRO conflicts between wizards and screens is a different issue, imo.

[m_c]

You probably are right, regardless I think it's safe to say beneath the surface, it was probably not top of the issue list with Mach 3.

[Neale]

I came across a thread somewhere that had a lot of finger-pointing on the CSMIO/Mach3 compatibility issue. The gist of it seemed to be that because the Mach3 APIs were not particularly well documented, CS Labs worked it out as they went along and ended up using Mach3 functionality that they were not supposed to/should not have used. But it worked. Until Artsoft changed that bit of the code, which is why "updating" to an earlier Mach3 version fixes those particular issues. At the moment, at least, I don't seem to suffer from any of the problems that were presumably fixed in the later Mach3 releases.

I agree that you have to be careful about user DROs, as some screensets use these to transfer values to associated macros. My own very trivial mod to the standard 1024 screenset does exactly that, and I spent quite a long while checking to make sure that it didn't interfere with anything else.

I'm happy with what I have at the moment and it all works fine (apart from lack of support for proper two-motor homing) but I'm not sure that I would go the same way again. I keep looking at the UC300ETH, even though with a decent BOB it would work out to be a similar price to the IP/M. At least it has active support in place!