My Triac PC is running on the Denford software V1.30 and works very well but today I have this odd delay and I don't know why.
The delay is when the Z axis is commanded in program.
This program below works just fine until the Z has to rapid to 25mm above the job after cutting the path, at this point there is a delay of about 20 seconds and then it continues until the next Z rapid up. Rapids in the minus direction are fine.
Its as if its waiting for something, timing out and continuing on its way. Its got oil and air and the tool changer is working just fine. It has never done this before so Its got to be something simple I have over looked.
Has anybody any idea why this should be.
Thanks
Graham
O0106
G21 G40
G91 G28 X0 Y0 Z0
N1
G00 G90 G43 X-3.316 Y18.692 Z25. S2000 M3
Z1.
G01 Z-2. F50.
X-3.3 Y14.537 F125.
G03 X0. Y11.25 R3.3
G02 X11.25 Y0. R11.25
G01 Y-5.
G03 X13. Y-6.75 R1.75
G01 X19.5
G02 X23.25 Y-10.5 R3.75
G01 Y-15.
G02 X20. Y-18.25 R3.25
G01 X-20.
G02 X-23.25 Y-15. R3.25
G01 Y-10.5
G02 X-19.5 Y-6.75 R3.75
G01 X-13.
G03 X-11.25 Y-5. R1.75
G01 Y0.
G02 X0. Y11.25 R11.25
G03 X3.3 Y14.533 R3.3
G01 X3.322 Y18.761
G00 Z25. ( this line is where the delay happens)
X-3.316 Y18.692
Z-1.
G01 Z-4. F50.
X-3.3 Y14.537 F125.
G03 X0. Y11.25 R3.3
G02 X11.25 Y0. R11.25
G01 Y-5.
G03 X13. Y-6.75 R1.75
G01 X19.5
G02 X23.25 Y-10.5 R3.75
G01 Y-15.
G02 X20. Y-18.25 R3.25
G01 X-20.
G02 X-23.25 Y-15. R3.25
G01 Y-10.5
G02 X-19.5 Y-6.75 R3.75
G01 X-13.
G03 X-11.25 Y-5. R1.75
G01 Y0.
G02 X0. Y11.25 R11.25
G03 X3.3 Y14.533 R3.3
G01 X3.322 Y18.761
G00 Z25. (and this line)
G91 G28 Y0 Z0
M30
Delay during Z axis move on my Triac
Moderators: Martin, Steve, Mr Magoo
Hallo Rasp,
the programme seems actually to be all right. Only the G28 could be the cause of the faults in my opinion.
Consider this command.
G91 G28 Z0
In step one of G28, the tool will move to an intermediate position that is incrementally nothing (zero) from its current position in Z. In step two, it will go to the zero return position in Z (only). Note that X and Y will not move. For all intents and purposes, we're telling the machine to move the tool straight to its zero return position in Z.
G91 G28 X0 Y0 Z0
In step one of G28, the tool will move to an intermediate position that is incrementally nothing (zero) from its current position in X, Y, and Z. In step two, it will go to the zero return position in X, Y, and Z (together). For all intents and purposes, we're telling the machine to move the tool straight to its zero return position in X, Y, and Z.
G91 G28 X0 Y0 Z3.0
In step one of G28, the tool will move to an intermediate position that is incrementally nothing (zero) from its current position in X, Y. But in Z, it will move up three inches. Maybe the tool is in a pocket you need to clear before moving in X and Y. In step two, it will go to the zero return position in X, Y, and Z (together).
Watch out! Here's what can happen in absolute mode. Consider this command.
G28 X0 Y0 Z0
Assuming the machine is currently in absolute mode (G90), step one of G28 tells the machine to move to the program zero point (probably a crash). Then, in step two, the machine will move to the zero return position (if it still can).
Some programmers don't like to program (ever) in incremental mode. While I don't consider using the incremental mode with G28 to be straying too far from absolute programming, there is a way to stay in the absolute mode when using G28. Consider these commands.
G90 G00 X1.0 Y1.0 (Rapid to hole position)
G01 Z-0.5 F5.0 (Drill hole)
G00 Z0.1 (Rapid out of hole)
G28 Z0.1 (First, stay right where you are in Z, then go to the zero return position in Z)
While this works, I don't like it. I show it just for the sake of explanation. Essentially, we're looking back in the program to the tools last absolute position so we can include it in the G28 command. Again, this does work, but someday you'll probably change a tool's last position. In this case you better also remember to change the related G28 command or you'll be in for a big surprise!
HTH
Enny
the programme seems actually to be all right. Only the G28 could be the cause of the faults in my opinion.
Consider this command.
G91 G28 Z0
In step one of G28, the tool will move to an intermediate position that is incrementally nothing (zero) from its current position in Z. In step two, it will go to the zero return position in Z (only). Note that X and Y will not move. For all intents and purposes, we're telling the machine to move the tool straight to its zero return position in Z.
G91 G28 X0 Y0 Z0
In step one of G28, the tool will move to an intermediate position that is incrementally nothing (zero) from its current position in X, Y, and Z. In step two, it will go to the zero return position in X, Y, and Z (together). For all intents and purposes, we're telling the machine to move the tool straight to its zero return position in X, Y, and Z.
G91 G28 X0 Y0 Z3.0
In step one of G28, the tool will move to an intermediate position that is incrementally nothing (zero) from its current position in X, Y. But in Z, it will move up three inches. Maybe the tool is in a pocket you need to clear before moving in X and Y. In step two, it will go to the zero return position in X, Y, and Z (together).
Watch out! Here's what can happen in absolute mode. Consider this command.
G28 X0 Y0 Z0
Assuming the machine is currently in absolute mode (G90), step one of G28 tells the machine to move to the program zero point (probably a crash). Then, in step two, the machine will move to the zero return position (if it still can).
Some programmers don't like to program (ever) in incremental mode. While I don't consider using the incremental mode with G28 to be straying too far from absolute programming, there is a way to stay in the absolute mode when using G28. Consider these commands.
G90 G00 X1.0 Y1.0 (Rapid to hole position)
G01 Z-0.5 F5.0 (Drill hole)
G00 Z0.1 (Rapid out of hole)
G28 Z0.1 (First, stay right where you are in Z, then go to the zero return position in Z)
While this works, I don't like it. I show it just for the sake of explanation. Essentially, we're looking back in the program to the tools last absolute position so we can include it in the G28 command. Again, this does work, but someday you'll probably change a tool's last position. In this case you better also remember to change the related G28 command or you'll be in for a big surprise!
HTH
Enny
Machine Data:
Model: TRIAC VMC
SerialNo.: EO 4026
DespatchDate: Feb 1992
ExportNo.: 4026
Voltage 220 F.L.C 11Amp 50Hz 1PH
Control Voltage 24V Light Voltage 12V
Main Motor 1HP 0,75 DC PH
SerialNo. Of Electrics: 0001285
Model: TRIAC VMC
SerialNo.: EO 4026
DespatchDate: Feb 1992
ExportNo.: 4026
Voltage 220 F.L.C 11Amp 50Hz 1PH
Control Voltage 24V Light Voltage 12V
Main Motor 1HP 0,75 DC PH
SerialNo. Of Electrics: 0001285
Hi Enny,
How can it affect the "G00 Z25." in the middle of the program the program runs and the part is completed perfectly. The only problem is when the Z axis is commanded to lift to 25mm there is a delay of 20 seconds before it moves, once it has moved it then continues as normal.
I think this is a machine fault not a g-code fault but I may be wrong.
Thank you for your reply
Graham
How can it affect the "G00 Z25." in the middle of the program the program runs and the part is completed perfectly. The only problem is when the Z axis is commanded to lift to 25mm there is a delay of 20 seconds before it moves, once it has moved it then continues as normal.
I think this is a machine fault not a g-code fault but I may be wrong.
Thank you for your reply
Graham
Last edited by rasp on Tue 14 Apr , 2009 11:22 am, edited 1 time in total.
Dear Graham
I apologize.
I did not want to question your abilities and skills.
Unfortunately, I did not know these.
On the other hand I have this stated, disturbances can appear again and again.
Even if a programme is completely fault-free.
These disturbances arise from faults in the control software.
Since the programme introduced by you contains only a simple contour, no necessity passed, in my opinion, for G28 orders.
I therefore thought, a test without the use of G28 could not harm.
You probably are right with your assumption, however. There is for certain a hardware problem.
I apologize again.
Enny
I apologize.
I did not want to question your abilities and skills.
Unfortunately, I did not know these.
On the other hand I have this stated, disturbances can appear again and again.
Even if a programme is completely fault-free.
These disturbances arise from faults in the control software.
Since the programme introduced by you contains only a simple contour, no necessity passed, in my opinion, for G28 orders.
I therefore thought, a test without the use of G28 could not harm.
You probably are right with your assumption, however. There is for certain a hardware problem.
I apologize again.
Enny
Machine Data:
Model: TRIAC VMC
SerialNo.: EO 4026
DespatchDate: Feb 1992
ExportNo.: 4026
Voltage 220 F.L.C 11Amp 50Hz 1PH
Control Voltage 24V Light Voltage 12V
Main Motor 1HP 0,75 DC PH
SerialNo. Of Electrics: 0001285
Model: TRIAC VMC
SerialNo.: EO 4026
DespatchDate: Feb 1992
ExportNo.: 4026
Voltage 220 F.L.C 11Amp 50Hz 1PH
Control Voltage 24V Light Voltage 12V
Main Motor 1HP 0,75 DC PH
SerialNo. Of Electrics: 0001285
Hi Enny,
please except my apology, I did not mean my reply to be aggressive.
After many hours of messing checking and running g-code the fault has vanished. I have no idea what cured it. Has it gone for good, who knows.
During the testing I did find that G81/82 etc have a bug in them, they totally ignore any value in the Z work offset.
I had put +25mm in the Z work offset to make sure my tools were clear of the job and the canned cycles drilled to the original position, every thing else was 25mm above.
Is this a known fault or is it me doing something stupid.
Thanks
Graham
please except my apology, I did not mean my reply to be aggressive.
After many hours of messing checking and running g-code the fault has vanished. I have no idea what cured it. Has it gone for good, who knows.
During the testing I did find that G81/82 etc have a bug in them, they totally ignore any value in the Z work offset.
I had put +25mm in the Z work offset to make sure my tools were clear of the job and the canned cycles drilled to the original position, every thing else was 25mm above.
Is this a known fault or is it me doing something stupid.
Thanks
Graham
-
Triac whizz
- CNC Expert
- Posts: 238
- Joined: Mon 17 Jul , 2006 21:48 pm
- Location: France
could just be something simple like lack of lubrication? the ball screw or dovetails?
Self Catering Lodges in Central France with covered pool & large grounds
www.la-coterie.com
www.la-coterie.com
I've seen these symptoms when an offset error has appeared in the servo drives (and typically on the Z axis when the drive is having to compensate for the weight of the head)
The CNC will not move onto the next block until the Z axis is 'seen' to be 'in positon' - ie within for example +/-25 microns of the programmed position (can't remember what the actual value was on these machines). Down hill is fine but Up hill the drive strugles to pull the Z axis into position.
I think on the control you can press the POS button until the screen shows LAG. This is the difference between where the CNC wants the axes to be, and where they actually are. Run your program and you may find a large lag when the Z axis is stationary after it has travelled uphill and is 'waiting' to move to the next block.
If this looks like the case, post the LAG values when the Z axis is stationary, both after traveling +ve, and -ve (you can do this in JOG mode) and it may give some clues.
Other thoughts: does you machine have any Z axis counterbalancing - either gas strut or weights? Gas Struts might have leaked? Could the Z axis be tight? Try loosening the gib strips?
The CNC will not move onto the next block until the Z axis is 'seen' to be 'in positon' - ie within for example +/-25 microns of the programmed position (can't remember what the actual value was on these machines). Down hill is fine but Up hill the drive strugles to pull the Z axis into position.
I think on the control you can press the POS button until the screen shows LAG. This is the difference between where the CNC wants the axes to be, and where they actually are. Run your program and you may find a large lag when the Z axis is stationary after it has travelled uphill and is 'waiting' to move to the next block.
If this looks like the case, post the LAG values when the Z axis is stationary, both after traveling +ve, and -ve (you can do this in JOG mode) and it may give some clues.
Other thoughts: does you machine have any Z axis counterbalancing - either gas strut or weights? Gas Struts might have leaked? Could the Z axis be tight? Try loosening the gib strips?
If as Mr Magoo points out it turns out to be a position deviation error you may be able to clear it on the Z Axis drive depending which drive is fitted. There is normally a drift pot on the servo drives.
If you have the serial number & year of manufacture then we may be able to determine what drive is fitted.
If you have the serial number & year of manufacture then we may be able to determine what drive is fitted.