Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: Mauri on January 28, 2018, 05:01:24 PM
-
Hi,
Does anyone have a Real G93 4 Axis Gcode output from a CAD/CAM program?
Regards,
Mauri.
-
Here you go a fanuc one
-
Dude1,
Thank you.
Regards,
Mauri.
-
Question,
Why do CAM Posts that process G93 Code apply them to both Arc movement and Linear Movements?
These F Speeds become inaccurate when machining in Simultaneous mode (i.e.) not all are similar movements.
Why do they not just apply them to the Arc Movements since they are the ones with the incorrect F speed?
All it would mean is that the G-code would have G93 on for example on all Arc A Axis movements with its calculate F speed and G94 on All X/Y/Z Linear movements with its user preset F Speed.
This would cover every type of multiple Axis shape and be able to do both normal and Simultaneous CNC machining with Accurate Fspeeds.
Can anyone shed any light on this?
Regards,
Mauri.
-
Hi Mauri,
I've never used G93. Found this video and it explained quite a bit:
https://www.ganotechnologies.com/cnc/rapidrotary/ (https://www.ganotechnologies.com/cnc/rapidrotary/)
The converter has the option of processing both the linear and rotary moves or just the rotary moves only, although I have no idea how that would work, in fact by my
reasoning it can't work.
My question is: what happens when you have a coordinated move which includes a linear and a rotary component?
The simplest I can think of is
G1 X50 A180, my expectation would be that the X axis would drive 50mm while the A axis rotated 1/2 a turn. If the current feedrate is 180 and is conventionally
interpreted the move would take 1 minute.
If the feedrate were 4 and it were interpreted as inverse time mode then the move would take 15 secs (1/4 minute).
You ask why the G93 interpretation is applied to the linear component of the move.....how else can you interpret it? If you wish the rotary move to complete in 15 secs
then for the linear component to be coordinated it must also complete its move in 15 secs. The F word for the linear move would have to be 200mm/min whereas the
conventionally interpreted F word for the rotary component would be 1440 deg/min. The two F words don't match up. I argue therefore that if a move combines rotary and
linear components then both components must be treated the same way or the move will break, that is NOT be coordinated.
Where a move is solely linear or solely rotary then I could see that differing feed interpretations would work.
Imagine a move G1 X50 Y50 Z50 F86. I expect the controlled point to move 50mm in the X direction, 50mm in the Y direction and 50mm in the Z direction. The 3D distance
is 86mm and with a feedrate of 86mm/min the coordinated move would take 1 minute to complete, easy, normal interpretation.
The same move but inverse time mode would be G1 X50 Y50 Z50 F1. The move would still complete in 1 minute.
These F Speeds become inaccurate when machining in Simultaneous mode (i.e.) not all are similar movements.
I'm not sure how you come to this conclusion...this example suggests that the coordinated move completes in the same time with the same trajectory and
I see no inaccuracy in it.
Craig
-
Craig,
my question is as to why the CAM G93 programmers decided to use the average method and not a precise one.
I have been working with this for a short time, but have done all the calculations and have found that none of the CAM G93 generating programs are accurate especially then all axis are one the same line.
If for example you use the program from the website but you have X/Y/Z on the same G-Code line, but have all the A Axis on a seperate line you will get a different answer, but closer to the correct one.
I am working with the writer of that program from the web you posted to come up with a better solution.
Just to let you know I posted the same website on another post.
I you use the program make sure that you keep the setting in Inch (with G-Code using inch or mm) as mm will produce an incorrect result.
The G93 is supposed the make all moves maintain the user set Fspeed, but when used on the same line with all the axis move it cannot do so.
The G93 formula for Linear is different to the Arc move and taking an average will only make it close if all moves move a similar distance.
Calculating each individually especially when the move differ proves this point mathematically.
The real importance of G93 is to ensure all surface speeds are the same.
So Fspeed X/Y/Z are user set under G94 but A is not a linear move under G94 so to make this A axis do the same as X/Y/Z then it must be converted to produce the same Fspeed using G93.
This then means since X/Y/Z allready moves at the correct Fspeed, all you need is to move the A axis the same way using G93.
The becomes more evidant with 4 Axis simultaneous of a statue for example that has many part offset for center.
Here are the formulaes for Linear and Arc moves converted to G93.
For linear
Let’s say
G1 X0.000 Z1.000 F400
G1 X0.100
Then
G93 F speed = 400/.1 = 4000 G93 Fspeed for that move.
For Angular
Let’s say
G1 X0.000 Z1.000 F400
G1 X0.100
G1 A5.000
Then
G93 F speed = 400/(2 x Pi() x Z1.000 x A5.000/360) = 400/(2 x 3.141592654 x 1 x 5/360 = 400/0.087266463 = 4583.662361 G93 Fspeed for that move.
This would apply for every A axis move.
Or a simpler method
G93 F speed = 400/ (Degree arc move in radians/Z) = 400/(0.087266463/1) = 4583.662361 G93 Fspeed for that move.
The program writer is reviewing his program on how to correct it amd make it better us the many examples I have sent him.
Will let you know what we come up with.
Regards,
Mauri.
-
Good thread guys,
Never used the inverse time mode, so I spent time researching G93, unfortunately never finished doing it.
You won't find much info on G93 and you need to get into the math that is involved to get a good feel for what needs to be accomplished by the controller.
The statement that you start at some point and finish at some point all in a given time frame for axes involved
is ok for making something complex easy to grasp, BUT, what is truely involved to precisely machine something using complex motion say 3+2 is a different story.
RICH
-
Hi Mauri,
I think the difference here is between inverse time mode and constant surface speed.
in my example
G94
G1 X50 Y50 Z50 F86 completes in 1 minute with a cut speed of 1mm/sec
G93
G1 X50 Y50 Z50 F1 completes in 1 minute, same trajectory, same time to completion, therefore same cut speed ie 1mm/sec
This is straight inverse time mode and it works just fine. What you want is a rotary move subsequent to the linear move to have the same cut speed as the linear move:
G93
G1 X50 Y50 Z50 F1 cut speed=1mm/s
G1 A5 F=nnnnn
where nnnn is such that the cut speed is still 1mm/sec
The cut distance = (5/360)*PI*2*radius and radius is Z=50
cut distance =4.363mm
time to complete at a desired cut speed of 1mm/sec is 4.363 sec
Fnnnn= 60/4.363 =13.75
This is a constant cut speed expressed as inverse time mode but requires the radius for the calculation to be made. The two are fundamentally different.
Craig
-
Just for fun heres the code for it.
[code// Start of multi-axis feedrate logic
/***** Be sure to add 'useInverseTime' to post properties if necessary. *****/
/***** 'inverseTimeOutput' must be defined. *****/
/***** 'headOffset' should be defined when a head rotary axis is defined. *****/
/***** The feedrate mode must be included in motion block output (linear, circular, etc. *****/
var dpmBPW = 0.1; // ratio of rotary accuracy to linear accuracy for DPM calculations
var inverseTimeUnits = 1.0; // 1.0 = minutes, 60.0 = seconds
var maxInverseTime = 9999; // maximum value to output for Inverse Time feeds
/** Calculate the multi-axis feedrate number. */
function getMultiaxisFeed(_x, _y, _z, _a, _b, _c, feed) {
var f = {frn:0, fmode:0};
if (feed <= 0) {
error(localize("Feedrate is less than or equal to 0."));
return f;
}
var length = getMoveLength(_x, _y, _z, _a, _b, _c);
if (true) { // inverse time
f.frn = inverseTimeOutput.format(getInverseTime(length[0], feed));
f.fmode = 93;
feedOutput.reset();
} else { // degrees per minute
f.frn = feedOutput.format(getFeedDPM(length, feed));
f.fmode = 94;
}
return f;
}
/** Calculate the DPM feedrate number. */
function getFeedDPM(_moveLength, _feed) {
// moveLength[0] = Tool tip, [1] = XYZ, [2] = ABC
if (false) { // TCP mode is supported, output feed as FPM
return feed;
} else { // DPM feedrate calculation
var moveTime = ((_moveLength[0] < 1.e-6) ? 0.001 : _moveLength[0]) / _feed;
var length = Math.sqrt(Math.pow(_moveLength[1], 2.0) + Math.pow((toDeg(_moveLength[2]) * dpmBPW), 2.0));
return length / moveTime;
}
}
/** Calculate the Inverse time feedrate number. */
function getInverseTime(_length, _feed) {
var inverseTime;
if (_length < 1.e-6) { // tool doesn't move
if (typeof maxInverseTime === "number") {
inverseTime = maxInverseTime;
} else {
inverseTime = 999999;
}
} else {
inverseTime = _feed / _length / inverseTimeUnits;
if (typeof maxInverseTime === "number") {
if (inverseTime > maxInverseTime) {
inverseTime = maxInverseTime;
}
}
}
return inverseTime;
}
/** Calculate the distance of the tool position to the center of a rotary axis. */
function getRotaryRadius(center, direction, toolPosition) {
var normal = direction.getNormalized();
var d1 = toolPosition.x - center.x;
var d2 = toolPosition.y - center.y;
var d3 = toolPosition.z - center.z;
var radius = Math.sqrt(
Math.pow((d1 * normal.y) - (d2 * normal.x), 2.0) +
Math.pow((d2 * normal.z) - (d3 * normal.y), 2.0) +
Math.pow((d3 * normal.x) - (d1 * normal.z), 2.0)
);
return radius;
}
/** Calculate the linear distance based on the rotation of a rotary axis. */
function getRadialDistance(axis, startTool, endTool, startABC, endABC) {
// rotary axis does not exist
if (!axis.isEnabled()) {
return 0.0;
}
// calculate the rotary center based on head/table
var center;
if (axis.isHead()) {
var pivot;
if (typeof headOffset === "number") {
pivot = headOffset;
} else {
pivot = tool.getBodyLength();
}
center = Vector.sum(startTool, Vector.product(machineConfiguration.getSpindleAxis(), pivot));
center = Vector.sum(center, axis.getOffset());
} else {
center = axis.getOffset();
}
// calculate the radius of the tool end point compared to the rotary center
var startRadius = getRotaryRadius(center, axis.getEffectiveAxis(), startTool);
var endRadius = getRotaryRadius(center, axis.getEffectiveAxis(), endTool);
// calculate length of radial move
var radius = Math.max(startRadius, endRadius);
var delta = Math.abs(endABC.getCoordinate(axis.getCoordinate()) - startABC.getCoordinate(axis.getCoordinate()));
if (delta > Math.PI) {
delta = 2 * Math.PI - delta;
}
var radialLength = (2 * Math.PI * radius) * (delta / (2 * Math.PI));
return radialLength;
}
/** Calculate tooltip, XYZ, and rotary move lengths. */
function getMoveLength(_x, _y, _z, _a, _b, _c) {
// get starting and ending positions
var moveLength = new Array();
var startTool;
var endTool;
var startXYZ;
var endXYZ;
var startABC = getCurrentDirection();
var endABC = new Vector(_a, _b, _c);
if (currentSection.getOptimizedTCPMode() == 0) {
startTool = getCurrentPosition();
endTool = new Vector(_x, _y, _z);
startXYZ = machineConfiguration.getOrientation(startABC).getTransposed().multiply(startTool);
endXYZ = machineConfiguration.getOrientation(endABC).getTransposed().multiply(endTool);
} else {
startXYZ = getCurrentPosition();
endXYZ = new Vector(_x, _y, _z);
startTool = machineConfiguration.getOrientation(startABC).multiply(startXYZ);
endTool = machineConfiguration.getOrientation(endABC).multiply(endXYZ);
}
// calculate the radial portion of the move
var radialLength = Math.sqrt(
Math.pow(getRadialDistance(machineConfiguration.getAxisU(), startTool, endTool, startABC, endABC), 2.0) +
Math.pow(getRadialDistance(machineConfiguration.getAxisV(), startTool, endTool, startABC, endABC), 2.0) +
Math.pow(getRadialDistance(machineConfiguration.getAxisW(), startTool, endTool, startABC, endABC), 2.0)
);
// calculate the lengths of move
// tool tip distance is the move distance based on a combination of linear and rotary axes movement
var linearLength = Vector.diff(endXYZ, startXYZ).length;
moveLength[0] = linearLength + radialLength;
moveLength[1] = Vector.diff(endXYZ, startXYZ).length;
moveLength[2] = 0;
for (var i = 0; i < 3; ++i) {
var delta = Math.abs(endABC[i] - startABC[i]);
if (delta > Math.PI) {
delta = 2 * Math.PI - delta;
}
moveLength[2] += Math.pow(delta, 2.0);
}
moveLength[2] = Math.sqrt(moveLength[2]);
return moveLength;
}
// End of multi-axis feedrate logic]
-
Dude1,
Thank you for the code.
What program language is it for?
Below are two examples.
The both produce a Step Circle on a Rotary Axis.
CircleStepTest1/2
Have X/Z/A on the same line
CircleStepTestx
Has A on a separate Line.
The G93 is the result.
I will send the rest on the next post reply.
Regards,
Mauri.
-
More attachments,
These are the rest.
You can see in these example that calculating all X/Z/A gives you different results to X/Z and A on separate lines.
Regards,
Mauri.
-
That's from the HSM/Fusion 360 post processor it's java in there extension of .cps
Some machine can handle useing inverse time not all.
It's time of flight so it all tries to move in sink with the rotary motion, if you did not run in sink with the rotary axis the rotary axis moves slow as a wet week or you have to have it's feed rate over 2 times faster than a linear axis to just keep up
-
Dude1,
Thanks for the info.
I manually calcuated this next file.
Attached the same CircleStepTest file, but this time it has both G94 and G93 in the G-Code.
Could anyone try these files as an AIR test as I currently do not have a running 4 Axis for Mach4 and compare the times.
I have included the Simulated cut shape using Predator and all four G93 files run and cut the same shape.
Regards,
Mauri.
-
That shape part does not need inverse time it's 2 moves then one then 2, it's for when you wont to move many axis at the sametime like 3 plus axis, that toolpath I posted is a wrap 4 axis toolpath doing 4 axis moves at onces it makes it more continuous than wrap.
-
Dude1,
Yes I am fully aware of what you are saying, this was a simple example as the forum system cannot receive large 4/5 axis simultaneous G-code.
It does still speed up the cut as it does have variable movement of the A axis.
It also shows the issue, when your axis movements vary (i.e.) when one axis moves a lot more than another as it happens in simultaneous axis machining of statues.
A normal CNC cut would be a spiral cut but would not make a precise shape like the supplied G-Code.
Below are G93 calculations and my take on there results I have calculated.
Full Movement Distance Calculation D= square root of ( dx^2 + dy^2 + dz^2 + a arc_length^2) used in the Gano Technology program.
Full Movement Distance Calculation D = square root of (dx^2 + dy^2 + dz^2 + a arc_length^2 + b arc_length^2 + c arc_length^2) This would be a 6 axis version
[where dx is the change in x from the last move, etc.]
ArcLen = R * theta (where R is the current largest Z value) and theta is the change in rotation for that line (converted to radians). Used in the Gano Technology program.
G93 Fspeed = G94 Fspeed / D full movement distance.
This produces an average speed across all Axis.
If calculating Linear and Arc movments seperately then
D = dx and G93 Fspeed = G94 Feedrate / D (same for Y and X axis)
D = a arc_length = R (the current largest Z value) x theta (change in rotation for that line canverted to radians) = G94 Feedrate / D (same for B and C axis).
This produces a more accurate result.
For the most accurate Feedrate speed using G93 on all these axis would be if all are calculated individually.
However if you could mix G93 and G94 in the G-Code, then the only calculation that is required is for the ARC movments as the Linear ones would remain as G94 with its user set feedrate.
Regards,
Mauri.
-
Hi Mauri
I use g93 on our 5 axis Waterjet and it uses it only when the one of the two rotation axis's are being used but the is also x and y movements all on the same line. I will try to remember to post a code for you to review but it may not help you much but I had to do a lot of digging to help Sigmanest get it to work right. Also I do know on my machine with mach3 the arc movements we had to divide the feedrate by the arc radius not sure why but that was the way it worked out
-
RDR,
If you are using Mach3 there should be no issue it does not require G93.
For me it can produce accurate speed changes as the Z axis changes the A axis also changes in speed to maintain the correct surface speed.
You must put .0001 in the Rotation Radius under the Settings Tab on your A/B/C if using 4/5/6 axis.
You must also under "ToolPath Configuration" place a TIC in "User Radius for Feedrate".
I have manually calculated the times and compared then to actual times on Mach3 and they are within a decimals second.
As we do not have this available in Mach4 hence the search for an alternate solution.
Regards,
Mauri.
-
I wish that would work in my case be it would not the radius that we are cutting are always in one part is always different and our rotation is around the z axis and then throw in a tilt of the head that also is in deg's the g93 is the only way for me
-
Attached is two file one has the G93 code that we need to run to make the feed rates right and the other has the normal feed rate. Like I said this may not help you much since it is not a mill code but you need to have the G93 when you do any rotary movements as you can see in the code and in the picture that is attached when it is doing the straight line I do not need the G93 but when it comes to the Arc I do
-
Did some playing around But first what cam are you using? I did some testing on mcam and it looks like it will do a 4th axis feed rate correction and also I posted out a G93 code for you to view see attachment
-
RDR,
On my Mach4 Part3.txt just displays the Toolpath as straight line.
I keenly interested to know how it is showing correctly on your Mach4 and not mine.
Do you have any special Lua Script coding or settings?
Are you using a standard screen set?
Can you send me a copy of machine.ini and your Screen set please so I can get to the bottom of this problem.
Regards,
Mauri.
-
RDR
I use Rhino/madCAM 5 and Aspire 9, but have used others like BobCAD and DeskProto.
Regards,
Mauri.
-
Hi Mauri
sorry the pic can from Mcam I never looked at it in mach at all but that sounds like what it will look like since the mach toolpath window only shows xyz and does not have A axis/or any rotary in the window. I was Just wanting to help with the G93 in this part of this forum topic and to say I use it in our 5 axis waterjet and it works.
I'm sure your cam should be able to post a g93 code in mcam all I had to do is change it in the software setting they had three ways to post feeds on a rotary axis
-
RDR,
For am moment there I was hoping for a Toolpath 4 axis visual solution with Mach4.
From what I have been told it is supposed to show 4 axis displays, but they have not been able to make the 4 Axis Toolpath display correctly in the Toolpath program part of Mach4.
None of my Cam programs can generate the G93 by themselves, however I have someone working on a solution that will convert the G94 G-Code to G93 G-Code accurately.
Thanks for you code.
Regards,
Mauri.
-
It shows 4th axis stuff sometimes but the toolpath is way off.
-
RDR,
Can you provide that CAM picture file so I can use it as a test for G93.
It can be in STL or any Rhino5 format.
Example .3dm - .igs - .iges - .obj - .stp - .step - .wrl - .wml etc.
I will then Use Rhino5/madCAM to produce the G94 G-code and use the test G93 programs to convert it.
Regards,
Mauri.
-
RDR,
Just to let you know BobCAD does support G93, I was using a Mach3 Post and it did not have G93, but other type Posts that work with Mach4 do.
How ever the 4 axis version of BobCAD I have does not support simultaneous axis machining, that is why I use madCAM.
Regards,
Mauri.
-
RDM,
Here is a sample of the BodCAD G93 output.
Regards,
Mauri.
-
Hi Mauri
Attached is a .stp file for you to test with. also I had the feed rate set at 6.4176 IPM for the tool but it will take all the exact settings to make the feed rate match 100% since it is a time factor feed rate if that makes cents to you
-
RDR,
Thanks for the file,
I have also found that some systems use TCP (Tool Centerpoint Control)
It uses G43.4 to activate it (not available in Mach4).
It maintains the X/Y/Z F speed with A/B/C axis.
https://www.youtube.com/watch?v=Gs5EKfL95WU
Regards,
Mauri.
-
Hi Mauri
I did some more playing and I have 3 settings for the rotary see attached pic. I also attached 2 codes I believe that the units/min is what you normally use in mach3 and then let it to the feed rate correction and I also attached the deg/min that may work for you but I'm not sure I think the cam is doing the correction for you instead of the control doing all of the thinking it maybe worth a shot.
-
RDR's first gcode looks plausable... But there seems to be an extra cone and cylinder.
mauri's one looks odd to me - (atleast it doesn't look like the stl...)
-
Hi skunkworks
I'm not sure on Mauri's file. I don't think he had my stp file yet if you look back he posted that before I sent over the file so that maybe something he drawn up
-
Hi,
G-Code file that I used was sent before RDR sent his.
Here is the shape from Rhino as the file in any 3D format is too big for this forum.
I have also provided the G-Code with madCAM.
So as you can see Mach4 cannot display this and even a simple circle in G-Code on the ToolPath display in its true form.
Regards,
Mauri.
-
that looks better
-
https://www.mmsonline.com/columns/programming-feed-rate-in-degrees-per-minute
I Found this site but I am not sure if mach4 hobby can do custom macro B
If so maybe someone can help you with it
-
Hi,
Hobby cannot do custom B but Industrial can.
Craig