Mach3 Screensets

[kirby43a]

I have a Gate turret mill with Anilam Servos and amps with a retrofit CSMIO /IPA CNC controller (Anilam brain dead hence retrofit) and am using Mach3 currently with a Big Tex screen set as I need to be able to change tools on the fly. All is not entirely well with Tex is there a better alternative to Big Tex.

[Neale]

Two popular choices are the "2010 screen set" from Gerry/ger21, and the machstdmill screen set from Calypso Ventures. I know people who use both very happily, although I personally use the standard Mach3 offering with some slight tweaks of my own. A google search will find both of the ones I've named. Can't help with whether or not they help with tool-changing - I've found the standard features of Mach3 sufficient but I'm not using a professional machine.

[Chaz]

2010 from Ger. I'm using this now and I should have changed to it years ago.

[needleworks]

I'm using Hoss's screenset, perfect for what I do, and lots of youtube videos on how to set it up/tweak it.

[komatias]

Personally, Ger21's Mach2010 is the better of the commercial ones.

The hoops you have to jump through with MachSTD to get it installed and the fact that it is not 100% compatible with the CSMIO killed that one for me years ago....and I dont even use CSMIO products hehe

[Mad Professor]

I also use Ger21's Mach2010 screen-set, I personally find it to be the best one to use.

[kirby43a]

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?

[Chaz]

I also use Ger21's Mach2010 screen-set, I personally find it to be the best one to use.

Mmmm. I know this nick. Ex 3D printing world?

[Neale]

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?

I don't think that changing a screenset will change other aspects of that profile. The macros are stored per-profile, i.e. typically per machine, so if you updated a macro in one profile, that change won't be seen in other profiles.

However, there are a few odd things that can happen around M6 that aren't quite right if you are using a CSMIO-IP/M, and I wouldn't be surprised if it's not true for other CSMIO variants. For example, when I first started playing with tool height setting/resetting during an M6 tool change (i.e. between the calls to M6start and M6end), there were problems about losing X and Y position. The fix (in my case) was to "upgrade" to an earlier version of mach3. I'm currently using 3.043.028 which is not the latest version but can still be downloaded and installed. Remember to save any profile modifications in a custom machine profile and not mach3mill or any of the other out-of-the-box profiles or they will definitely be overwritten. The CSMIO compatibility thing is well-known and documented but you won't generally find it unless you go looking for it.

[kirby43a]

Enormous thanks!

An explanation at last, maybe not the one I had hoped for but a clear understanding.
What bothers me most, now, is losing all of my CSMIO-IP/M settings that have taken months to resolve. Which begs the question is it possible to run two versions of Mach on a single machine using an alternative profile name?

[needleworks]

Enormous thanks!

An explanation at last, maybe not the one I had hoped for but a clear understanding.
What bothers me most, now, is losing all of my CSMIO-IP/M settings that have taken months to resolve. Which begs the question is it possible to run two versions of Mach on a single machine using an alternative profile name?

When you first open Mach3, can you not just "create" a copy of your working profile, rename it to something else and make any changes you want to your new renamed profile, if it goes tits up, just delete it and start again ? I'm sure I have done this in the past where I had 2 x copies of one profile, where one (the original) was set up for metric and the other (copy) was set up for imperial. I'm almost certain I was using different screensets as well, but it was a long time ago so I could be wrong.

[kirby43a]

I had something like that in mind but I guess being a little overcautious, recollecting the pain of setting up the servo parameters etc. before it would move a single step. I needed confirmation, thanks for the encouragement.

[Neale]

Easy to create a second profile based on an existing one. Start "Mach3 Loader" (which is an application installed as part of the initial Mach3 installation). That gives you the opportunity to create a new profile (just click "Create Profile"), and then tell it which profile you want to use as a starting point. When you load it for the first time, it creates the relevant folder in the macros folder and copies over the macros from the starting profile you specified. You'll probably want to create a new icon on your desktop - copy an existing Mach3 shortcut icon (such as mach3mill), right-click on it, select properties, and in the "target" entry, replace mach3mill with whatever your new profile name is. If your new profile name has spaces in it, then put the profile name in double-quotes (e.g. "router mk2" in my case).

Job done!

You can have as many different profiles as you like, as far as I know. However, there does seem to be a gotcha. If you are using a CSMIO, you can only have one set of CSMIO parameters per machine. That is, all the profiles that use the CSMIO also use the same parameters for it, the ones you set in the config plugins->CSMIO page. That might not be a limitation if you want different profiles because you are playing with different screensets and/or macros for each profile, but it's all with the same machine.

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

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.

[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/forums/viewtopic.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.

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

[Davek0974]

However, there are a few odd things that can happen around M6 that aren't quite right if you are using a CSMIO-IP/M, and I wouldn't be surprised if it's not true for other CSMIO variants. For example, when I first started playing with tool height setting/resetting during an M6 tool change (i.e. between the calls to M6start and M6end), there were problems about losing X and Y position. The fix (in my case) was to "upgrade" to an earlier version of mach3. I'm currently using 3.043.028 which is not the latest version but can still be downloaded and installed. Remember to save any profile modifications in a custom machine profile and not mach3mill or any of the other out-of-the-box profiles or they will definitely be overwritten. The CSMIO compatibility thing is well-known and documented but you won't generally find it unless you go looking for it.

Pretty certain I have run into this on my Bridgeport conversion, IIRC if you jog the table while in the M6 loop it will fault with ePid error.

Any idea how i find the "well documented" info :)

[Neale]

Pretty certain I have run into this on my Bridgeport conversion, IIRC if you jog the table while in the M6 loop it will fault with ePid error.

Any idea how i find the "well documented" info :)

Dave - take a look at this (http://www.calypsoventures.com/forums/viewtopic.php?f=9&t=75#p337)for starters. It has a couple of pointers to some general info on Mach3 internal architecture and at the bottom of the post a pointer to a pdf with a bit more specific info on the CSMIO problem. What it doesn't have is a "fix" as really there isn't a proper fix as such. However, I have found that .028 works fine (at least, I have had no problems with it on my machine) although it has a few other bugs which were fixed in later releases. I have a feeling that these were more lathe-related, though, so not something that worries me too much. I have seen another post that suggests version .022 as well.

Maybe I overstated it a bit when I said "well-documented". The problem is well-documented in the sense that plenty of people have complained about it. In general, it shows up if you do any movement between an M6start and m6end. That rules out tool-height setting during a tool change, which is a bit of a bugger. The "solution" or work-around seems less well known but it does seem to work.

[Davek0974]

Thanks,


tool-height setting during a tool change, which is a bit of a bugger..

THAT was the issue - was going to try that on the mill as it worked great on my mini-mill but that only had a UC100 controller on it. In the end i gave up and locked-out all the auto-set buttons on the screen-set for safety.

It seems my idea will be ok as having the M6 macro move the Z axis works fine so having it also move the knee should be ok too.

[Davek0974]

Thanks for that link, very interesting reading.

As it seems to do with auto tool length and as i am not using that, it also seems to back up my hopes that my new ideas will actually function well for me.

[Neale]

I'm not sure if it's to do with TLO directly, or some of the stuff that gets done at the same time. I don't use TLO as I have the usual ER20 collet on my spindle, so no repeatable tool settings. I have modified some of the tool height setting macros that are often mentioned to work with my setup and controller (so it uses the CSMIO M31-type probing, for example) and I have the usual tool height, initial tool height for multi-tool operations, and second-tool setting macros. These all work fine with the m6 macros now, including various combinations of G28 and manual jogging while tool-changing. Seems pretty solid once I upgraded to the older Mach3!

I'm also pretty confident that the probing and movement stuff works fine in X and Y as well, as I threw together some macros for X and Y probing while setting up the machine and they seemed OK. Not sure that I ever used them during an M6 sequence, though - that seems pretty unlikely. But at least they do work when needed, with the older Mach3 version.

Still tempted every time someone mentions UC300ETH, though - seems to do pretty well everything the CSMIO/IP-M does, and in a supported package. If you buy an expensive BOB to go with it, anyway...

[Davek0974]

Still tempted every time someone mentions UC300ETH, though - seems to do pretty well everything the CSMIO/IP-M does, and in a supported package. If you buy an expensive BOB to go with it, anyway...

That looks ok, I'm a bit confused about the LPT part - if its ethernet, how can it be LPT??
Anyways, the price difference will drop when you add in the cost of all the connectors/adaptors to get from the header sockets to real-world cable connectors etc. Still looks a good board though.

[Ger21]

UC300ETH + UB1 + UCCNC license = $380 US.

Closer feature wise to the IP-S than the IP-M.
And the macros always work. :yahoo:



That looks ok, I'm a bit confused about the LPT part - if its ethernet, how can it be LPT??

The LPT is just the way the pins are configured. They match a parallel port pinout, so that just about any breakout board will plug right into it.

[Neale]

if its ethernet, how can it be LPT??


It talks ethernet to the PC, but instead of direct outputs like the CSMIO range, it has a set of 5 "parallel port" style output connectors. In fact, they are standard PC board headers and each needs to be connected (simply) to a terminal strip (or cheap BOB as the connectors carry the same signals as a parallel port) to give access to the connections or (much better) to a custom BOB which provides opto-isolation plus the potential for 24V signalling. There is a fancy BOB specifically designed to go with it that provides opto-isolated access to all its IO ports. Not sure if it can also handle differential signalling for connection to stepper drivers. The combination isn't cheap - the BOB costs as much as the controller board, I think, but the combination plus UCCNC is competitive with the IP-M if you also add in Mach3.

(edit - Gerry was quicker off the mark! UB1 - that's the board I was thinking of)

[Davek0974]

Its a 5LPT board with ethernet connection? So you would use 5 BOB's too get full functionality??

Just guessing, couldn't see a UB1 win the site ;)


Edit,
typing at same time ;)

Makes sense now, I still prefer the CSMIO if not just for its "completeness" and rugged build.

[Ger21]

"Full Functionality" would depend on the users needs. And there are 1 port, 2 port, and 3 port breakout boards. The UB1 uses 3 of the ports.
http://www.cncroom.com/interface-cards/uc300eth-ub1

You don't need the 5LPT board with the UB1, so you save a few bucks there.



Makes sense now, I still prefer the CSMIO if not just for its "completeness" and rugged build.

But it relies on flawed software, which is the main issue.

[Davek0974]

But it relies on flawed software, which is the main issue.

Yes its one drawback and i have worked around it, I guess i could ask CSLABS if they have done anything on it as the linked stuff was a while back, doubtful though which is a pity IMHO.

[Neale]

I guess i could ask CSLABS if they have done anything on it

About as likely as retrofitting the dual-motor support from the IP-S into the IP-M, more's the pity.