Centroid Z height problem

[Muzzerboy]

Hi Tim

I've used your add-in to post process a roughing toolpath in Fusion for my 3 axis mill running Centroid Acorn.

When I try to load the file, the Centroid s/w does a look ahead check and objects to the Z height at line 1257 "N6205 G43 Z15. H7". However, I can ignore that and start the program(!!) by pressing the cancel button.

In itself, the line doesn't look silly. However, once Centroid has compiled the look ahead, it shows that the lowest Z coordinate is about 4.5m (yes, metres) below Z0, hence the initial objection.

I see there are about 115 replacements of the vertical feed moves in the file, so I'm guessing it's making those moves as incremental moves downward in a cumulative way.

The backplot feature also tries to show the XY plan view and that doesn't seem to end well either. I stopped the program before anything serious happened but I'm guessing there's a similar issue with cumulative moves. Presumably relative vs absolute moves? I'll see if I can understand what's happening here but TBH I'm right on the edge of my capability here, possibly some way beyond it.

Here's the screenshot:

And the original g code - the .nc file suffix has been renamed .jpg so I can upload it here. Change the file ending to .txt or .nc etc so you can open it in the editor:

Let me know if I can provide any further help to figure this out. It's certainly a worthwhile endeavor!

Murray

[TimPaterson]

Yes, the problem is the machine is being put in incremental mode and left there.

At the bottom of the project description is a section called "Compatibility" with a table listing a few post processors. One of the columns in the table is labeled "Tool change". You should copy the text from that column for Centroid and paste it into the "G-code to precede tool change" box in the Post Process All dialog. This uses G90 to change the machine back to absolute mode at the start of each operation. It appears from the G-code you posted that this entry in the dialog is currently blank.

Let me know if this solves the problem. The tool change G-code has not been tested and could need refinement. I would really to know what works so I can keep the compatibility table up-to-date.

[Muzzerboy]

Ah, that one passed me by. I dismissed this because there's no tool change happening. As often as not I post each toolpath into separate files and on this first road test I thought I'd keep it simple anyway. Here I had several operations all using the same tool.

Sounds as if that should do the trick. I'll try it next time I run the machine and let you know.

Might be worth highlighting the need to paste the tool change code regardless of whether tool changes are likely.

[Muzzerboy]

Exactly the same problem even after I've pasted those options into the dialogue box.

Again, rename the file from .jpg to .txt etc:

Perhaps I'm missing something. Let me know what to try!

[TimPaterson]

You're right, it's not using the tool change G-code because the tool doesn't actually change.

When I run the Centroid post processor for a single operation, I get M9 stop coolant near the end. This is used by my program as a signal that it's in the ending sequence, and prevents a subsequent G91 from being emitted. That G91 is causing the problem. I don't see an option to turn off coolant commands, so I'm wondering why your programs don't have it.

The simplest way for you to get going quickly is to manually edit the file. You should remove all lines with G91 on them except at the very beginning and the end (there should be a G90 after each one you keep). Besides putting the machine in the wrong mode, this is also slowing you down by moving back to home before each operation.

If you need to attach any more code files, it's easiest if you just add a ".txt" extension ("file.nc.txt").

[Muzzerboy]

I think I've figured out how to fix the problem. The Centroid post processor ends each job with a G28 G91 Z0, which is a fairly standard Z home move. G28 is a rather confusing command but the G91 relative command within it is persistent until it is cancelled by giving a G90. As it's originally been made at the end of each of the individual constituent files, there wouldn't normally be any need to cancel it. But when the files are joined together by the add-in, the G91 results in every subsequent move being executed as a relative move rather than an absolute coordinate.

I'm not telling you anything you don't know here. But the way to fix the issue is to stop the post processor from generating the G28 G91 Z0 string. Luckily, Centroid doesn't actually need it, as a spindle stop, full retract and program pause is automatically executed by the CNC12 software when it encounters a tool change signified by a "Tx" statement.

I also don't want a spindle retract and program pause in between operations when there's no actual tool change. Finally, at the end of the program, I need a full retract. CNC12 will automatically stop when the file ends, so it seems sensible to do a full retract as the final move. In Centroid, an M25 does that, whereas M30 does not.

I noted that your add-in looks for M30, M5 or M9 to detect the beginning of the "tail" (ending sections of the files). M30 is consistently used in the Centroid post, so I can put code after that if I want it to be added to the end of the combined file.

So in summary, I've got:

• No "tool change" g code (that's the G28 G91 Z0) - leave the dialogue box empty
• Added M25 in my post processor (after the M30 within onClose)

Here's my onClose:
}
function onClose() {
onCommand(COMMAND_COOLANT_OFF);
zOutput.reset();
setWorkPlane(new Vector(0, 0, 0)); // reset working plane
onImpliedCommand(COMMAND_END);
onImpliedCommand(COMMAND_STOP_SPINDLE);
writeBlock(mFormat.format(30)); // stop program, spindle stop, coolant off
writeBlock(mFormat.format(25)); // muzzer - add M25
writeln("%");
}

And an example of what I get:
....
N21560 X141.293 Y-22.114 Z-1.557
N21565 X141.3 Y-22.11 Z-1.4
N21570 G00 Z15.0 (Changed from: "Z15.")

(2207 Drill1)
N21575 T14 M6
(2.1mm drill)
N21580 S4000 M3
etc......
N21630 Z10.
(2208 Drill2)
N21635 T21 M6
(3.3mm drill)
N21640 S4000 M3
etc......
N21680 Z10.
N21685 M30
N21690 M25
%
When CNC12 sees the T21 M6 etc, it pauses, stops the spindle and does a full retract. After changing the tool, you press cycle start and it resumes. At the end, there is a retract due to the M25. The M30 doesn't actually do anything, so has no purpose other than signalling the start of the tail.

The rapids appear to be reinstated but I will continue to test.

[TimPaterson]

The goal is to make this work without needing to modify the post processor, as I wouldn't expect that to be a possibility for most users. I have just released a new version that adds an option to use the move home (G28 or G30) as an additional marker for the end sequence. You can see it ("Move home ends op") in the image of the dialog box. That should allow the unmodified Centroid post to work for you. If you can try it out, let me know so I can mark centroid.cps as "tested". Maybe I need to add a column for the new "Move home" option.

You mention that no code is needed for tool changes. My only concern about that is whether there could be other variations of equipment or software that do not automatically retract on a tool change. I don't think it hurts anything to leave it, but if you're sure it's never necessary, I will remove it from the table.

[Muzzerboy]

Yes, you might consider removal of tool change code a risk but this is a dedicated Centroid post and the tool change behaviour triggered by the T entry is a documented feature. However, if it keeps things simple, a G28 G91 Z0 wouldn't harm anyone as it would simply be redundant. By recognising it as part of the tail, this whole issue would go away and you wouldn't need to introduce the M25 as an alternative fix.

Certainly, avoiding post mods would be the best solution but I was trying to show that a solution is indeed possible - I think that's a yes in the end. I will test the new version and report back (tomorrow hopefully). The G28 G91 Z0 is probably the most appropriate retract sequence for the end of the file, so that sounds like a good outcome.

The remaining issue for Centroid is the repetition of the tool number at each new operation, regardless of whether or not it's different from the current tool. This pauses the machine and requires a manual restart. If you have several operations with only one tool, it results in lots of manual interventions. You might argue the std Fusion post would be better there but in this example I'm perhaps more interested in regaining the rapids than stitching together several tools in one file. Previously, it would run through without requiring intervention. That would be the icing on the cake, restoring full functionality to the Centroid version.

[TimPaterson]

Having a tool command when there's no change in tool is just a bug. My Tormach doesn't stop if the tool is the same, so I didn't notice it. Probably got in there during some reorganization of the code. I'll fix that right away.

[Muzzerboy]

Thanks Tim - that fixed the tool change pause! Now it only generates a tool number when a new tool is required. It also produces the required end of file G28 G91 Z0 line.

I'm having the devil of a job trying to get it to process several ops. They all process fine with the same post processor when used with the std Fusion process. Here's the setup:

This produces this error:

Followed by this one:

I tried increasing the time to 1s / 5 tries but no improvement. Any ideas what to do? Obviously this is preventing me from cutting real air, so I can't confirm it working.

On the upside, I have been able to string simple drill cycles together in a trial setup using different tool numbers and hole positions etc whereas the "real" combination above fails every time, despite Fusion being happy to generate each of the individual toolpaths. I will try to change my simple trial drilling file to include some rapids and see how that works so we can demonstrate the replaced rapids, tool changes etc.

I'm also struggling with controlling which individual toolpaths are run. I am used to creating a different setup for each workpiece within an assembly and also for different orientations of the same workpiece. However, the "process all" operation seems to want to grab and process every possible operation within all of the listed setups, regardless of what I select and even if they are suppressed. Is it possible to control that?

Must admit I haven't quite figured out how the folder numbering scheme works but again, I'm used to creating a long number and name (eg "4100 Main housing") for the setup and a sequence for its operations ("4100 Slot 2D Adaptive", "4101 Drill", "4102 Chamfer" etc). Perhaps this is messing up how the add-in works and it's not how you imagined it to be used.

Finally, it's handy for the final file to open in the default editor (VSC, Brackets, Notepad++ or whatever), so I can see if it looks like a sensible/valid output before trying to load and run it. Is that something you can add?

[TimPaterson]

Post Process All was specifically designed to generate all setups for the entire design at once (long before being modified to deal with the limitations of the free Fusion 360). I had a project with about 60 setups which all needed to be regenerated if a parameter was tweaked in the design. I would have made it possible to do just selected setups, but I could not find any way to learn what is selected through the Fusion 360 API. Since it's going to do them all, you must come to understand the naming convention. Automatically loading them all into an editor isn't usually necessary. Note that operation names aren't relevant, the program works at the setup level.

Anyway, your error message: I was specifically working on improving error reporting, so I don't know how I came up with such a useless message. It was supposed to report which operation it was doing, not the file name. Not that it would lead to a fix, however.

Since you know how to modify a post processor, you should have no trouble learning how to debug a Fusion 360 add-in. It requires Visual Studio Code. There's a quick tutorial (although slightly out of date) at:
https://modthemachine.typepad.com/my_weblog/2019/09/debug-fusion-360-add-ins.html

All we want to do is use a breakpoint to stop execution at line 892 where the call is made to Fusion 360 to post the operation. Then single step ahead a few lines to line 902 where the program opens the file Fusion 360 generated.

I'm giving you this level of detail so you can decide if you're up for it. If you want to give it a try, tell me before you start so I can give you a few tips and explain what we'd be looking for. Maybe even Zoom or something to work together.

[Muzzerboy]

I'll have a look into that. I'm not a s/w guy really and my limited usage has been in the Fortran>Pascal>C>Arduino line with bits of VHDL and a bit of Javascript (Fusion post). Consequently perhaps I can't get Python at all, not even slightly - seems like double Greek to me. That and years of self abuse.

I have VSC already installed, so will see how I get on with that tutorial. Sounds interesting and you never know, I may get somewhere with it.

Where are you / what time zone? I'm in the UK.

[TimPaterson]

The idea is that you won't need to delve into understanding the code. There's a very short distance from Fusion 360 generating the G-code file and PostProcesllAll opening that file to munge it. We want to look at simple stuff like: Which operation failed? Did the file get created (is it visible in file explorer)? Did it take a really long time (> 1 sec)? What we're dealing with is that Fusion 360 reports the operation was completed successfully, yet it's not really done.

When you actually set up debugging, note that the add-in automatically runs when Fusion 360 starts, so you have to stop it first. And the icon for the debugging environment has changed, but it's in the same location. You just click to the left of the line number to set a breakpoint, leaving a red dot. For the first test. a breakpoint at line 910 will be after it failed and you can look at "opHasTool.name" to see which operation it is (just hover over that text on line 895).

I'm in US Pacific Time, 8(?) hours earlier.

[Muzzerboy]

Will be looking into this over the next day or so once the dust has settled and I've got my breath back. Work was getting almost mad towards the end and of course there's all the Xmas stuff to arrange.

We lived in same time zone for 5 years back in the 2010s - Vancouver BC. Miss it like hell, particularly this time of the year with snow on the hills.

[Muzzerboy]

I seem to have it running in debug mode. Luckily the MS team recently renamed "debug" to "run", making it confusing for first time users. I think they do that deliberately.

I ran it until I got this message in the alarming red box:

Exception has occurred: FileNotFoundError
[Errno 2] No such file or directory: 'C:\Users\murra\AppData\Local\Temp/9910.nc'

I don't understand the double slashes but the file 9910.nc exists in that named "Temp" directory and contains:
%
(9910)
(T14 D=2.1 TAPER=118deg - ZMIN=-11. - drill - BT40 ER16 collet chuck with 2.1mm drill)
N10 G90 G94 G17
N15 G21
(2207 Drill1)
N20 T14 M6
(2.1mm drill)
N25 S4000 M3
N30 G54
N40 G0 X126.5 Y-27.628
N45 G43 Z10. H14
N55 Z5.
N60 G98 G83 X126.5 Y-27.628 Z-11. R2. Q3. P0. F40.
N65 G28 G91 Z0.
N70 M30
%
!Error: Failed to post data. See log for details.

Seems to have got a fair way through, as this is the first op using T14. 7 pervious ops seem to have been swallowed ok.

Can I PM or email you if you don't want to clog up your git page? Could Zoom you later this evening if you are available, perhaps midday your time or thereabouts.

[Muzzerboy]

Hmmph. Bizarrely, it's now working flawlessly. I can compile a mixture of toolpaths and tool numbers. Each setup generates a new file (1, 2 etc) and each contains the approved end of file sequence (G28 etc) - and in my case it only has the "T14" etc simple tool change (no G28 etc string required for Fusion).

....
N21535 X141.3 Y-22.11 Z-1.4
N21540 G00 Z15.0 (Changed from: "Z15.")

(2207 Drill1)
N21545 T14 M6
(2.1mm drill)
N21550 S4000 M3
N21555 G54
etc
N21595 G80
N21600 Z10.

(2208 Drill2)
N21605 T21 M6
(3.3mm drill)
N21610 S4000 M3
N21615 G54
etc
N21645 G80
N21650 Z10.
N21655 G28 G91 Z0.
N21660 M30
%

No idea why it would suddenly work although Fusion hung up and had to be forcibly restarted - that's the only change I can see.

At least this will allow me to cut air finally, as long as The Domestic Manager doesn't make an appearance and curtail activities....

-- UPDATE --
I managed to sanity check the content of the 2 generated files, then used ncviewer and CNC12 to check the extents. Looked good so ran my larger file (9 ops, 3 tools) and it behaved impeccably. Rapids have returned and the tool changes, program end etc proceeded correctly. It's hardly a rigorous validation test but it's pretty convincing, running for about 20 mins without issue.

One detail that is missing is the tool change message. Usually CNC12 tells you what tool to change to, based on its own tool table and the tool number from the file. That's getting overlooked now, so will try to understand how it works.

There's also a fancy post processor created by "swissi" (Centroid super user) that supports all sorts of options and messages, as well as in-cycle probing. That doesn't work now, so will take some effort to figure out, possibly something I can fumble about and get some insight into. I get the "unable to open output file error message". In the meantime I am fine to use the original Centroid post.

And of course, the final code doesn't open in an editor. Dunno if that can be easily implemented as an option?

[TimPaterson]

As I understand the current situation, centroid.cps is working well for you now, except its tool change prompt. You have left the tool change entry in the Post Process All dialog blank, and I assume you're checking the new box "Move home ends op".

If you have any files generated by Fusion 360 with tool changes from before it was crippled, you could check if it did anything different.

It seems like we're about ready to close this issue...

[Muzzerboy]

Yes, move home ends op was selected. And no need for anything in the tool change entry, as it would be redundant.

I've surely got a few original files to compare against, so will do so. Also, I will see if I can convince myself I won't see a repetition of the errors but in the meantime, I'll close this issue.

After the last update, Fusion seems to be crashing and sick. I even had 2 instances running simultaneously at one point this morning. Doubt it's anything to do with this.

Thanks for helping to figure this out and for your sterling work getting this add-in working in the first place! Is there a beer fund to help you on your way?