Mach3 Screensets

[Ger21]

Fwiw, I've had a couple 2010 users with CS Labs controllers that couldn't get the macros to work. I've even redid the macros to use CS Labs M31 probe, and it still didn't seem to help them. Not sure what the issue was??

Is it feasible to load a couple of screen sets without inter-corruption, I have a suspicion that my Big Tex installation has been corrupted by a previous screen set e.g. M6 overrides the tool change position and reverts to a location I had set for a previous screen set?

It's not the screenset that causes the issue, but rather the macros included with them. You can change between screens with no issues, but changing screens does not change the macros. If you want to switch between screens like my 2010 or the Big Tex, then I'd create separate profiles, to keep the macros separate.

MachStdMill, on the other hand, is an entirely different animal. It does a lot of things that "standard" screensets don't, and it can cause a lot of issues if not uninstalled properly.

[Neale]

I've modified the usual touchplate macro to use the special commands which CS Labs provide for this purpose in place of the usual g31. I've also written macros (or modified someone else's - can't remember now) to do tool height sensing for second-operation tool changes, which means that they have to work reliably during an M6 tool change. I had a lot of problems until I went back to an earlier version of Mach3. I have also tweaked the first of these macros for touch-off in x and y, both directions. I used these when initially setting up the machine although I don't use them day-to-day but I'm guessing that these are the kind of problem areas that Gerry is talking about.

However, given that there are some internal problems between the CS Labs side and Mach3, it does look as if you need to check that the functions you want do work. I've steered clear of add-in screensets partly for this reason. At least I have full visibility of what my own code does and I carry the can for anything that doesn't!

[kirby43a]

Hi Neale, until I opened this thread I was unaware of the problems with CS Labs controllers and Mach3 and I had imagined a new screen-set/macros would resolve touch-off issue, two screen-sets later and a dogs breakfast of a setup, I have an explanation but no obvious solution and I am coming to the conclusion that I might be out of my depth.
Harry

[Ger21]

These problems are not limited to CS Labs products, as many Mach3 motion controllers have probing issues. The makers of MachStdMill only support it with the parallel port, and Smoothsteppers.

http://www.calypsoventures.com/forum...c.php?f=4&t=62

This is a big reason that I'm moving to UCCNC. With Mach3 (and Mach4), you are relying on two different companies writing complex software that need to interact with each other flawlessly. Changes in Mach have frequently required new or updated plugins.

With UCCNC, software and firmware are developed by one team, simultaneously, so all features always work as they should, as soon as they are released. And bug fixes typically happen in a few days, if there are issues.

[kirby43a]

Hi Gerry,
thanks for your help, I guess I bought the wrong retrofit kit and now I am going to have to live with it's shortcomings or dig into my pension and start allover.

An interesting recent observation of my CS Labs CSMIO/Mach3/Big Tex Bluescreen configuration: Regarding the tool measurement utility; Both the "initial Setup" and the "Zero Tool Setup" consistently function correctly however when a tool change is either embedded in a "G" code or is triggered manually in the middle of a toolpath the tool will move to the correct location to change the tool and proceed to the touch plate, when the tool touches the touch plate the first time it trips-out and a ePID error box comes up; with the system "RESET" and the tool is jogged up and the "Zero Tool Setup" is hit the operation functions correctly and proceeds to the next line of code. If an embedded tool change is initiated and the "STOP" button is used and then the "Zero Tool Setup" is hit the tool is measured correctly and it proceeds to the next line.

I had wondered whether my observation resonated with anyone else.

Harry

[m_c]

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

I know when I was still running Mach3 on the lathe, I couldn't use the threading wizard directly, as I unknowingly used the same UserDRO for transferring the current turret position from the KFlop to Mach, that the wizard used for the thread pitch (it was ok if the pitch I wanted happened to match the current turret position though!). It took me a while to figure that out, but by that time I was in the habit of generating any required code on the laptop anyway, so never bothered changing what userDRO was being used.

The hardest part I always found about writing Mach macros, was finding out what all the DROs were meant to contain, and I'm sure certain plugins used DROs with no documentation to tell you what DROs were used, let along what they were used for. All it would take was for you to use a DRO that was already being used, and you had the potential for things to wrong.

Thankfully I've never had any problem with probing using Mach3 and a KFlop.

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

[kirby43a]

Fwiw, I've had a couple 2010 users with CS Labs controllers that couldn't get the macros to work. I've even redid the macros to use CS Labs M31 probe, and it still didn't seem to help them. Not sure what the issue was??

Hi Gerry, your quote below, was that with respect to other screen sets or MSM? Are there any known issues with CS Labs controllers and MSM, if not, that would appear to be an answer to a maidens prayer.

It's not the screenset that causes the issue, but rather the macros included with them. You can change between screens with no issues, but changing screens does not change the macros. If you want to switch between screens like my 2010 or the Big Tex, then I'd create separate profiles, to keep the macros separate.

MachStdMill, on the other hand, is an entirely different animal. It does a lot of things that "standard" screensets don't, and it can cause a lot of issues if not uninstalled properly.