/images/combined_setup.png

UPDATE:

Tim added an additional field in his plugin that lets you specify exactly which G-codes are used as end marks. This allowed me to easily remove the M5 command without needing to edit the source code. In addition to this Tims is now detecting whether spaces are present in the generated output files. If spaces are found it retains them, but if they are not found it no longer adds them. This means that Tims plugin now works with the DDCSV with no further actions required.

A great big thank to Tim for his prompt update. Please be sure to go check out his work.

If you have been using my post processor with your DDCSV controller, perhaps with a plasma or even with a generic CNC setup you would know that there’s a bit of manual editing to do to join NC files together. This is due to a limitation in the free ‘Maker’ version of Fusion360 that does not allow you to generate NC programs that contain tool changes. Instead it will generate a seperate NC and Post program for each tool path, which means that you then need to join them together yourself. This soon becomes tedious, especially when you are creating a bunch of plasma jobs that have spot marking.

So just recently, whilst looking for something else I stumbled across Tim Patersons Fusion 360 Batch Post. This is a Fusion 360 Add-In that is essentially a batch post processor that detects tool changes in the generated files and stitches the seperate tool paths together to make one single output file.

The Add-In looks for GCode elements that signify where the tool changes would normally reside, and then splits the code removing the headers and footers from each operation and then stitched each tool-path together before re-adding a header and footer to produce a single file.

Initially the add-In did not work with the code generated by my Post Processor as I had stripped out all code related to tools and tool changes as it was not needed. So I added back in a simple tool number change to the ‘onSection’ function that looks for a change in the active tool and if it finds one adds the TXX tool number GCode commands to the code.

DDCSV11-Plasma.cps

/**********
 * onSection
 *
 *******************/
function onSection() {
  operationCount = operationCount + 1;
  writeComment("Setup #" + operationCount);

  var insertToolCall = isFirstSection() || (tool.number != getPreviousSection().getTool().number);

   if (insertToolCall) {
		writeBlock("T" + toolFormat.format(tool.number)); // (used by Fusion360 'Post Process All' - https://github.com/TimPaterson/Fusion360-Batch-Post)
   }
}

This allowed Tims code to pick up the tool changes in the output generated by the DDCSV11-Plasma post processor, however the final generated output was a little out of the correct order. On further inspection and with a little pointer from Tim I realised that Tim is using the M5 ‘Tool Off’ command to detect when the code is finished with the current tool. In most cases M5 would signify that a tool change is imminent as machines like Mills and Routers generally leave the tool on until it is not not needed, however with machines that use M3/M5 for tool On/Off control like Plasmas, Lasers, Waterjet Cutters, Engravers, Plotters, Drag Knifes etc, this is not the case as the M5 command will be used many times throughout the tool path. So the generated file resulted in some very weird stuff happening.

Fortunately Tim has written his code in a well structured manner and it was a simple change to remove the M5 Tool off command from the command triggers used for tool change detection. I simply removed it from the constEndMcodeSet array.

constEndMcodeSet = {5, 9,30}

I also added the M30 command to the onClose function of the DDCSV11-Plasma Post Processor to be sure that Tims code had a nice easy to find delimiter to mark the end of the operation…

/**********
 * onClose
 *
 *******************/
function onClose() {
  setCoolant(COOLANT_OFF); // turn air off?
  onImpliedCommand(COMMAND_STOP_SPINDLE); 
  writeln("M5"); // turn plasma off
  writeln("M30"); // (used by Fusion360 'Post Process All' - https://github.com/TimPaterson/Fusion360-Batch-Post)
  writeComment("JOB FINISH");
}

I also had to address another small issue to get the generated code to work on the DDCSV. There was a line return added in between the combined code sections which generated a space between the combined operations. On the DDCSV a space in the Gcode results in the operation stopping. So I simply commented out the relevant part in Tims code to remove the generated space from the code.

# Space between operations
   # if not fFirst:
	#    fileBody.write("\n")

This allowed the DDCSV11-Plasma post processor to work with Tims Add-in.

Setting it all up.

If you want to use Tims Add-in with my DDCSV11-Plasma post processor you will need to install Tims add-in into Fusion360. ~~I’ve forked Tims repo and committed the changes outlined above so you do not need to make these changes yourself. All you need to do is follow the instructions described in the ReadMe - https://github.com/DeeEmm/Fusion360-Batch-Post

I’ve also committed the changes to the DDCSV11-Plasma post processor too. So if you have the previous version installed you will need to update it to the current version. - https://github.com/DeeEmm/DDCSV11-Plasma If not just follow the instructions outlined on the repo main page.

Using it

To generate an NC program that combines tool paths into one single output file you need to set up your job a certain way. This is a little different to how I originally described this process in the original post processor post.

The main difference is that instead of creating two setups - one for each tool, you first create the drilling operation and then the cut operation under the same setup

So this…

/images/seperate_setups.png

becomes this…

/images/combined_setup.png

It is important that you edit each tool afterwards to check that the post-processor tool number is the same for all tools. If they are not then you may get some weird Z-height stuff going on as each tool will have a different tool length which is obviously not desirable for a plasma setup. to check / edit this, right click on each operation and choose ‘edit tool’. Then click on the ‘Post Processor’ tab and make sure that the tool number used for each operation is the same.

/images/tool_numbers.png

Now when you call the Fusion360 Batch Post Add-in it will combine both files into one. If you do not combine the operations under a single setup the Add-in will not combine the files and will instead give you two output files - one for each operation.

The result of all of this is that Fusion360 now works like the licensed version, generating a single output file with all tool changes and operations combined into one.

So a big thanks to Tim Paterson for his awesome add-in, he’s definitely saved me from cut-and-paste hell.

I’ve made a request to Tim to see if he will consider updating his plugin to allow user selectable constEndMcodeSet values and operationally removing the space added in the generated output. https://github.com/TimPaterson/Fusion360-Batch-Post/issues/22 But even if he doesn’t then you can still used the updated code on my fork to get it working on your machine.

/DM