Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: striplar on June 22, 2014, 12:37:36 PM
-
Ok, this is getting really scary. I've now had two rapid Z plunges into the work, one while manually entering a Z coordinate which it ignored and went down. The second one I've taken a screenshot of. Look at the positions shown on the program and look at the DRO!
Once my heart rate got back to normal and I was brave enough to get out of E-Stop and reset it, I did a G01Z0F100 move which it happily did, so it clearly hadn't lost where zero was.
So please, can someone tell me what this is all about. I'm using an Aqua screen that I understand is a common one but now I'm wondering if it's full of holes.
Maybe it's because I'm using the computer for other things at the same time as Mach3? Surely that wouldn't result in something like that?
I'm getting to the point where I'm scared to use it. This is a powerful machine, not a toy, and it's capable of causing serious damage.
I've switched to the default screen and set the Z backlash compensation value back to zero in case that's got something to do with it.
Has anyone else experienced anything like this?
-
SO, at that line of code, it just started plunging 25mm too deep?
No, I've never heard of or seen anything like that.
You should never use the computer for anything else while Mach3 is running. It can definitely cause issues, but I wouldn't expect it to do what you're seeing.
And no, the screenset has no effect on Mach3 operation. The only thihg different is the look. Everything "under the hood" is the same Mach3. I created the Aqua screenset, btw.
-
SO, at that line of code, it just started plunging 25mm too deep?
No, I've never heard of or seen anything like that.
You should never use the computer for anything else while Mach3 is running. It can definitely cause issues, but I wouldn't expect it to do what you're seeing.
And no, the screenset has no effect on Mach3 operation. The only thihg different is the look. Everything "under the hood" is the same Mach3. I created the Aqua screenset, btw.
It seems to be related to the high speed movement when it lifts, repositions for the next cut and then plunges again. Yes, your interpretation is correct. It seems to react violently to the F1000 feedrate and then plunge another 12mm or so before happily carrying on with the program running in the window and the DRO updating to the wrong position. If I then stop the program and tell it to go to Z0, its correct. In other words, this is not a case of the machine losing pulses, it agrees with the DRO. It's the DRO that's lost position compared to the program that generated it.
I've slowed the F1000 down to F400 and that seems to resolve the problem. This looks like an issue to do with the rate at which the DRO is capable of keeping up with the program. Maybe there's someone I could send these files and my setup file, I'm sure it would reproduce without a machine connected, after all, it's a dumb open loop system?
I'm using an ESS by the way.
This has nothing to do with the computer doing other functions. It does this regardless of whether the computer is standing idle or not. I thought the whole point of the ESS was to offload the work done by Windows. I've been happily surfing the internet, creating other 3D jobs and all kinds of things while another job has been running without a hiccup.
I'll switch back to the aqua screen since that doesn't affect anything. It's an awful lot better than the default one which is a nightmare in my opinion. I do wish things like the Home buttons weren't dangerously close to the Zero on the DRO's that's an accident waiting to happen.
-
Ok, I can get this to repeat just from the MDI.
All I have to do is to set a feedrate of say F2000, do a move in X or Y and then type Z to a new position and it plunges straight down. This is something peculiar to the setup of Z, nothing else. Remember, this has nothing to do with the machine, the machine is doing exactly what it's told.
The feedrates I mention are not at all fast, I've been using F3000 (3000mm/min) for years on this machine with a different controller.
-
You didn't say you had an ESS. So yes, with an ESS, you can do other things while Mach3 is running.
My guess is that your problem may be related to the ESS.
-
I would have thought that Mach3 would be in control of interpreting the program and displaying the DRO? Surely the ESS only creates the steps?
-
ESS will update the DROs.
Attach your xml and I will take a look.
Hood
-
ESS will update the DROs.
Attach your xml and I will take a look.
Hood
Thanks, I appreciate your help. It's always a problem with a split product like this, it's hard to know who to ask and what part of the system is responsible for each part.
I've attached the xml file and the program I was having trouble with so you can try it. I've set the rapid to F2000 and the following plunge to F500, both within the setup parameters of the machine. Hopefully you will see what happens when it does the lift and then start of each cut.
Cheers,
Roger
-
I will have to look at your xml on the lathe tomorrow as it is the only machine I have an ESS on and I cant look at certain info without an ESS hooked up
BTW just downloaded the plugin version you have and it has a config page for Backlash, so you may want to look at that for your previous issues, maybe a setting or two there. Again afraid I can not see that page due to not having an ESS here, so maybe it doesnt have much relevance.
Hood
-
Thanks, hopefully that will show the same fault. What's weird is that if I perform a rapid move in X/Y & Z together, it's smooth and trouble free. It seems that it might be something to do with the fact that the Z moves on its own that it doesn't like. I suspect that there's a problem in the Z motor setup that it uses to initialise the Z only move. The Z axis uses a different resolution to the X & Y axis because there's a toothed belt giving a 2:1 reduction on that axis whereas the others are direct drive.
-
Can you try something. If you put Mach Offline and run the code does it still show this weird move in the Z DRO?
Hood
-
Can you try something. If you put Mach Offline and run the code does it still show this weird move in the Z DRO?
Hood
Good thinking.... I've just tried this, and yes, the problem is still there. As soon as it does that head up at the end of the first cut, it ends up with the DROs being too far -ve. Hopefully that narrows things down a bit. It also means I can experiment with things here without risking a crash.
-
How about trying an older plugin, go as early as you can find.
Hood
-
I'll experiment with the Z-motor parameters first and see if I can tease out where the problem lies. I've got the Warp9 people looking into it too. I'm just surprised that what I thought was a mature product still has serious flaws like this.
-
I still use one of the first plugins that came out for the ESS, newer ones caused me issues but have not tried any for a long time.
I can say with almost certainty that it is not your hardware as the DRO is showing the movement, so it would seem it is either Mach sending the wrong command to the ESS via the plugin or it is the plugin itself, my guess the latter.
If however you are using Ver 066 of Mach then I would say that may be an issue because it has problems and in my opinion it should have been pulled a long time ago.
Hood
-
Ok I can say its not specific to plugin or Mach version but have been unable so far to work out where it is going wrong.
It seems as if there is some sort of shift going on but not sure why as there doesnt seem to be anything in your code.
For example it seems kind of like it is in Incremental mode but it is not according to Mach, will look and see if I can work out where its going wrong later.
Hood
-
Not found anything yet but can you make a new xml from scratch to see as there is definitely something very weird going on, even homing (I have disabled Home switches in Ports and Pins) and the DRO shows a value for Z and Y when they should be zero in machine coords.
Hood
-
I have to go out on a job now, but I'll try that later. It's been homing fine, including a rapid move to 0,0,0 and it's repeated fine. I think this is to do with the setup of the Z move when it's on its own. If you halve the Zmotor tuning acceleration the fault remains, but if you change the maximum Z velocity to 1000 and leave the accel at 1000 then the problem goes away.
-
Ok I see now your Z is 4000 steps per unit and 2000mm/min. That equates to 133KHz, you have 128KHz set in the plugin for the Z.
Set the plugin to 256 KHz for Z, restart Mach and see if all is fine.
Hood
-
Ok I see now your Z is 4000 steps per unit and 2000mm/min. That equates to 133KHz, you have 128KHz set in the plugin for the Z.
Set the plugin to 256 KHz for Z, restart Mach and see if all is fine.
Hood
Aha! That makes sense then, I was beginning to wonder what it could possibly be. Well spotted, I've tried that offline and it seems to fix the problem. I'd read the notes on that page and assumed that the settings were only going to affect the length of the buffer queue, that's what it seemed to imply to me.
Anyway, many thanks for helping with that, it's much appreciated.
-
And a quick update.... I thought I'd put the X & Y to 256KHz and the Z to 512KHz as an experiment and cranked up the feedrate to the XY maximum of F3000 then ran it through again. I then tried it while streaming music from Spotify, watching BBCi and compiling a complex routing path on my CAM system at the same time. All is bullet proof now as far as I can see.
So it looks like there's no reason why a decent PC with an ESS can't be a full blown multitasking system.
-
The buffer is the top one in the plugin, it is in Hz.
The axes are in KHz and should be set to the nearest to your actual axis frequency but has to be above and not below. In other words if you require 133KHz then you should set it to 256 KHz, setting it higher than required may not be an advantage and may actually have an adverse affect.
Regarding using the computer for multi tasking, it is not personally something I would do, computers are cheap and I prefer to dedicate them to the working of the machine only.
Hood
-
The buffer is the top one in the plugin, it is in Hz.
The axes are in KHz and should be set to the nearest to your actual axis frequency but has to be above and not below. In other words if you require 133KHz then you should set it to 256 KHz, setting it higher than required may not be an advantage and may actually have an adverse affect.
Regarding using the computer for multi tasking, it is not personally something I would do, computers are cheap and I prefer to dedicate them to the working of the machine only.
Hood
Ok, thanks for that. Each to their own. I find it more convenient to have easy access to my CAD/CAM data at the machine. Cheap computers on a machine tool will probably have the issues you're concerned about, a faster one won't have a problem, as I've demonstrated. I can understand if you've grown up with Mach3 that you have had to be wary in the past.
-
I do have easy access, have all machines linked to my desktop via network :)
When I said computers are cheap I did not mean used computers, you can get an integrated motherboard/CPU and some RAM and a HDD for just over £100.
As I said everyone to their own, I was just stating my preference ;)
Hood