I “hacked” a change to my Fusion 360 post-processor, to automatically put a pause after tool change:
M0 (MSG, Wait for Spindle!)
This matches the experience with V-Carve. I see someone else created a version that puts in a delay - I like the manual intervention that this provides. I got tired of hand-editing all the gcode files to put a pause in, so updated the post-processor to do it for me!
There are 2 places in the post-processor where the spindle is started, search for “writeBlock(sOutput.format(spindleSpeed”
Put this line of code in immediately following the line above:
writeBlock(“M0 (MSG, Wait for Spindle)”);
Here’s my modified .cps file. All my changes are marked by a //MDH comment:
onefinity.cps (52.7 KB)
Create a backup first! And please test - this works for me, but your experience may be different.
Thanks Mike - can you do this in the OF interface? I thought there was a section to put in custom code during a tool change?
Regardless, seems like a great feature - how can we get these changes rolled into the official baseline? I now have 4 different CPS files for the OF.
I see the post-processor is in the github repository, I’ll clean this up to work for everyone (with or without spindles) and see if I can get this officially updated.
OK, I submitted a pull request with a consolidated Fusion 360 post-processor that allows both a delay and/or a pause, to be inserted into the g-code. Both options show up in Fusion, allowing end-user control over them.
I’ve not done this before so hopefully I didn’t break anything. The OneFinity admins will need to review and accept my proposed changes.
Here’s the file:
onefinity.cps (51.9 KB)
Please dont take this as a negative feedback.
I’m happy to see that there are contributer like you that get involve and act to get the Onefinity Post Processor Evolve.
That said, I did some review and wanted to give you my though and suggestion
The baseline used to create your revision seem to be ‘$Revision: 43008’.
This is an old revision that do not take in account Autodesk and Buildbotics changes and since onefinity post processor inherits from them this will eventually be a problem.
Autodesk last revison for onefinity is 43242 (but also need adjustment as Onefinity support asked everybody to enable UseCircularInterpolation).
Lack of UseCircularInterpolation property definition (it’s part of last autodesk 43242)
New property ‘spindleDelay’ with default value of 0 second. Good idea. User can ajust if needed only.
New property ‘spindlePause’ with default ‘true’ value. Good idea but the default value should be ‘false’ because this is a specific need that differ from common post processor and also most VFD spindle user will not use it. User can ajust if needed only.
Syntax error found at line 582 (missing ; at the end of writeBlock sentence)
Duplicated block line 583-589 should be removed as they appear where is suppose to at line 698-704. (Edit 2021-04-21 Finally lines mandatory)
Need to update syntax to use the new property definitions implemented by autodesk.
Default value of UseCircularInterpolation set to true in order to enable arc circular movement instead of linear circular movement.
File in your post was not usable on my system because it has unix carriage return.
I did ajust v43242 and apply suggested change.
Here is the file (EDIT 2021-04-30) onefinity_fusion360-v43242B.cps (53.0 KB) (upload://j0eL8LLaVbdVRAKjUh0KMnNtIyQ.cps) (52.8 KB)
Note: The need to use ‘spindleDelay’ and ‘spindlePause’ is less pertinent for HY Huanyand spindle user in particular for those who set PD014 SET 1.5 – DEFINE ACCELATI0N TIME TO 1.5 SECOND (default was 10).
No problem! I’m new to all of this, and glad at least some of what I put together was useful. Not sure how I started with an older version, but I’m glad you were able to get everything pulled together correctly.
I’ve seen recommendations to keep the spindle acceleration time to no shorter than 8 seconds. Personally, I’d rather have this extra step in there than have a race condition on timing of the spindle ramp-up.
Thanks for your help.
This new version works great – thanks for the collaboration!
I’ve been following this post. I’m just getting my machine up and running and was checking for an updated F360 PP. In the library for both OneFinity and Buildbotics, the version # has changed to 43190 for some reason. I checked and there are no code differences other than line 6&7 for $Revision & $Date. Just FYI
Thanks for the info. In fact they seem to have deleted 43194 and 43242 that were publish 2021-03-30 and 2021-04-29. The code stay the same.
After everything had been working perfectly with my OF, I noticed an odd behavior tonight, where the spindle started and the progress bar on the OF web interface showed progress, but the spindle never moved. Upon digging further, I discovered that F360 had released version 43340 of their PP at 5:40pm this evening (see attached screenshot), just minutes before I went to perform a simple cut. Is anyone else having issues with this F360 PP?
I’m using the “community” edition - so I haven’t been affected by this. I did look at the output - the .nc file that contains the G-code - and I didn’t see any material differences in the generated G-code between the community edition, and this current edition. Certainly, nothing that would cause the behavior you described.
Here’s what the beginning of the g-code looks like for me:
(T3 D=0.125 CR=0 - ZMIN=0 - FLAT END MILL)
N10 G90 G94 G17 G91.1
N20 G53 G0 Z0
N25 S16000 M3
The file you generated should look similar to this - obviously a different tool number, and initial spindle speed, but I think the rest is standard.
I can try tomorrow to run a file produced by the new post-processor to see if I can replicate what you saw.
@MikeH, thanks for the reply and this is all on me as I made a rookie mistake. I had injected a new line of code (G4 P10000) to allow my spindle to get up to speed prior to making the first move, and I forgot that the Buildbotics controller has units of seconds, and not milliseconds, on the dwell time parameter. Therefore, the behavior I observed was because I thought the spindle would dwell for 10 seconds, but it was actually trying to pause for 10,000 seconds (i.e., almost 3 hours)
Glad you got it resolved! I put in a message: “M0 (MSG, Wait for Spindle)” as my way of handling this.
The “community edition” post processor above allows you to either put in a delay or a message, as you see fit, and have it automatically placed in the g-code file. No more forgetting to edit the g-code file before running your job!
Well, that settles it, I’ll go install the ‘community’ PP right away. Thanks for the input!
@MikeH, I’ve been using your community edition PP, but I keep running into the same issue with regard to the spindle delay. For some reason, the S4 command doesn’t elicit a pause on my OF to allow the spindle to get up to speed. However, if I change that S4, which was generated by the sOutput command in your PP, the sequence runs just fine. Can you help me understand why this is occurring? I suspect I could change the PP to use a gOutput command instead, but I’ve just been manually editing each gcode file for now.
in the post processor, change “sOutput.format(4)” to “gOutput.format(4)”
I believe this has been corrected in the latest version.
This was fix. Install later
Thanks, I’ve installed the new version and everything is working again. I appreciate the feedback here.
I’ve been hunting down this problem and solution. This is pretty old but looks ideal. Does this have to be updated to work with 1.3 firmware? Thanks!!