Here is a post processor for the SolidworksCAM extension. This is just a generic 3x Fanuc based post with long code enabled for the canned drilling cycles.
This was made using the Camworks post development tools. Keep in mind that at the moment I don’t have any way to test and debug this so if you have any errors please include a snippet of the section of the G-code that is giving you the trouble and I can make the necessary changes as they’re reported.
After/if Langmuir makes CC recognize canned cycles, this post will still work but we can then update this post to implement their use very easily.
I’m normally a SolidCAM user and I have tons of post editing experience in that platform. Camworks uses a different language and processing scheme than I’m used to so there’s a steep learning curve here for me. If it will help others make using their MR-1 easier I’m happy to do what I can. MR-1 Rev 1.zip (6.2 KB)
I ended up needing to make a number of changes so I used your post as a jumping off point and ended up diving in the deep end and writing one myself. That was a great help!
This is the post processor I have developed for CAMworks and the MR1. It has been working for 2.5 Axis ops, Drilling, Countersink* (see below), and I have compared code between this post and the stock one for 3-axis ops and they are identical but I have not ran it yet.
NOTE: for anyone wishing to use this post processor; it is experimental, use with caution and at your own risk.
When using a spot drilling or other drilling cycle it will not output the dwell P or L values and you get the following error on the machine:
“A G-code command was sent, but is missing some required P or L value words in the line”
Below you can see the highlighted code calling for a dwell time (G04) and then a 5 second dwell (I was using an abnormally long dwell for testing the code to make it easy to track) but for some reason the time is then output as “X5.” instead of “L5” and I cannot figure out why:
The easy, but hacky, solution to this is to just not use dwell time and set it to zero.
The second bug is that when trying to run a tapping cycle the post processor is still outputting the canned G84 cycle and I cannot get it to stop doing that.
As far as I know the G84 tapping cycle doesn’t have a long code variant. It was developed when ridgid tapping became a thing. The MR-1 cant rigid tap anyway so it makes sense that it would error out.
I looked at the source file and I only see the dwell callout in the G82, G88, G89 cycles. Try the G81 and then the G82 and see if the code posts differently. It should, it also looks like it might be as simple as changing the reference in the post callout. It also looks like the default P value is industry standard (in ms), it will need to be changed to output what the MR-1 uses (seconds). Right now a 1 second dwell will post as 1,000 seconds.
I have not had time to address your advice on the dwell time thing yet. I did however discover that G41/42 does not appear to be supported by the MR1, the solution is to just turn this option off when defining your mill ops (its on by default for contour mill ops). The original post seems to not disable this option either, its is just off by default. Is there a way to actually disable this?
I think I’ve resolved the X posting instead of L for the Dwell. Give the attachment a go.
As far as compensation, for the SWCAM the compensation is set in the operation. If the post is set to ignore the CAM settings the code always outputs compensation on (aka use the compensation values stored in the control, which CC doesn’t do (face palm)). The way to prevent the G41/G42 code is to make sure its off in SWCAM.
