Friday 1 February 2019

Recreate Fusion 360 post processor for Newker 990MDc CNC controller

(Re)creating a custom Fusion 360 post processor for the Newker 990 controller:

God nose what happened but I can't find the custom post processor I created for the Chinesium controller when I was last using it on The Shiz. I replaced it with the Centroid Acorn controller, as I had given up hope of being able to understand the inscrutable Chinglish user manual. That work seems to have gone West. Bollocks.

Although the manual was unfathomable in places, the Newker controller's clearly a pretty capable device and it is evidently more versatile than the Acorn in several respects. For instance, it has rigid tapping without requiring a stupid (>1000ppr) encoder resolution and has encoder inputs for each axis, allowing a sort  of closed loop control. I've yet to see how successful those would be to implement but it's certainly good enough for the Blidgeport conversion, which is why I moved it over onto that machine.

The G code library used in the Newker is loosely based on the generic Fanuc set, although there are some features that have not been implemented and some variations on the genuine Fanuc codes themselves. I had to make some changes to the post processor to get the correct g code for The Shiz without having to manually correct the g code in the Brackets g code editor each time. 

The post processor is written in Javascript and although I'm no software heavyweight, I found that with a bit of effort, you can figure out how it works and which parts to change in order to output the g code you require. You can even create your own post processor from scratch if the urge takes you - there is a step-by-step tutorial showing you how to do just that. Each to his own but I'm more interested in making a few changes than reinventing something that works perfectly well as it is.


I first looked into this back in Sept 2017 when using the Newker in anger, although I subsequently made a series of further enhancements. I now need to put all of those together into one definitive post processor, having completely failed to locate the definitive version I was using back then. And this time I should save it for posterity by uploading it as a "cloud post". That way, if I lose my laptop or reinstall (which I think is what actually happened last time), I won't lose a perfectly functional post processor. I blame that fat idiot again.

Editing the post processor:

There was a recent Pootube video intro by the Fusion 360 team that gives a pretty helpful overview of the process. 



And a post by Al Whatmough that gives a bit of background on the concepts.
They recommend using Visual Studio Code for editing the post processor, with a plug-in for Autodesk HSM Javascript which you can install from within VSC itself. I had to restart VSC to get it to run but the benefits are evident and worthwhile.

Learning Javascript and understanding the post processor code:

Since I started messing with the post processor last year, I see that Autodesk has posted(!) a handy guide to everything you would ever need to know about the whole process, including an intro to the editor (VSC), Javascript and "Entry functions" (fnaaaarrrr), which are "the interface between the kernel and the post processor". In other words the stuff that actually generates the g code.

Have a look if you have a few hours spare. I wish this had been available when I needed it. 

Anyway - off we go:

One of the outputs of the generic Fanuc post processor that is provided with Fusion 360 is the "home" move which retracts the tool / quill and moves to the tool change position. 

The standard code in the generic Fanuc post (on which mine is directly based) generates a G28 ahead of tool changes like this:

writeBlock(gFormat.format(28), gAbsIncModal.format(91), "Z" + xyzFormat.format(0));

...which simply outputs "G28 G91 Z0" ie incremental move to machine home with no preceding Z move". G28 isn't recognised in the Newker controller, so something else has to be put in its place to move the spindle to a safe place ahead of tool changes.

I replaced it with this:

writeBlock(gAbsIncModal.format(90), gFormat.format(53), gMotionModal.format(0), "Z0");

...which outputs "G90 G53 Z0"





**** ****

In onClose(), the subsection used to say:

writeBlock(gFormat.format(28), gAbsIncModal.format(91), "X" + xyzFormat.format(0), "Y" + xyzFormat.format(0)); 

...which outputs "G28 G91 X0 Y0" ie return directly to machine X0 Y0.

I replaced it with this:

{
    var homeX;

    if (machineConfiguration.hasHomePositionX()) 

 {

      homeX = "X" + xyzFormat.format(machineConfiguration.getHomePositionX());

    }
    var homeY;
    if (machineConfiguration.hasHomePositionY()) 
 {
      homeY = "Y" + xyzFormat.format(machineConfiguration.getHomePositionY());
    }
 var homeZ;
 {
      homeZ = "Z0";
    }
    writeBlock(gAbsIncModal.format(90), gFormat.format(53), gMotionModal.format(0), homeX, homeY, homeZ);
  }




...which outputs "G90 G53 (homeX), (homeY), (homeZ)", where the 3 values in brackets are defined previously. X and Y can be specified at the time of post processing via the dialogue box. 

Z is hard wired in the post file as zero. I don't expect to need to change this ever. Note that the variable getHomePositionZ doesn't exist in the standard list and I've no idea how to create it, even if that is possible.

This seems to work. There are no G28s in the posted code and I get the return to Z0 at the beginning and end of each operation. 


**** ****

Finally, I found that the post processor mysteriously stopped working, even though I'd not changed anything. Presumably some change in one of the Fusion updates. I had an exchange with Tim Dykes (aka AT Man on Pootube) who knew the answer. I had to make the following change:

The line:

     if (properties.SetHomePosition) {
machineConfiguration.setHomePositionX(HomeX);
machineConfiguration.setHomePositionY(HomeY);
}

Should actually be:

     if (properties.SetHomePosition) {
machineConfiguration.setHomePositionX(properties.HomeX);

machineConfiguration.setHomePositionY(properties.HomeY);

That fixed the issue and I was then able to post g code successfully.

Of course, the Newker controller was last used on The Shiz and is now going to wake up on The Blidgeport, so many of the settings will be wrong, not least the X and Y coordinated for the home position. I'll need to set those up as the default coords when I have the limits / home switches set up.

As you can see, the default home coords are changeable in the post. This was actually how I came to get into a discussion with At Man in the first place. 



Testing the g-code:

I suppose I could simply post some code and see what the machine does. But there are better ways to do it and right now I don't have the machine fully set up yet. All I've done is how that the post is happy to generate code rather than error messages. 

I'll start off by posting a trivial operation and checking what is generated in terms of home moves etc. That'll have to wait for now...

No comments:

Post a Comment

Final assembly and test of the spindle nose adaptor - RESULT!!

After the recent distraction caused by the 3D scanner, resurrecting the 3D printer and buggering about with the throttle bodies for my Honda...