Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: ranchak on September 29, 2010, 12:39:15 AM
-
Here we go again. This is the third computer and the same problem still comes up. I am running a program that drills some holes, cuts a few pockets and then profiles. This is the first time I ran this program and I noticed that I did not make the first pocket large enough, so I stopped the run, went to zero and made a few programming changes. The program ran fine then all of a sudden the toolpath runs off to wherever. Again the origin was reset or changed somewhere, somehow by Mach. Take a look at the photos, I pushed Go To Zero which was no where close to being correct. I manually ran the table back to where about 0,0 SHOULD BE, it is off by over 3.5 inches. Seems weird how three different computers are having this same issue. There has to be a glitch or bug somewhere. Also this is the second time that I ran that pocket program, the first time I had no problem. So I don't think that the problem is in the program. I ran the machine for about 10 hours today with no trouble. Any thoughts? I can't belive that I am the only one that is experiencing this kind of problems on a continuing basis. If the DROs didn't change I maybe blame the drives or steppers. If this hadn't happened on three different computers I would blame the computer, but the only thing that is consistent is Mach and me. I'm pretty sure it's not me ::)
-
When using run from here, I always use single block and TO GO distance, I do not trust run from here either.
If the distance from stock is say .500 inch and DRO show 2.000 inches, I know that there is a problem.
TO GO button is my best friend.
Jeff
-
The thing here is Mach is reporting it is at the correct position and shows the toolpath to be in the correct position. From my understanding Mach updates the DROs from its pulse output at the parallel port so if Mach was sending out the wrong pulses the DROs should show that it is way off.
Is it always the same axis that goes off? I thought it was the Y previously?
Have you swapped hardware around recently, ie have you swapped X and Y drives or swapped outputs on the BOB?
Have you monitored the voltage of your power supply whilst cutting? it may be falling short when doing multi axis moves.
Hood
-
When using run from here, I always use single block and TO GO distance, I do not trust run from here either.
If the distance from stock is say .500 inch and DRO show 2.000 inches, I know that there is a problem.
TO GO button is my best friend.
Jeff
I dont see how RFH could be thought of as the problem as it started back correctly and after a while things started going wrong. If it had gone wrong right away after the RFH then yes it could be a problem with it.
Hood
Hood
-
I am running a program that drills some holes, cuts a few pockets and then profiles. This is the first time I ran this program and I noticed that I did not make the first pocket large enough, so I stopped the run, went to zero and made a few programming changes.
'stopped the run' - did you hit 'feed hold' first?
I have noticed Mach losing registration a few times if I just hit Stop, and the manual (somewhere) warns about it.
Cheers
-
have you tried a differnt controler, mabe the cooling fan took a dump
-
I ended the program run, went Go To Zero, Closed G code and the Load G code (once fixed) and pushed Start.
When using run from here, I always use single block and TO GO distance, I do not trust run from here either.
If the distance from stock is say .500 inch and DRO show 2.000 inches, I know that there is a problem.
TO GO button is my best friend.
Jeff
I dont see how RFH could be thought of as the problem as it started back correctly and after a while things started going wrong. If it had gone wrong right away after the RFH then yes it could be a problem with it.
Hood
Hood
-
It was the Y axis before that was off in tolerance. BUT both axis 0,0 would appear to be reset.
The DRO does not change, what changes is 0,0. That is the only answer (or so I think), how can the machine be off when you Go To Zero? Something is changing 0,0. The DROs are really only showing a "location", they do not show true distance. The DROs have no way of knowing where they are in relation to 0,0. If they did the machine would not run off. If 0,0 didn't change Mach wouldn't be trying to move to the "wrong" place.
I think from what I am hearing that this is the same or similiar problem that Terry had with a plasma cutter.
-
ranchak
have you tried running your program without any G00 moves in the code.
open your code with the text editor and change all of your g00 moves to g01 moves with
a speed a little faster compared to the feedrates in the code.this will help stable the code
while looking for problems.
bill
-
No its not the same problem Terry had or at least from what I understand of it.
As far as I know Terry would see the DRO showing the true position of the axis and also the toolpath would show the true position but it was not a position that it was meant to be, in other words when an axis shot off it showed that movement in both the DRO and the ToolPath.
What you are seeing is the DRO and Toolpath showing where the axis is supposed to be but the axis is not there. In other words it seems like your drives are sending the motor somewhere else other than Mach is sending it.
Why I dont know, it could be faulty drives or much more likely is your Step signals are getting noise. It could be Mach but as the DRO and ToolPath seem to show the axis should be other than where it is I cant see how.
Hood
-
Here's another goofy thing going on. In the first picture you see ver. x.x. Also when this "version" of Mach runs, the Auto Tool Zero functin does not work. In the second picture the opening screen is different, but the ATZ function does work. This is something that I have noticed on different PCs running Mach.
Could there be something in a Bios setting or a Windows setting that is causing this? I have disable
Automatic Updates
Screen Saver
Hibernation mode
-
You will get different splash screens when starting Mach, I think there are three and they are chosen randomly.
I cant see how the splash screen could stop a macro working but I am wondering if you are possibly starting a different profile by mistake? One that has the macro and one that doesnt.
Hood
-
Ranchak
Are you sure you are not losing steps way to find out is to set a home point zero all your DRO's reference home to zero then move the machine to way off point then tell mach to go to zero it should return the machine right back to the point you had set if that works then probably nothing wrong with your machine or computer I had a similar problem and what i found was the encoders were losing steps giving mach an incorrect location it only happened when i was working in heavy cut's with a lot of geometry arc's and curves hope this helps.
Dennis
-
I'm using the same profile, I created one when I installed Mach. I tried this numerous times and when the first screen set comes up the ATZ does not work properly.
You will get different splash screens when starting Mach, I think there are three and they are chosen randomly.
I cant see how the splash screen could stop a macro working but I am wondering if you are possibly starting a different profile by mistake? One that has the macro and one that doesnt.
Hood
-
Then afraid I can think of no other reason that would happen.
Hood
-
I've done what you are suggesting and 90% of the time it works. I'm not using encoders so at least that is one less thing to worry about. If I was loosing steps it would have to be a huge amount to be off by 4 inches.
Ranchak
Are you sure you are not losing steps way to find out is to set a home point zero all your DRO's reference home to zero then move the machine to way off point then tell mach to go to zero it should return the machine right back to the point you had set if that works then probably nothing wrong with your machine or computer I had a similar problem and what i found was the encoders were losing steps giving mach an incorrect location it only happened when i was working in heavy cut's with a lot of geometry arc's and curves hope this helps.
Dennis
-
Definatley crazy. I really don't know what to do at this time. I can't continue and have intermittent issues, I'll see if taking a lighter cut will change anything. Other than this I think it might be time to move on to a different control system.
-
Is there anything you can think of that switches on at the time the axis go wild? Something that could cause electrical noise?
Hood
-
Nothing that I can think of. The only thing that is on is an overhead fan and the VFD. These have always been on, nothing new has been added, elecrically speaking. I did remove my ATZ scrip and macro. I turned off the macropump. I'm also going to reprogram my pocketing toolpath and use a smaller stepover and a lighter cut to see if that helps. Right now I'm running a part (hopefully that's what it will be).
-
If it goes wrong dont do a go to zero or whatever, check the DRO and toolpath and see what it shows, ie see if they show the tool has gone wayward or if they show it to be where it should be even though the axis is obviously not there.
Hood
-
It happened again. I just finished a toolpath, waiting to change out tools, had a phone call that I had to take. I changed the tool, zeroed manually, pushed Cycle Start. the machine runs off course, but the DROs read what the last location was before the M6 callout. Here's abit of the code where this happened:
N22450G1X-2.9990Y0.9860Z-0.4800
N22460G1X-3.0000Y0.9745Z-0.4800
N22470G1X-3.0000Y-1.0774Z-0.4800
N22480G1X-2.9990Y-1.0889Z-0.4800
N22490G1X-2.9957Y-1.1057Z-0.4800
N22500G1X-2.9924Y-1.1168Z-0.4800
N22510G1X-2.9884Y-1.1250Z-0.4800
N22520G00X-2.9884Y-1.1250Z0.2500
N22530T203M6
N22540 (Tool: End Mill {0.25 inches})
N22550G43H203
N22560S2500M03
(Profile .250 End Mill)
()
N22590G00X0.0084Y0.1124Z0.2500
N22600G1X0.0084Y0.1124Z-0.2589F10.0
N22610G1X0.0432Y0.1074Z-0.2589F40.0
-
So the machine moved but the DROs didnt?
Hood
-
The DROs read:
X -2.9884
Y -1.1250
Z 0.2500
I changed the tool and zeroed the tool, the axis read the same as above except for the Z.
I push Cycle Start and the table moves away from where it is supposed to. I stopped the program and hit Go To Zero, it is nowhere near being 0,0.
One thing I thought of and I am assuming that it is right, but in General Configuration I read:
Constant Velocity is on
Distance mode is in Absolute
IJ Mode is in Inc
Is this correct?
-
So when the table was moving away were the DROs showing that movement?
Can you sip and attach your two M6 macros.
All these settings are fine or should be depending on your code but from what you have shown they are fine.
Hood
-
Yes the DROs were showing the movement, but they continued "counting" from where the were X -2.9884, Y -1.1250.
I tried to do a driver test and I am told that it is Pulsing Too Fast.
-
Here are the M6 files
-
Disabling the ATZ function and macros did nothing.
-
I am getting confused, one minute the DROs are the same the next they are moving.
Really I think you have to be very methodical in noting down what you see and describing it when things go wrong. What you need to note is where the DRO and Toolpath say the axis is and whether or not it is actually there. Forget the return to zero as all that is telling you is you have lost position, we need to try and work out why you have lost position.
As for the pulsing too fast, was Mach running at the time?
Hood
-
1 question, When this last happened and MACH wondered off, did you see the wandering off in the toolpath display as well? AND did the dros show that it had wondered off the programed toolpath?
Have you tired to reload a known good backup of the XML?
IF you do not have one build a brand new XML from scratch using all the setup info that you have in your old one.
IF that does not work then do a completed reload of mach. BUT FIRST document precisely how it happens NEXT TIME it does it
IT is important when testing that you do not jump around doing a lot of different things at the same time. ONLY a methodical test approach will find your problem. NOTES as Hood said LOTS of noted describing each step you take. AND do them them one step at a time.
You explanation is somewhat all over the place as Hood said. Settle down and we can get to the bottom of the problem.
(;-) TP
-
1 question, When this last happened and MACH wondered off, did you see the wandering off in the toolpath display as well?
I did not notice this.
AND did the dros show that it had wondered off the programed toolpath?
No, they showed exactly what the G Code stated at the time of the tool change
Have you tired to reload a known good backup of the XML?
No I haven't
IF you do not have one build a brand new XML from scratch using all the setup info that you have in your old one.
IF that does not work then do a completed reload of mach. BUT FIRST document precisely how it happens NEXT TIME it does it
IT is important when testing that you do not jump around doing a lot of different things at the same time. ONLY a methodical test approach will find your problem. NOTES as Hood said LOTS of noted describing each step you take. AND do them them one step at a time.
I typically change one thing at a time
You explanation is somewhat all over the place as Hood said. Settle down and we can get to the bottom of the problem.
I think what the problem is I am not saying what I exactly mean. Or this is a miscommunication in the question vs. the answer.
(;-) TP
-
Let's try and start over.
I have removed the ATZ macro and all related items.
This is the same download of Mach that I have installed on three computers.
The computer I am using now is a fresh rebuilt PC, there is no internet connections or other programs running other XP and Mach. This is also a fresh install of Mach on this PC.
There is nothing else running in the garage or house electrically that I know of that is different from a week, month or six months ago.
Now here is what is happening:
Usually I experience a problem (about 90% of the time) after a tool change. The DROs will read whatever the related G Code states. I will change the tool and either manually or using the ATZ feature zero the Z axis. The Z DRO will read 1.000 if I use the ATZ feature. I then push Cycle Start and I can tell instantly that the toolpath is headed in the wrong direction. I have never looked to see if the display screen shows the toolpath in the wrong location. The DROs will read where the tool is sitting at the time of that I stopped the program run. What I do know is that the 0,0 is NOT wher it should be. This is where the problem is (or so I think). If I understand this correctly every machine move is related to an origin, it doesn't have to be 0,0, but there has to be a common known location to base every move from.
-
This is why I am obsessed with the origin changing. Now the DROs do not change. It seems like some how the origin location is changed in memory or wherever Mach keeps it. Now this doesn't happen every single time I run a part. On Tuesday I ran for over 10 hours with no troubles, this was two parts, each about 4.5 hours each. I started a new part and everything was going fine until I realized that I needed to make a programming change. I stopped Mach, pushed Go To Zero, Closed the G Code. I then made my programming change and loaded my revised G Code. I pushed Cycle Start and the program was running fine. Then I heard the cutter getting bogged down and it then took the huge pass that you can see in my photos that I posted. There was no tool change when this happed. I have since removed the ATZ macros and tryed to run the same part. The first time I ran the part the drilling cycle ran for about four holes, on the fifth hole the drill bit was drug acrossed the work piece instead of being .25 safe Z height, I stopped the program run. I tried a second piece after resetting the DROs and Zeroing the Z axis. This time the drill bit plunged quickly into the work piece and I saw the DRO change and it was about .625 below what the original Z height.
I haven't run anything since, I did try to run my Driver Test and I always get Puling Too Fast. I have run the Driver Test with Mach running and without, always the same results.
-
What I meant is the DROs read what the G Code is, then when the machine starts to move the DROs change, but the DROs do not try to catch up like if you had feedback. They are reading where the tool bit is. There is no consisteny with what is happening. Sometime using the ATZ feature causes a problem, sometimes it doesn't. Sometimes there is a problem after the second tool change, sometimes it is after the fifth tool change. I watch very carefully to try and remember what was happening at the time there is a problem. But there is no consistency so one time it is this way and another time it may be a different scenario, but there is some overlap or similiarities.
I am getting confused, one minute the DROs are the same the next they are moving.
Really I think you have to be very methodical in noting down what you see and describing it when things go wrong. What you need to note is where the DRO and Toolpath say the axis is and whether or not it is actually there. Forget the return to zero as all that is telling you is you have lost position, we need to try and work out why you have lost position.
As for the pulsing too fast, was Mach running at the time?
Hood
-
Do you have home switches on the machine?
Hood
-
This thread is like a deja vu for me. :o
It seems I am suffering from a very similar trouble also on my machine: After performing a toolchange, sometimes something goes wrong.
The crazy thing is: I was (and I still am) not able to recognize any pattern in the accidential loss of position, except that it happens after tool change, when pressing "Cycle start" to perform Auto-tool-zero.
-The machine is equipped with home switches on all axis' and tool height sensor.
And here is, what should happen:
G-Code runs
Tool change commanded in G-Code
Z, and then X and Y are moved to a convenient tool change position (by M6Start-script)
---
Manual tool change
---
Home Z axis
go 20mm above tool height sensor
then do the whole referencing stuff...
(In fact, this doesn't matter, because it seems, that the "M6End-Script is not even executed, or something bad happens before mach3 can execute the script..)
... and this happens after Manual tool change
maybe an unexpected movement to somewhere in the center of the stock, :-\
maybe there appears the "preparation move" dialog before the unexpected movement will take place... :'(
What I can state:
- The Z Axis is homed by my M6End script before the tool leght is measured, so, if this homing is not performed, I KNOW, that the movement is NOT caused by my script
- This "terrible accident" happens SOMETIMES not ALWAYS, whenever:
- G-Code remains absolutely unchanged (same part)
- XML remains absolutely unchanged
- NO ONE button is pressed during program execution
---> This is the whole story...
This, I feel, is a real quirk, and I know for sure, it will be very hard to find and repair what is causing this trouble.
(maybe some race-condition in mach 3 code, or some other timing problem which also might not be reproducable on any hardware...)
After spending lots of working hours in researching this damned mis-behaviour, I decided to keep my hand just over the emergency-off after tool change and wait for the release of Mach3 V4... (by the way: when...?????)
regards,
Konrad
-
No home switches, no limit switches
-
No home switches, no limit switches
So, it can be stated that electric noise does NOT cause the trouble we have ;-)
(In deed, I also made test runs with de-activated switches to isolate "noise" from the possible causes...)
-
Ok do you ever home the machine by pressing the Ref All button?
Reason I ask is because you were saying about the zero position and about how Mach must reference to somewhere. Well what Mach references to is the machine coordinates and these are set by homing and the offset coordinates that you use (G54, G55 etc) all reference to them.
So just wondering if this could be a problem, now on a rotary axis I could see it being an issue, especially if you only rotate one way as the number will get so big and may roll over so Mach may have issues. With a linear axis it should not get so big but it may do if you are always resetting your offset zero and it just happens to be that you always move the same way when setting the zero.
As said this is just a stab in the dark but as a test how about moving your machine so the tool is fully negative in X and Y and fully positive in Z (table fully right and fully towards column and z fully up)_and then press Ref All, you can then move to where you want your offset zero to be and zero each axis and then see if there are still issues. As said its a long shot but the problem is a very weird one so everything should be considered.
If it does happen again make sure you look at the DROs and also the Toolpath and see whether they show that the Mach knows where the cutter is, ie it shows it going wild, or if they show that it is where it should be but obviously is not.
Hood
-
Ok do you ever home the machine by pressing the Ref All button?
For my machine, I can confirm that homing is regularly done by "ref all" and home switches. So, my machine coordinates always refer to the same mechanical position reliably...
I also confirmed (by watching DROs) that MACHINE coordinates remain correct when the big accident (TM) occurs. i.e. the machine does NOT get out of reference by itself (of course, after hitting the stock and trashing the bit, everything stalls and is de-referenced)
Next step will be to run programmes from the diagnostic screen and check offsets and so on...
-
Konrad
so your DROs and Toolpath show where the tool is supposed to be but its not?
Hood
-
Konrad
so your DROs and Toolpath show where the tool is supposed to be but its not?
Hood
The MACHINE coordinates are correct. (same as physical axis position)
-- This is easy to recognize, because the physical machine moves quite continously.
The CURRENT coordinates (with work, fixture, tool and temporary offsets) are heavy to recognise, because the offsets seem to be switched during execution of toolchange and selecting another tool-table entry.
(So to say, I was not able to determine wether they are correct or not.)
-- This will be my work on the next weekends, because I am not working in the mechanical lab during the week.
-- I think it makes sense to capture everything (display and machine) by camera, to be able to review the crash. (I fear any screen capture software could influence the CPU load and thus timing of the PC)
-
Ok look forward to your results but it seems to be Mach does indeed know where the axis is if the machine coords are correct, doing a verify would confirm this I think.
Hood
-
Ok look forward to your results but it seems to be Mach does indeed know where the axis is if the machine coords are correct, doing a verify would confirm this I think.
Hood
Yes, it seems to know where the axis is, but wants to go to the absolutely wrong position for some reason I am not yet able to see :-(
(I only spend so much time in Mach3 because I honestly don't expect he competitors to work better - they will also have their own quirks. In fact, Mach3 with all it's possibilities is brilliant. Hopefully, we will catch the glitch before christmas *gg*)
-
If it only happens after a tool change, it may be interesting to look at the M6 macros in some detail?
Cheers
-
If it only happens after a tool change, it may be interesting to look at the M6 macros in some detail?
Cheers
It also happens when the M6End is an empty file. *lol*
-
Ok, but what's in the M6Start?
-
I never use the Ref All Home, I set the table where I want it and the use the ZeroX,Y,Z buttons. Did yuo see anything weird in my M6 macros?
-
I do not use G54 or G55 in my code.
Could the problem lie in my pulses being to fast? Parallel Port?
-
You know, this does remind me of some problems I was having. In one case a program restarted itself from the beginning, rather than continuing on from Hold; in another case the tool on the Z axis tried to go through the floor. There were others.
But careful investigation showed that by and large, all my problems happened in conjunction with my interacting with the system. Further careful checking showed that they fell into two classes.
Class 1: I forgot to zero the Z-axis after changing tooling.
Class 2: I accidentally bumped the keyboard or the mouse, causing all sorts of havoc with resets, zeroes and edits.
I did try to blame the machine, but long experience with computer systems told me otherwise. It was an operator effect. (That's me.) And in every case of course, the machine coordinates were correct, even if the user coordinates were ... aberrant. So I learnt (am still learning) to avoid playing with the mouse and the keyboard while the machine is running, and to check every action. In fact, sometimes I deliberately put an M1 after an M6, to make me check.
Now, I am not saying that my problems are the cause of your problems, but one has to wonder. After all, the hiccups seem to happen only after operator action, and certainly not every time. At the very least, it may be worth looking for this.
Cheers
-
I have done what you said, occasionally I will bump the escape key. Unfortunately I don't believe the problems I am experiencing are operator related. I wish it was and I could fire myself.
You know, this does remind me of some problems I was having. In one case a program restarted itself from the beginning, rather than continuing on from Hold; in another case the tool on the Z axis tried to go through the floor. There were others.
But careful investigation showed that by and large, all my problems happened in conjunction with my interacting with the system. Further careful checking showed that they fell into two classes.
Class 1: I forgot to zero the Z-axis after changing tooling.
Class 2: I accidentally bumped the keyboard or the mouse, causing all sorts of havoc with resets, zeroes and edits.
I did try to blame the machine, but long experience with computer systems told me otherwise. It was an operator effect. (That's me.) And in every case of course, the machine coordinates were correct, even if the user coordinates were ... aberrant. So I learnt (am still learning) to avoid playing with the mouse and the keyboard while the machine is running, and to check every action. In fact, sometimes I deliberately put an M1 after an M6, to make me check.
Now, I am not saying that my problems are the cause of your problems, but one has to wonder. After all, the hiccups seem to happen only after operator action, and certainly not every time. At the very least, it may be worth looking for this.
Cheers
-
I do not use G54 or G55 in my code.
Could the problem lie in my pulses being to fast? Parallel Port?
You do, you use at least G54 as you can not use anything else unless your code has a G53 on every single line of code.
G54 is the default offset and it is the numbers you have in the DROs and it is the offset you are changing when you zero an axis..
Please try doing the Ref all as I mentioned above, it will set your machine coords to zero and then you can move to where you want and zero each axis and that will set your G54 offset to zero and you can start again.
Pulsing too fast is not good and will definitely cause you problems, if you are not running Mach when getting that message then there does indeed seem to be an issue with your computer and the pulsing engine.
Hood
-
Hood, thanks for all the input the past two days
The problem that is being discused here is very similar to what I have been fighting, After a tool change M6 T?? the system loses or resets the home position in X especially if you change from G54 to any other offset, I have also noticed that the tool path is reversed in X and Y when the program and if you have soft limits set they will show a over travel in one axis or another. I suspect that only using G54 corrects this problem. I will test this theory today.
So it looks like I an not the only one fighting this problem.
-
To be honest the only similarities I see between them is that the machines are not doing what you are expecting them to do. Yours I think is a plugin issue but I am certainly no expert. I can however say I use offsets and tool changes(not automatic height setting) all the time on the mill and I have never witnessed the axis reversing.
Did DSPMC have anything to say?
Hood
-
No I have heard nothing form the DSPMC guy's or from my post
Just to confirm the program does not run reversed it runs normal only the tool path display reverses or after a tool change using (auto height settings)
M6 T4
G55 x0.0 y0.0
G00 G43 H4 Z1.0
there is a 50/50 Chance that it will not go to G55 it will be off in x or if it does and you go back to G54 after tool change it will be lost
I have not tried using auto height to see if it makes a difference
-
Hopefully they will reply, at least they will be able to test things out with a DSPMC. Even if they come back and say all works fine there with your xml and code it will at least be another possibility removed.
Just to clarify the reason I dont see these being similar is
ranchak's problem doesnt seem to involve the tool change as it happens at other times although a toolchange seems to be most common. Also it would seem he only uses the G54 offset where as your problems seems to be centred around the offset change and also your toolpath reverses where ranchaks doesnt.
Hood
-
Valid points, I will running the machine and working on debugging over the next few days and I will let every know what the conclusion is
-
Look forward to the results, hopefully they will lead to a solution.
Hood
-
M6 T4
G55 x0.0 y0.0
G00 G43 H4 Z1.0
Purely out of curiosity, what happens if you rewrite this as
M6 T4
g55
g0 x0 y0
g43 H4
g0 z1
I have limited faith in the ability of ANY parser to always interpret the more complex statements correctly. I prefer to treat systems as being slightly simple-minded...
Cheers
-
In reply to egerber.
I am not sure that the DSPMC supports soft limits. It didn't originally and I am not sure if it does now.
I don't use any of the offsets other than g54 so I don't know if I have the problem or not.
I will respond to your post in the dspmc section.
-
Egerber
I was running my mill yesterday and needed to have a feature of the program run before it got to the end of the code so stopping the code and then scrolling down to find the line i needed i did a set next line and run from here started mach and the machine cut the feature but when the code finished and i did a return to Z on the mach panel it ran the mill to another point other then the original home point and ran the cutter way deeper then it was set is this whats happening to you?
Dennis
-
Dennis
What you experienced sounds different then what I have been seeing, However I don't trust the run from here feature because in my experience it does not always load all the position information so I only use it at a tool change so I know all values for position are called and that seems to work fine
-
Ergerber
Well i agree Mach has some quirks but it works well what version of Mach are you running ? I am always skeptical of updating.
Dennis
-
Dennis
I am running R3.042.040 of Mach and Version 3 DSPMC plug-in. I have been making headway with some of the issues and the appear to be G code related so currently we are breaking down some of the complex lines to see if this helps, I am testing a program currently the drills and taps three different size holes at 96 different locations using 7 different tools, so we will see.
-
Egerber
So you have found the problem it was all code related have you found anything weird in the R3.043.40 version seams that when i update my mill version thing's go ok but when i update the lathe version it always screws up.
Dennis
-
Dennis
I found that the problem was directly related to the tool change I changed the config to Ignore Tool Change from Stop Spindal wait for cycle start and added befor the next tool M0 and every thing is fine now
I also found that if you don't make tool changes ther is no problem
There is another thread under plugins DSPMC that has moor info
-
Hi Guys, I have changed to a different machine program and none of the issues that I was having with the origin changing or whatever we want to call it are happening. I would like to thank everyone who has helped, especially Hood, Steve at PMDX and David Cole of Cole Controls, but I still believe that there is a bug somewhere that is creeping up.
-
Ergerber
Good to hear you have the problem solved i use a tool change but not as many as you have noted so far anyway and found no problem to date in the mill application lathe is another issue.
Dennis
-
Good afternoon, ;D
as promised, I spent the weekend in the lab.
1.
As I stated, I am quite sure that the M6End Script is sometimes not started, or is interrupted by another "Ghost" sending commands to the trajectory planner. Maybe, Mach3 does not see wether the M6End Script is terminated before continueing with other (paused) operations.
To be sure that my tool-change script is able to finish properly, I attached the content of M6End Script to M6Start Script, generated a Message window to have a pause for the manual tool change. As a result, the M6End is no longer needed.
--> After this change, I could do tests for hours, without encountering any surprising events.
2.
Secondly, I noticed a clearly reproduceable position error after completing the tool change: Z-Axis was wrong.
So to say: Machine DRO and Work DRO are showing correct coordinates, but, the "Z target position" was incorrect.
"z = GetToolChangeStart(2)" delivers the WORK coordinates before start of the toolchange. Unfortunately, this value does NOT include the tool lenght offset. So, when commanding the return movement with a "straight feed" or "straight traverse" command, the Z position is wrong, because those commands need the "controlled point" as target coordinate, which includes the tool lenght offset.
Of course, it has to be taken into account that you need the tool lenght offset BEFORE performing the tool change and new tool measurement... So, you have to do it all in one script, or you have to use a global variable to store the "old" tool offset.
So, I am fine now, waiting for new adventures... I will inform you about the next crashed drill bit. >:D
Regards, Konrad
-
--> After this change, I could do tests for hours, without encountering any surprising events.
Valuable information.
"z = GetToolChangeStart(2)" delivers the WORK coordinates before start of the toolchange. Unfortunately, this value does NOT include the tool lenght offset.
One could argue about whether that means the 'Z coord' is wrong or just misunderstood, but clearly one has to be very careful about what ASSUMPTIONS about definitions one makes in writing the code.
Once again, very valuable information.
So, you have to do it all in one script, or you have to use a global variable to store the "old" tool offset.
Good point. Fortunately there are a lot of spare global variables available.
All very helpful: thank you.
Cheers
-
"z = GetToolChangeStart(2)" delivers the WORK coordinates before start of the toolchange. Unfortunately, this value does NOT include the tool lenght offset.
One could argue about whether that means the 'Z coord' is wrong or just misunderstood, but clearly one has to be very careful about what ASSUMPTIONS about definitions one makes in writing the code.
Once again, very valuable information.
[...]
All very helpful: thank you.
Cheers
Thanks for your feedback :-)
I better should have said: "wrong for what I wanted to do with it" ;-)
My reference was the default script which comes together with Mach3. I just took apart and reassembled it. So, my conclusion was that I just could return to the coordinates delivered by "GetToolChangeStart" function... At least my conclusion was wrong... ;-)
Konrad
-
Hello,
The fact that you have a tool length active at a tool change is a bit odd.. You should cancel the tool length offset when you are changing tools. Also here I delete ALL The code from the M6 end Macro. I am one of the guys that likes to take care of moving the machine in the Gcode file... Depending on the part you are cutting you may want to change how you get back from a toolchange and by having a "dumb" tool change it allows you to do this. Having said that I don't think I can change how the Data is recorded with the GetToolChangePosition(2). The reason is that this has been like this for so long that I can't change it.. if you would like to add the toollenth offsets in your toolchange code please do so, you can get the data in VB.
Thanks and if I am not reading this right please tell me where I am going wrong.
Thanks
Brian
-
Hello Brian.
thanks a lot for your hints. :)
As I understand that it isn't easily possible to change a part of the program, on which many users have built their scripts and customisations, I myself took account of the coordinates which are delivered by the "GetToolChangeStart" function in my script.
As of now, everything is working and I am happy.
best regards
Konrad
-
Hello Konrad,
Thanks for the update!
Brian