[MichaelGolden]

I don't know know how to calculate it but I think I can tell you where to find it., EMC and Mach were created from the open source NIST program. As I recall they downloaded the G code source code and then developed the GUI and software from there to run it. If you code on the EMC forum someone may be nice enough to cut and paste that section for you. Although I have not found them particularly helpful on some matters. Your success may be different that mine. Alternatively, I believe a copy of the G code engine can be found with some searching..
Dan Mauch

I don't think motion control software will have the answer for me. Because the f word in mach or any control software simply interprets the F word as completed time = 1 / the f number.

What I need to know is how the f word is calculated by the post processor from the 3d distance from move a - b, pulled from a cartesian coordinate system. Which is easy with 3 axis but not sure how the rotary motion is integrated.

So I'm going to have the choose the longest distance between rotary and linear moves to determine the fword. Because sometimes cut moves are purely rotary motion with little to no xyz motion.
-The rotary distance along parimeter using radius from zero point. Or the 3d distance of xyz. Unless any mathematicians know a better way to do it.

Does anyone see an issue with this?

[neilw20]

Rotation matrix - Wikipedia, the free encyclopedia

Now apply this in 3d space.
Rotation About an Arbitrary Axis in 3 Dimensions

and become a mathematician.

[MichaelGolden]

Rotation matrix - Wikipedia, the free encyclopedia

Now apply this in 3d space.
Rotation About an Arbitrary Axis in 3 Dimensions

and become a mathematician.

Yeah and whats nice about the maxscript is it does this for you by calling quat "said axis". Or by using the euler angle equations. Which is how the 5 axis gcode is generated within the script. I was hoping for an easy go-too calculation for the 3d distance. Like the linear one I keep seeing popup anytime g93 is mentioned. But have yet to find anything useful on the rotary axis.

I thought about it some more during the day at work. And choosing the longest distance would not work because then your feedrate would be too slow during simultaneous linear and rotary motions. So that must mean the total distance must be equal to the sum of all distances in each dimensional plane.

Total Distance = SQRT ( distanceX^2 + distanceY^2 + distanceZ^2 + distanceA^2 + distanceC^2 )

But to know the distances of A and B using the euler angles to find the actual radius would be a must. And the x y z are absolute so would stay the same.

Cross your fingers

[MichaelGolden]

Sooo. Here is 1.07.

I watched the youtube videos with the twitchy movements in the file 02AltParallelSpline posted on the yahoo forums. I checked the gcode line by line and determined there is no problem with the gcode. Its just an issue with the simulation. Something to do with the rotation when 180 degrees. I tested the gcode on the actual machine to confirm this.


This update includes an option for G93 in the post under "standard G-code"

I tested it in mach3. Seems to work. This was a real pain in the butt. So enjoy.
And if anyone has experience with G93 please say so and if there's an issue we can tweak it.

The real cool part about this is you can import gcode from another cam software to form splines in gmax and re-generate the gcode with G93 added to it. You would need to re-do all the 5 axis toolpath vectors if you were using A and C. But I think the next update would be cool if we could add the fword to the existing code without changing it.

I also added a tick box for adding line counters to the code. I found it a real pain to check the code in notepad without any kind of reference.

[MichaelGolden]

Trunnion Mk3 is on the way

[TOTALLYRC]

Looks good Mike.
Since the trunnion code seems to be working it looks like I will have to move my trunnion table build farther up the list of things to do.
Keep up the great work.

Mike

[yohudi]

Sooo. Here is 1.07.


This update includes an option for G93 in the post under "standard G-code"

I tested it in mach3. Seems to work. This was a real pain in the butt. So enjoy.
And if anyone has experience with G93 please say so and if there's an issue we can tweak it.

.

Hi There,

Rab has mentioned to me that he did look at g93 in the past.... this is what he said...

"
I looked into that ( G93 Inverse Time Feedrate) many years ago and it didn't seem to work very well in Mach at the time......... However, Art implemented my suggestions on rotary move feedrates into the Mach code which for me worked well enough that I left it at that....... "

Is anyone aware that anything has changed in respect to the way mach handles g93.... Is it not more useful to stick with the existing setup.. bearing in mind that it implements Rab's rotary feedrate advice anyway ??

Will be looking at this in the immediate future.. which is why I'm asking

TTFN

Danny

[dmauch]

Thanks, Michael for implementing it.
Dan

Sooo. Here is 1.07.

I watched the youtube videos with the twitchy movements in the file 02AltParallelSpline posted on the yahoo forums. I checked the gcode line by line and determined there is no problem with the gcode. Its just an issue with the simulation. Something to do with the rotation when 180 degrees. I tested the gcode on the actual machine to confirm this.


This update includes an option for G93 in the post under "standard G-code"

I tested it in mach3. Seems to work. This was a real pain in the butt. So enjoy.
And if anyone has experience with G93 please say so and if there's an issue we can tweak it.

The real cool part about this is you can import gcode from another cam software to form splines in gmax and re-generate the gcode with G93 added to it. You would need to re-do all the 5 axis toolpath vectors if you were using A and C. But I think the next update would be cool if we could add the fword to the existing code without changing it.

I also added a tick box for adding line counters to the code. I found it a real pain to check the code in notepad without any kind of reference.

[MichaelGolden]

Hi There,

Rab has mentioned to me that he did look at g93 in the past.... this is what he said...

"
I looked into that ( G93 Inverse Time Feedrate) many years ago and it didn't seem to work very well in Mach at the time......... However, Art implemented my suggestions on rotary move feedrates into the Mach code which for me worked well enough that I left it at that....... "

Is anyone aware that anything has changed in respect to the way mach handles g93.... Is it not more useful to stick with the existing setup.. bearing in mind that it implements Rab's rotary feedrate advice anyway ??

Will be looking at this in the immediate future.. which is why I'm asking

TTFN

Danny

Yes the rotary move feedrates work. I'm aware the change in z axis height can set the radius for the a axis around zero but is there support for simultaneous changes in C axis rotation?

The travel speed across the part changes with every move in xy and z position on the trunnion type setup.

I set the rotation diameters as close as I thought the toolpath would be. But this has to be measured/set for every different part. (Effected by size of stock/fixture) And because of this I would prefer to work with G93 and only worry about my feedrates.


Now I noticed mach 3 has at least one issue running G93 and I'm not sure if it's the gcode or mach3. I haven't looked into it yet.
I ran a simple test and 20 lines in the c axis had to move by about 30 degrees and everything halted to a crawl. The feedrate lowered by about 100 times what it should have been. But the very next line everything went back to normal. I wouldn't mind having to edit a few lines of code by hand but I'm sure there must be a simple fix.

[billw999]

Hi There,

Rab has mentioned to me that he did look at g93 in the past.... this is what he said...

"
I looked into that ( G93 Inverse Time Feedrate) many years ago and it didn't seem to work very well in Mach at the time......... However, Art implemented my suggestions on rotary move feedrates into the Mach code which for me worked well enough that I left it at that....... "

Is anyone aware that anything has changed in respect to the way mach handles g93.... Is it not more useful to stick with the existing setup.. bearing in mind that it implements Rab's rotary feedrate advice anyway ??

Will be looking at this in the immediate future.. which is why I'm asking

TTFN

Danny

Hi yohudi,

I have run many gcode files containing g93, that were generated with commercial software, and never had a problem with Mach3 handling them.

When I first got into 5 axis machining the first problem I ran into was the fact that the rotary axis would run to slow when using F words that

I had been using for three axis toolpaths. As far as I am concerned this is the first problem to overcome and if you want an efficient toolpath

no other work around will do, g93 is a must. Making efficient 5 axis toolpaths is way more involved than I could have ever envisioned and the last

thing I want to worry about is linear verses the rotary feedrate problem. This is a link showing mach3 running gcode with g93 in it.

https://www.youtube.com/watch?v=gDFbsYNMdE0

[billw999]

Sooo. Here is 1.07.

I watched the youtube videos with the twitchy movements in the file 02AltParallelSpline posted on the yahoo forums. I checked the gcode line by line and determined there is no problem with the gcode. Its just an issue with the simulation. Something to do with the rotation when 180 degrees. I tested the gcode on the actual machine to confirm this.


This update includes an option for G93 in the post under "standard G-code"

I tested it in mach3. Seems to work. This was a real pain in the butt. So enjoy.
And if anyone has experience with G93 please say so and if there's an issue we can tweak it.

The real cool part about this is you can import gcode from another cam software to form splines in gmax and re-generate the gcode with G93 added to it. You would need to re-do all the 5 axis toolpath vectors if you were using A and C. But I think the next update would be cool if we could add the fword to the existing code without changing it.

I also added a tick box for adding line counters to the code. I found it a real pain to check the code in notepad without any kind of reference.

Hi Michael,

First let me say that I think it is really cool that you are making the cnctoolkit usable for people with a trunnion instead of the head head configuration.

I have been testing all of your script mods but only with the built in parallel and spiral splines as I can't seem to make importing splines work.

I have read the pdf on using gmax and cnctoolkit but when I try to project the imported splines onto the surface they fall right though, if anyone

could enlighten me I would be very grateful and be able to test these new scripts in more depth.

[yohudi]

Hi There,

My concerns with g93.. and if I should implement trunnion 1.07.. or a previous version...relate to what will be the most generally usable output... without issues like glitching.. or need to edit code and so forth.

So Micheal's remarks re: his problems with it did cause concern.

Having resolved the issues with the other pathing configurations.. the last thing I want to do in a more general implementation is introduce something else to fix.. unless the feature is an absolutely pressing requirement....

I do realise that trunnion is the focus here.... but my own perspective looks to set up trunnion alongside other configurations..... so that all options are available.... I have a little time yet.. so I will jkeep an eye to progress.. before coming to a final decision....

Re: you spline projection issue.... this sounds like a face normal problem.. i.e the faces are flipped.. but without sight of the file / mesh target this is best guess rather than definite answer..

TTFN

Danny

[MichaelGolden]

I -think- whats happening is the a and c degrees are being viewed as inches per minute in mach.

N20 X0.0048 Y0.5169 Z3.9209 A-9.1574 C151.432 F983.175
N21 X0.0047 Y0.5161 Z3.921 A-9.1444 C203.631 F1000.0 <-- this was the problem line

the C move being 52.199 degrees is the largest move on line 21. And im assuming mach is completing this move in the way it does with inches per minute. But it should be degrees per minute.

I'll see if I can look at the mach3 code tonight after work to find out what its actually doing. But if I knew the exact way it was handling the moves. It shouldn't be a big deal adding an expression to the toolkit to change the fword to match mach3 control.
Although, a new post processor option would need to be put in place because it would no longer be "standard gcode" and only work for mach3 specifically. As far as we know.

[mcphill]

I have a totally "different" question for you guys with respect to CAM vs Machine Control... And totally different packages, so excuse the "focus" not being on the CNCToolkit, but it sounds like you may be able to answer my question? I currently have MACH and use BobCAD for CAM. I am planning a new machine, and will use FlashCut for the machine control, and want to stick with BobCAD for the CAM. FlashCut "supports" 4th and 5th axis only as a trunnion, but I want to do a machine head configuration. What I don't know is "do I care"? Doesn't the CAM take care of tool centers, etc? I know I have to set up the machine configuration in BobCAD, so that the code is generated with the proper axes of motion. I understand Mach can handle "any" configuration, but FlashCut seems to not know for sure if their "trunnion safe" machine control will work with GCode written for "column based" axes. I can't do trunnion as I am making a HUGE work area (over a cubic yard) and that would require too much space being taken up with a trunnion...

I have posted this question in the General CAM question area, and have no responses, so again, I apologize for the "off target" co-opting of the thread, but it seems the right expertise to address my question is here. If you would rather reply to my original post rather than here, I would love that! Here is a link to that post: http://www.cnczone.com/forums/genera...-software.html

[dmauch]

What version of Bobcad are you using? AFAIK Bobcad wants $15,000 for their 5 axis CAM program. So I doubt that you would be able to generate G code for the flashcut. I'm not sure why flashcut wouldn't work with a head mounted 4th/5th axis as the criteria for it work is generated by the CAM program. In the Cam program you designate the configurations of your 4/5th axis. Yes the CAM program should allow you to set up your offsets. Yes Mach 3 doesn't care which machine configuration you have as long as the machine's paramenters are set correctly. The reason flashcut doesn't know if their controller will work with a head mounted is because they haven't used it for such. It should work as long as the G code is compatible with the flashcut G code.

Dan

I have a totally "different" question for you guys with respect to CAM vs Machine Control... And totally different packages, so excuse the "focus" not being on the CNCToolkit, but it sounds like you may be able to answer my question? I currently have MACH and use BobCAD for CAM. I am planning a new machine, and will use FlashCut for the machine control, and want to stick with BobCAD for the CAM. FlashCut "supports" 4th and 5th axis only as a trunnion, but I want to do a machine head configuration. What I don't know is "do I care"? Doesn't the CAM take care of tool centers, etc? I know I have to set up the machine configuration in BobCAD, so that the code is generated with the proper axes of motion. I understand Mach can handle "any" configuration, but FlashCut seems to not know for sure if their "trunnion safe" machine control will work with GCode written for "column based" axes. I can't do trunnion as I am making a HUGE work area (over a cubic yard) and that would require too much space being taken up with a trunnion...

I have posted this question in the General CAM question area, and have no responses, so again, I apologize for the "off target" co-opting of the thread, but it seems the right expertise to address my question is here. If you would rather reply to my original post rather than here, I would love that! Here is a link to that post: http://www.cnczone.com/forums/genera...-software.html

[dmauch]

You don't have to assume that Mach3 is reading that line of code's feed rate as inches/MM per minute. It is but that is where G93 would control the AC axis in degrees per minute

I -think- whats happening is the a and c degrees are being viewed as inches per minute in mach.

I ran into the same problem with a gear that I was machining on a 4th axis with G code written by Gearotic Motion Software. Bill999 told me that I need to use G93 and when I edited the software it fixed the problem. But you need G94 to turn off the feed in degrees back to IPM/MM .

I think that the G93/G94 would work with any controller that implements those G codes. EMC uses them. I would bet that all of the big machines controllers like Haas, Fanuc, Galil and other use it. I just checked and Flashcut also supports it.

Dan

N20 X0.0048 Y0.5169 Z3.9209 A-9.1574 C151.432 F983.175
N21 X0.0047 Y0.5161 Z3.921 A-9.1444 C203.631 F1000.0 <-- this was the problem line

the C move being 52.199 degrees is the largest move on line 21. And im assuming mach is completing this move in the way it does with inches per minute. But it should be degrees per minute.

I'll see if I can look at the mach3 code tonight after work to find out what its actually doing. But if I knew the exact way it was handling the moves. It shouldn't be a big deal adding an expression to the toolkit to change the fword to match mach3 control.
Although, a new post processor option would need to be put in place because it would no longer be "standard gcode" and only work for mach3 specifically. As far as we know.

[yohudi]

Although, a new post processor option would need to be put in place because it would no longer be "standard gcode" and only work for mach3 specifically. As far as we know.

Hi there,

If you leave the option to toggle g93 active or inactive... then the existing post-processor should be ok... that's the fastest and least disruptive approach... I think that's what I'll be doing anyway...

This allows user action..... such as selecting trunnion... to activate g93 in the post... with other options.. such as head / head XYZAC de-activating it in the post....

keep it simple... wherever possible... is the best approach I've found....

TTFN

Danny

[mcphill]

What version of Bobcad are you using? AFAIK Bobcad wants $15,000

I have had BobCAD since V23, and have active licenses for V23, V26 and V27. I have 5-axis for V26 and V27. $15k is the list price, you NEVER have to pay list price at BBCD... Just wait around or negotiate and you can get a significant discount. I bought V26 when I knew V27 was coming, so they were offering a significant discount. I also added support, which comes with a 1-year software upgrade. So V27 came out in the 1 year and I got the upgrade for free. It was about $6k if I remember correctly, but I had them give me 2 seats at that price (that is another trick, once done negotiating on price, say I'll take it if you give me 2 seats).

So, it was VERY spendy compared to CNCToolkit, but I tried Tookit a few times and never wrapped my head around it. It was also WAY cheaper than alternative options (though I did have an avenue to get SprutCAM from Tormach with 5-axis for a little less, I believe, but that would have been another learning curve for me. I also used that info in the negotiation to have BBCD come down to my costs for SprutCAM). I have been planning a 5-axis machine for literally years, and thought I was very close when I bought the 5-axis CAM, but the real world picked up and I haven't completed the build yet. In any case, I do have the CAM now, and I want to make sure I don't mess up in the control system...

I had thought that FlashCut should "not care" as the toolpaths are generated by the CAM, so your confirmation that is good to hear. I hope to have my whole system up and running by the end of this year, now. I have 80% of the parts on hand, and am on about version 6 of SW files for how to design it. I am shifting over to an Epoxy Granite build now, where I was considering cinder blocks and steel I-beams. EG will be much more solid, though a bit more expensive, but I will also make it "dis-assemblable" so if it comes to it, it can move if I do (the version I had been thinking about would basically not be able to be broken down and moved, except for the drive components...).

In any case, thanks for the reply!

[dmauch]

I emailed Mach3 Art.
Dan:

As I recall, it was some time after Rab’s fix was done that G93 was implemented..afaik it was implemented well and works fine in m3.


Art

I -think- whats happening is the a and c degrees are being viewed as inches per minute in mach.

N20 X0.0048 Y0.5169 Z3.9209 A-9.1574 C151.432 F983.175
N21 X0.0047 Y0.5161 Z3.921 A-9.1444 C203.631 F1000.0 <-- this was the problem line

the C move being 52.199 degrees is the largest move on line 21. And im assuming mach is completing this move in the way it does with inches per minute. But it should be degrees per minute.

I'll see if I can look at the mach3 code tonight after work to find out what its actually doing. But if I knew the exact way it was handling the moves. It shouldn't be a big deal adding an expression to the toolkit to change the fword to match mach3 control.
Although, a new post processor option would need to be put in place because it would no longer be "standard gcode" and only work for mach3 specifically. As far as we know.

[MichaelGolden]

I emailed Mach3 Art.
Dan:

As I recall, it was some time after Rab’s fix was done that G93 was implemented..afaik it was implemented well and works fine in m3.


Art

I tried again with different feedrates. I also tried changing the g code to see the effect. It doesn't matter if the c axis is a 52 degree or 5 degree move. The feedrate drops to .02 ish and the machine barely moves.

I changed the xyz. If I change any one of these by even .1 the feedrate jumps back up to normal.
If I run only the c axis alone without xyza. The feedrate reads as it should.

The math.
degree move / desired degree per minute = time in minutes
52.199 / 1800 = 0.028999444

1 minute / time in minutes to complete move = Fword
1 / .028999444 = F34.4834192754

I try this Fword and Mach reads the appropriate value in units per minute with only rotary axis moving.

Once the xyz mixed motion gets introduced everything gets messed up.

Unfortunately I don't know what file in mach or programming language it's written in to take a peak.

Maybe I'm using an old version. I was planning to upgrade to mach4 soon anyway.