Fusion 360 post processing - Coolant

It’s actually not coolant I’m after, but my shop-vac is hooked up so that M7 turns on the shop-vac, and M9 turns it off. Works fine with CNCjs (manually), and in Lightburn, where M7 turns on the air assist and M9 turns it off.

But with Fusion 360, it’s sending an M9 command at the top of the file, and an M7 command at the end. Like WTF?

I’ve attached the gcode file for a simple t-nut hole. Any suggestions appreciated!

1001.gcode (8.9 KB)

Clint

Try this post…

Hmmm… I’ll take a look at that. But I should have specified, I’m using the Guffy1234 post processor for GRBL. And as I said, it’s inserting the right codes (M7 and M9), but it’s got them switched. So it turns OFF the shop-vac before the job starts, and turns it ON at the end of the job.

Clint

From my little experience with post, it looks like in the Guffy1234 M7 will turn on and m0 to turn off
Sorry i may be making this worse for you… :man_shrugging:

I run Marlin version ofGuffy1234’s PP, and I have the following section in the property sheet:

CoolantProperties

Do you have this section in the GRBL version? If so, can you just edit this section to get the right values.

I took it a bit further and looked through DIYCNC_Common.js and DIYCNC_Marlin20.cps, and he may have his logic reverse. These are not languages I’ve spent much time with but in the common file in the setCoolant() function I see he is passing ‘true’ when turning the coolant off:

  writeActivityComment(" >>> Coolant A OFF");
     currentFirmware.coolantA(true);

But in the GRBL file his logic is reversed:

FirmwareGrbl.prototype.coolantA = function (on) {
    writeBlock(mFormat.format(on ? properties.coolantAGrbl : 9));

So I think you can change the last line to get what you want:

writeBlock(mFormat.format(on ? 9 :  properties.coolantAGrbl));

This is assuming you are using coolant A. There is a similar couple of lines for coolant B.

You will have to edit the post processor in notepad++ to match your needs… can you upload your post id like to take a look at it quick… in the mean time, here is your gcode fixed the way you describe it should be…
1001.gcode (8.9 KB)

would @CNeufeld also need to change =function (on) to = function (off) ?

He does not have to but he could. In my opinion, the right fix is to change the logic in the common file so that passes “false” for off, but that would be changing more lines of code. I suggested the smallest change.

1 Like

RobertBU, that worked like a charm. Now I need to track down @guffy and let him know! :slight_smile:

Clint

1 Like

his code is on github. just put in a bug report.

If you’re feeling generous, check out a branch and put in a pull request with the change

2 Likes

The change I suggest, in my opinion, is not the right way for a permeant fix…it was just the simplest change. So I wouldn’t check out a branch.

1 Like

Posting an issue with a good description. Or even the hack fix you made in a pull request is a good start for a SW engineer like Guffy. I’m sure it would be appreciated.

The Guffy PP GitHub doesn’t have issues enabled so you can’t log a problem.

I’ve forked the code and been reworking it. Version 1 is out and available here. I’m working on the next release and have just been through the coolant section and the logic was reversed. Version 1.1, that I hope to release this weekend, has

  • Coolant fixed as well as the coolant parameters reworked so it is easier to use. There was also a typo in the code that caused the JavaScript to crash but that only occurred for one firmware

  • Merged the code back into one .cps file which means you can use F360 install button under Manage->Post Processor to load the PP without errors.

  • Reworked comments so you can select the level of detail and if you want turn them all off.

Version 1 is already available at the link above. If you find an issue log the problems to my GitHub site.

V1 has feedrate scaling, so z stays within limits that mpcnc can handle, and the recovery of G1 rapids that F360 hobby looses.

1 Like

Hello Don, thank you very much for updating the PP. I’ve taken it for a spin and so far it is impressive, especially the reinstated rapids! :smiley:

There is only one thing, and it is not about your PP but rather f360’s handling of cutting operations. I need an M8/M9 in my gcodes for laser cutting to turn on my air blast, and it seems f360 does not do coolant with cutting operations. Therefore I humbly ask… is it possible to “inject” coolant into the PP for cutting?

Also, is there a place to edit the max spindle S value? I’m using default grbl which uses 0-1000, and from the gcode output by your PP it appears the default scaling is set to 0-255. Maybe I need to just change my max rpm in GRBL anyways… Lightburn had the same default of 255 which I changed to 1000. It’s not grbl default, but I digress.

Also, with M4 you don’t need to add M5 until the end (G0 turns the laser off).

When I released Flyfisher604 PP (v1.beta1) I had not yet looked at the laser/cutting code. That doesn’t make the code right or wrong but the PP does what it has historically done.

That said, I’ve done a quick review tonight and there does appear to be issues with what it does now base on what I’ve read.

As reference for Grbl Laser I’m using Grbl v1.1 Laser Mode. Please review and confirm that this is your target and meets your needs.

You are correct the S parameter is being scaled from 0 to 255 for all firmware selections. Grbl does seem to want this to be 0-1000. The good news is this is a relatively easy fix but I may take the opportunity to refactor the laser code at the same time which will increase the work.

With respect to the air blast there is nothing in the PP code to support this currently for a laser operation. That said, that is not an issue and can be changed. How about for lasers I find a way to specify in the laser parameter if it should add a coolant channel (none, A, or B) to the laser operation. This will allow coolant to work for Marlin lasers also. So if you wanted Air you would set Channel A’s coolant to “Grbl M8 (flood)” (which you’ve wired as an Air Blast) and set the laser mode to Grlb with Channel A enabled. This change should be relative straight forward to make - I hope.

I’ve currently working on a v1.beta2 that I’m almost done with. I need to finish that before I start making these changes. Hopefully in the next few weeks I can get these laser changes into a Flyfisher604 PP (v1.beta3) release.

Sneak Peak: Flyfisher604 PP (v1.beta2) allows you to define the ZSafe height as an absolute Z value as in v1 or as the Feed, Retract or Clearance height defined in F360’s tool option. This means that your SafeZ can change with each tool operation and follow what you have defined in the tool as the specific safe height - generally this would be Retract height, but could be lower when set to Feed or all the way up at Clearance.

Hopefully the v1.beta2 is out this weekend and I can look to release a v1.beta3 in a couple of weeks.

Please everyone keep the ideas coming! Lets build a F360 PP that rocks.

1 Like

Don, yes grbl v1.1 laser mode is what I am using, and I believe everyone else uses these days for laser etching. If mpcnc transitions to grbl for esp32 as planned, it will also become an officially supported system our favorite machines as well.

Honestly, you don’t really need to go out of your way to accommodate for 1000. It’s as simple as sending $30=255. A setting for that in the PP is a nice idea, but not a deal breaker by any means.

That is what I was sort of thinking. I don’t really care if the channels are labeled right in the FW as long as M8 turns on my air, hehe. Having a parameter to specify A and/or B with lasers would work for everyone I think (I can figure out A or B in a few seconds). Not even sure there would be much difference between marlin and grbl for this, other than A and B being transposed (again, easy for everyone to sort out either way).

TBH, I’m not 100% sure this will be an issue for me long term. I have only just started playing with f360 for laser work, and like many things about it, but some shortcomings may require me to workaround using the cutting operations as they don’t do stepdowns as well. I run a weak laser; so I need a few passes with stepdown, and that may require working around with a milling operation anyways (where both coolants already work).

Great to hear about the new release! I love how active this community is… this kinda stuff makes me want to get involved. I feel so dumb now, you guys told me about this a while back… but I still cut a bunch of long operations with the stock PP LOL. Granted I was new/nervous about experimenting, but if only I trusted you all more I could have saved myself hours of milling time.

Don, I just had a glance at master… I may be missing something, but it seems fixing the scaling for GRBL is just changing line 81 to var laser_pwm = power * 10; no?

Yes, I just need to ensure it does that only for grbl.

Did a quick fix before I release v1.beta2 tonight to include the fix for the Grbl M3/M4 Laser On speed scaling issue.

This release doesn’t include the coolant changes we discussed or other refactoring work I want to do to the laser code but it does get that bug solved.

Please let me know how it works. I ran 1 test and it looked good so please review and ensure it is what you expected.

The new release is here Flyfisher604 Fusion 360 Post Processor (v1.beta2) available .

The speed (or rather, laser output power) is now scaled properly for me as well, using beta2. I get S800 when I chose 80%. Note that I am also now getting a warning for non-laser operations that my rpm is higher than supported by machine (but that makes sense when I set it to 24000). I haven’t even got a pwm capable router anyways. When I do I will read up and see how others are doing it. My guess is switching back and forth between laser and router I would have to change the max rpm (both FW and PP… no fun), or scale router rpm to 1000 (likely how most are doing it).

I know you said you were still working on coolant, but I went ahead and poked around to see what we have so far… for the purpose of giving you some early feedback/info.

I was able to get both M7 or M8 to turn on either mist or flood separately using beta2. However in my case the mist and air valves are electrically independent. So I need to send both M7 and M8. It looks like F360 refers to this internally as “floodMist”; the stock PP does send both M7 and M8 when floodMist is selected. The beta2 PP appears to have options for mist and flood, but not floodMist which is what I need (and I suspect many others will too). It did throw up a warning in the gcode though, which is really nice.

Not sure the details on coding, but I would be fine if I could just have a place to setup “M7 and M8” for mist, versus actually adding “floodMist”. Whatever is easier for you is fine with me.

On a side note, it looks like the common js file is no longer needed, and you went back to using one file, correct? I wish I was more competent where I could help you develop this… alas I only barely know C and some yaml.