4 Axis Mach 3 Postprocessor (free but kinda wip)

[brianbonedoc]

Thanks for your work but can you upload the .gpp files as the VMID is just for the machine part of things.


Thanks!

[vakeiros]

sorry about that, here is the pre processor. it's the same for both systems.

best regards

[brianbonedoc]

Thanks!

[jailbreaker]

So I took @bogan's work and tried to adapt it to my homebuilt machine. Rotary along Y, as opposed to his rotary along X.

So here are the results :
- Got 4 axis to work properly
- Got CoordSys Repositioning to work properly for indexial jobs. And yes bogan, I does involve setting up new CSs. Ping me and I can explain in detail.
- Got 5x to work but with the quirk that no matter what I tried, either to tool is on the wrong side of the surface I'm trying to machine or the surface itself gets inverted in z -- gets concave instead of convex. I could use some help with this one... please.

Converting the post to rotary on X is relatively simple and I can provide a version for others to test.
Also, since all of this is happening due to a friend of mine who has the SC license and gets to play (he calls that 'work') with some real machines my time with SC is really limited so please be patient.

GPP file is attached. The screenshot pic is the part that I'm using for my tests.

Finally -- bogan -- THANKS !!!

[jailbreaker]

Ok, so based on bogan's excellent work I tried to 'upgrade' it a bit and use that for my own homebuilt machine.

Current status of the attached gpp file :

- Set up for a 4 axis machine, rotary along the Y, as opposed to the original along X.
- 4 axis operations work, including repositioning (indexial jobs), And bogan, yes - it does require setting up other CoordSyses (CSs). Ping me if interested and I can explain in detail.
- 5x ops do work in the sense that the generated curves and motions are correct. The slight problem that I'm facing, and can use some help with, is that the tool approaches on the wrong side of the face. No matter what I tried it's either this or the toolpaths get inverted -- they become concave instead of convex. So any kind of ideas are welcome.

I can relatively easily make a gpp for rotary along X - if anyone is interested let me know.
Also all of this I made as someone without any idea what he is doing I have a friend who gets to play with a real machine (Hass) and has SC and SW procured and he let me play around...

The attached screenshot is of the part that I'm using for tests. It has a 5x parallel cuts op toopath on it.

Cheers,

[jailbreaker]

Sorry for the double post. Had some issues with my cnczone account, now fixed thanks to Mark

So I played around some more and almost completely rewrote bogan's postproc. I have set up a repo on github here.

Due to video per post limit - here's one :



And links to the others
-


-


-


Attached is a shot of the model that I use for tests.

As a side note -- I find the free HSM Express Gcode editor and backplotter really useful.

Cheers,

[bogan]

I've had a brief look, but I seem to have forgotten a bit about the machine setup as I haven't got it to machine simulation correctly. From memory there are some table offsets or something, jailbreaker can you give us a quick rundown of what you changed and benefits of? I could just compare files between mine/yours to figure out what offsets need changing but if you can remember that'd be even easier. I'm happy to defer to your updates and spend a bit of time testing em on a physical machine if they are better than my first attempt...

[jailbreaker]

Ok, let me see if I can provide a list from the top of my head :

• Cleaned up the post, removed a lot of stuff that I found unnecessary -- block number generation subs (no more calls to @gen_nb), unused .gpp params (like ONLY_XYZ and TEXT iirc). Generates cleaner and less redundant code according to me. At least more readable. Also operation messages are now correctly added to the resulting gcode along with comments and so on.
• Streamlined the vmid, updated parameters of the drill cycles, used english names. Also added trace_level as a parameter so debugging is easier.
• 5x moves - changed your trig math to using @tmatrix -- xtpos, ytpos, ztpos. Found that in the gpptool help.
• For "3 1/2x" indexial moves added A axis repositioning between ops, so that when multiple CSes are at play the generated g-code does rotate the part in between operations. For reference you can take a look at the demo files I have added to the repo here.

Now stuff to note :

• MAC CS needs to be set so that the origin is on the axis of rotation.
• Currently all sub- positions also need to have the same origin. They must have the X oriented in the same way, but Z and Y can point to wherever necessary. This solves indexial repositioning between operations. Like this .
  
  This means that setting your CS like this
  
  will not really work since CS offsets are not taken into account. I.e. the part does get properly rotated but whatever moves are there after are off by the origin offset of the new CS has to MAC. This needs fixing.
• Determining if the part needs rotating between ops turned out to be harder than I thought so now I have hardcoded a retract to tool_z_level always (and that's in abs coords). Most of the time (almost always) this is unneeded and needs fixing

Cheers,

Teo

[bogan]

Sounds good, will run some test machining this weekend.

I've got it doing machine sims as it should now; in vmid file I had to adjust the rotation center in you file (as expected) but the tool station was set to -1 Z direction, so the tool was simulated upside down. Not sure if that is meant to be -1 for some other reason?

What are the trace level parameter options/functions?

cheers
John

[jailbreaker]

No specific "reason" in mind. My understanding is that if Z, pointing up is 1, the tool pointing down should have an opposite vector -- i.e. -1. But since I'm a complete amateur. this assumption may be very wrong ...
The parameter is called trace_level. You will be asked upon gcode generation. Default value of 0 produces no traces in the resultant file. Maximum value is 5 which is full tracing -- calls, parameters, values and so on.

Cheers,

Teo

[bogan]

I think it takes that into account somewhere else already.

I've tried some 3axis with indexial CS and that works great.

Tried some 4x and it didn't work at all. Took some rework of my simulation model and the vmid file to line those up so I was getting proper machine simulations. But the G-Code it spits out is wrong, my first try at the trig re-calc was also wrong (partially due to not having proper sims) which may have put you wrong. Anyway, this is what my 5x stuff now looks like

@move_5x
gcode = 0

; -z -a

zpos_trans = cos(apos)*zpos-sin(apos)*ypos
ypos_trans = cos(apos)*ypos+sin(apos)*zpos
apos_trans = apos

{nb, ['G'gcode], [' X'xpos], [' Y'ypos_trans], [' Z'zpos_trans], [' A'apos_trans], [' F'feed] }
endp

;-------------------

@line_5x
gcode = 1

; -z -a

zpos_trans = cos(apos)*zpos-sin(apos)*ypos
ypos_trans = cos(apos)*ypos+sin(apos)*zpos
apos_trans = apos

{nb, ['G'gcode], [' X'xpos], [' Y'ypos_trans], [' Z'zpos_trans], [' A'apos_trans], [' F'feed] }
endp

I could not find where you got the xtpos etc from so couldn't figure out what was going on there.

[jailbreaker]

xtpos, ytpos and so on come from something SC and gpptool call @tmatrix. Found out about it while tracing the post with trace_level above 1 I think. Then I looked in the help file (C:\Program Files\SolidCAMXXXX\Documentation). They say that these are the values the system pre-computes with "standard" setup, but if one has special requirements one can compute coords himself (like you do).

I found the machine sim to be too fiddly to waste time on, since after all, the ultimate goal is to have mach3 get proper gcode, not just a fancy 3d image of a machine moving. For all I know, if you open a file generated with my post in mach3 it works properly in all operations -- 3x, indexial, 4x and 5x. You can see this in the videos I've posted in the posts above.

But if you let me know what machine are you using for the sim I can try to get this to work too. I can PM you my email to send me the files or you can PM me a location where I can download them from.

I think "not working at all" is the reason I had to have tool_z to be -1. I have had the same problems of paths that look extremely wrong and weird, but in my case they were so in the backplotter and/or mach3.

[bogan]

It might be because my machine coord sys is not on the rotation center of the 4th axis. It was certainly doing much larger 'arcs' around that center than it should have been.

Your post has -180 on the Apos, and mentioned the toolpaths get inverted, you can change direction when you select the faces if that is what you mean. Also, the 5th axis seems to default to locking at 180 quite often.

I'll have another try of some things later today, then see about getting you some files.

[jailbreaker]

BTW, Does your trig. math work with off-center coord syses ?

[bogan]

No, but I'm not sure it should anyway, isn't part of the point of multi coord systems so you can clock it up to different features on the part.

[bogan]

I've got files for you, 25meg though, and I forgot my dropbox password... do you have one I could throw them into?

Test cutting a triple helix in some 25mm plastic round bar. Quite slow, I think the feed speed translation in Mach3 might be assuming it has a larger working radius or something.



EDIT: Might have found the answer to the speed

"You need to enter the rotaion radius on the settings page, in order for Mach3 to calculate the feedrate correctly.

Now, this is not actually the radius that you enter, but the distance from Z zero to the axis of rotation. If you zero your Z axis to the surface of your part, then you will enter the radius.
However, if you set Z zero to the center of rotation, then enter 0.001 for the radius. It should be 0, but entering 0 will disable this feature in older versions of Mach3.

Also, make sure your steps/unit is set up as steps/degree."

from How to speed up rotory axis

It's still doing the job so I don't want to stop it, might try a repeat part with those settings to compare times (it's looking like around 4hr this time, instead of the 1.25 hours SC estimated)

[jailbreaker]

Looking at the picture you posted I see that your A is "pointing" to the left -- in the -X direction. That would explain why you get issues with my post -- it's meant for A pointing in the other direction (+X). Meaning that rotation is also in reverse to your setup.
I've PMed you a link to a dropbox folder, btw.

Cheers,

Teo

[bogan]

Mach3 handles rotation inverse for the A axis I'm pretty sure.

[jailbreaker]

Sure, you can have it spin the axis in the other direction and that's a given.
That breaks the right hand rule, though... Or it doesn't provided you have your setup for that scenario starting from the CAM, then sim, post and finally g-code.

Edit: link to a pic with rhr pic.

[bogan]

Yeh I see what you mean, but everything works well now and I don't really use the A axis number notation enough to get into bad habits I think.