Sunday, 27 October 2019

Chinesium Leeb (rebound) hardness tester

Another mouse accident:

I bought one of these portable Leeb hardness testers from AliExpress. Arrived fairly promptly but of course TNT decided to help themselves to my funds on the way into the UK.

I've had a chance to look at it now. The carry case it comes in is a Chinesium copy of one of those “Pelican” travel cases, although I suspect the water / dust proofing qualities may have been lost along the way. Nonetheless, the stuff inside seems to be reasonable.





Yes, the Leeb hardness scale is actually very simple. It’s just the ratio of the impact and rebound velocities, from which some clever dick materials guys (Leeb and Brandestini) deduced a relationship to hardness. 


As for the method of acquiring the data, “a magnetic impact body permits the velocity to be deduced from the voltage induced by the body as it moves through the measuring coil.” Sounds simple enough – and what you might expect. The energy absorbed in the impact gives an idea of the plastic deformation or relative lack of it. If you prefer a more mainstream hardness scale, the tester simply translates the Leeb Hardness value to Rockwell C etc. 

If you try to measure the hardness of a coin, the surface features seem to prevent correct operation, presumably due to the small size of the test ball embedded in the relatively large moving head getting fouled in the valleys etc of the surface. Similarly, if the body is small (ie not much more massive than the moving test head) and not supported firmly, the reading suffers (suggests a lower hardness than actual) due to the loss of rebound.

Thought I'd have a go at measuring a few items although unfortunately I don't have any reference pieces of known hardness or other hardness measuring tools to cross reference my measurements.

Let's check these out and see if the readings seem remotely plausible, despite the lack of traceable known references. I'll be interested to see how the pukka Korloy toolholder compares to the Indian (Glanze) equivalent. It's my unfortunate experience that crashing the Glanze toolholder results in the tip of the body going plastic in a non reversible way. In contrast the Korloy grooving toolholder (not this actual example) will fracture if you really crash it properly, rather than bend or flow.


So here we are - ~HRC 35 for the Korloy


And ~HRC22 for the Glanze. Sounds about right - piece of shit toffee.



The body of this ISO40 toolholder is as hard as witches tits. Files bounce off it. It's actually the one that came in The Shiz. Sure enough, we see HRC 52.3


This pullstud adaptor (my design) was made by Funwick in China when I worked there. The test report claimed HRC 56 - 60. They have worked fine but oddly enough(!!), I'm seeing HRC 34.8. That's probably not a bad outcome anyway, as I don't want a component like this to be too brittle.


The "hardened" jaws of the Arc Eurotrade vise suggests about HRC 36, which seems reasonable.


The hardened inner race of this HSK bearing reads around HRC 51. According to Schaeffler, bearings are typically in the range HRC 60-65. Seems to be reading low, given that these are almost certainly through hardened ie shouldn't matter where 


Indicated HRC 56 on the table of The Shiz....


I set it to a different scale that is more suited to CI but The Stupid Fat Bloke took this photo and he didn't think to make the display fully readable. The scale indication (HRC, HRB etc) is partially hidden at the top LHS of the photo here.




It's not really suited to measuring carbide but indicated HRC 56 on a 3/4" chamfer mill. It should be more than this but I'm suspecting it doesn't work so well up near the top end of the hardness range.

Conclusion:
Overall, reasonably happy although it's clearly fairly inaccurate. I'd like to be able to get a better calibration using reference samples but that would have to wait until something suitable comes up. In the meantime it looks usable for sanity checking. It'll do for now, being better than what I didn't have before.

Sunday, 29 September 2019

Variables vs arguments for passing data

Passing data between macros:
I've struggled a bit with the issue of passing values when calling macros from within other macros. As there are quite a few levels of nesting in a typical probing operation, it's necessary to pass parameter values when you call one from another.

Some of the higher level macros seem to be perfectly happy to be passed parameters when you make a "command line" type call. In my relatively limited programming experience, these passed values are often called "arguments". In Centroid syntax, this will typically look something like this:

G65 "c:\cncm\probing\f360_probing-x.cnc" X[-8.] Y[20.] Z[50.] M[6.] F[1000.] D[56.] A[1] C[5.] H[3.] R[50.] W[01.]

Once inside the macro, you pick the parameters up and name them locally. From what I can see from existing examples, this requires something like the following:

DEFINE <x> #x
DEFINE <y> #y
DEFINE <z> #z
DEFINE <nominaldiameter> #m
DEFINE <feed> #f
DEFINE <depth> #d
DEFINE <approach> #a
DEFINE <clearance> #c
DEFINE <overtravel> #h
DEFINE <retract> #r
DEFINE <targetwcs> #w 

You can then use the named variables (rather than the short parameters) within expressions, such as this:

G65 "c:\cncm\probing\f360_probe_x.cnc" A[<approach>] C[<clearance> + <overtravel>]

and 

#100 = [#34006 + <approach> * #34009] ; (where did the hit occur)
However, that leaves the question of how to deal with "new" variables, which will either have to be created as named variables ("aliases") or as new (and therefore hopefully unallocated) numbered variables.

Defining aliases:
I tried to create my own new named variables ("aliases") using the DEFINE statement. This appears to be accepted by the interpreter ie it doesn't create any obvious error. However, it fails when I subsequently try to use said new variables in statements or expressions and may or may not be due to me also trying to include an equation in the definition. Needless to say, there is almost no coverage of this feature in the Centroid documentation and very few examples to go on. 

This works:

#100 = [#34006 + <approach> * #34009] ; (where did the hit occur)
But this doesn't:


<expected> = [<x> + <approach> * [<clearance> + <nominaldiameter>/2.0]], whether or not there was a DEFINE at the front, or a "=" sign.

This whole DEFINE / alias business turned into a bit of an unprofitable shit storm and I finally concluded that aliases were not the way to go. I will stick to using numbered variables inside macros.

This macro call works:

G65 "c:\cncm\probing\f360_update_x.cnc" W[<targetwcs>] H[#34006 + <approach> * #34009] E[[<x> + <approach> * [<clearance> + <nominaldiameter>/2.0]]]

Inside the macro, we have:
DEFINE <wcs> #w
DEFINE <hitfound> #h

DEFINE <expected> #e
...
etc
...
#[#34831] = #[#34831] + #h - #e ; updates the WCS value.

Conventionally, local variables are numbered #100-300 if I understand correctly. However, these are local and volatile ie not for passing between macros, with values that evaporate when you leave the current macro. For higher level, more global variables that can be accessed and shared by multiple macros, you'd want to allocate a unique variable number for each new usage. 

Aha - plenty of system variables!!
It's surely no coincidence that Centroid have created a whole slew of unique system variables in the 30000-34999 range. Each appears to have a unique usage - and there are quite a few gaps which I'm guessing I could grab for my own needs. In particular, there is a fine looking gap between 34100 - 34499. I'm planning on making these my own. I reckon 400 variables should be enough for my purposes.

Most of the rest of the system variables which are already defined and in use are in the range 30000 - 34999, with a bizarre addition between 29561 - 29569 which seems to be used by the "wall following" macro. 

Existing system variables:
There's a file called "probe_user_vars.txt" in the Centroid installation that sort of lists the variables currently in use, although most of them have no useful description to speak of. I've now imported that into Excel and am updating it with vaguely useful notes as I figure out what each of them does. Might have been nice if the originators had done so, mind.

The plan:
I will stick with numbered variables between 34100-34499 for my new probing parameters. As I create them, I will add them to the spreadsheet along with descriptions of what they are used for and comments locally within the macro. 

Wednesday, 25 September 2019

Bore probing - getting there...

Bore probing operation:
The Fusion post has now been hacked about to generate a bore probing operation:

  • Move to safe position above axis of bore at the X, Y coordinate position of the axis.
  • Move down to the specified height.
  • Probe both walls in X, stopping at the mid point. 
  • Probe both walls in Y, stopping at the mid point.
  • Save the current position as the corrected X, Y coordinates of the bore in the current WCS. 
In fact, the std Renishaw probing routines that are built in to the Fanuc etc posts have a more elaborate movement than simply plunging into the bore then shuttling back and forth:



(RENISHAW PROBE)
N35 G55
N40 G00 X55. Y20.
N45 G43 Z25. H10
N50 G65 P9832
N55 G65 P9810 Z15. F1000.
N60 G65 P9814 Z-6. D30. Q3. R-3. S1.
N65 G65 P9810 Z25.
N70 G65 P9833

N75 G28 G91 Z0.

As you can see, the fancy moves are clearly contained within the Renishaw macros, not generated by the post processor. The Fusion toolpaths are presumably showing what the Renishaw probing moves look like.

In my case, all I have done is use the existing "bore" macro from Centroid to locate the central axis. That won't be good enough for the "bore with island" move, where the probe must retract to avoid contact with the island. But this seemed like a fairly simple way to get started:

(Renishaw probe)
N35 G55
N45 G0 X55. Y20.
N50 G43 Z30. H10
N60 G65 "c:/cncm/system/probe_get_modals.cnc"
N65 G65 "c:/cncm/system/probe_bore.cnc"
N70 G65 "c:/cncm/system/probe_update_x.cnc"
N75 G80
; N80 X0. Y0. Z30. ; (This is redundant!)
N90 G28 G91 Z0.
N95 M30
%

The program and the macros:
probe_bore.cnc:

; store current WCS x position
#34562 = #5041
; store current WCS y position
#34563 = #5042

; find center of x
G65 "c:/cncm/system/probe_center_inside.cnc" E1
; store width 1
#34560 = #34506

; find center of y
G65 "c:/cncm/system/probe_center_inside.cnc" E2
; store width 2
#34561 = #34506

probe_update_xy.cnc:

#34831 = 2501 + #4014 - 54                   ; x - so 2501 is G54, 2502 is G55 etc
#34832 = 2601 + #4014 - 54                   ; y - so 2601 is G54, 2602 is G55 etc

; Update the current WCS with the difference between initial and final positions
#[#34831] = #[#34831] + #5041 - #34562       ; Update current WCS X variable
#[#34832] = #[#34832] + #5042 - #34563       ; Update current WCS Y variable

The variables:
It took me a while to figure them out. There's nothing particularly special about them but it's easy to confuse "the current WCS coordinate position" with "the coordinates of the current WCS origin" and you have to bear in mind that some of the variables are read only.
#2501     this is the X machine coordinate of the origin of the current WCS
#2601     this is the Y machine coordinate of the origin of the current WCS
#5041     this is the current X coordinate of the tool in the current WCS
#5042     this is the current Y coordinate of the tool in the current WCS
#34562   this was  the X coord of the tool in the current WCS, saved before the last probing move
#34563   this was  the Y coord of the tool in the current WCS, saved before the last probing move
#34831   variable to hold X coord in current WCS system: 2501 means G54, 2502 means G55 etc
#34832   variable to hold Y coord in current WCS system: 2601 means G54, 2602 means G55 etc

So this expression:
#[#34831] = #[#34831] + #5041 - #34562
simply adds the difference between the initial X coordinate and the final X coordinate to the current X coordinate, all in the current WCS. It works for G54, G55 etc. 

The proof:
It works:

Must admit, the approach rapids seem a bit excessive but hey, I got away with it. For safety and simplicity, I set my G40P4 (vise) parking position in the centre of the workpiece. This meant the probe position would be X0 Y0 Z-60. Setting it else where works fine but there's the danger I might forget to zero the axes or somesuch. Although I have several spare probe tips, they are £30 a pop, so best taken care of.


N35 G54
N45 G0 X0. Y0.
N50 G43 Z-60. H10
N60 G65 "c:/cncm/system/probe_get_modals.cnc"
N65 G65 "c:/cncm/system/probe_bore.cnc"
N70 G65 "c:/cncm/system/probe_update_xy.cnc"
N75 G80
; N80 X0. Y0. Z-30.
N90 G28 G91 Z0.
N95 M30

This is the first of the probing operations I have implemented. It's probably the easiest and isn't in a final state by any means. But it's getting there and I'm learning a lot along the way....

Wednesday, 11 September 2019

Fusion 360 probing - first working postlet!

Where are we?
Having got a simple probing macro working (see previous post), the next step is to knife and fork the embryonic "Centroid post with probing" to cause Fusion 360 generate the correct g-code to run some sort of probing event. I managed this - almost - previously, albeit with some manual edits required to weed out troublesome code that the Centroid controller disagreed with. In particular, it generated an M3 (spindle ON) command. Although the set speed was 0rpm for the Renishaw probe, it was right to question (override) the M3 request. I also had problems with the retract height which was somewhat excessively high (60mm). Of course, that's really down to the settings in the CAM that generated the operations rather than the post itself.

So, having managed to butcher the probing_bore.cnc macro to the point of functioning, along with the probing_update_x.cnc to make the results stick, let's try to implement that in my evolving post processor.

Probing post additions / changes to enable the "Bore" probing moves:
I made the following changes / additions to the post code:


    case "probing-xy-circular-hole":
      forceXYZ();
      // move slowly always from clearance not retract
      writeBlock(
        gFormat.format(65), '"c:/cncm/system/probe_get_modals.cnc"'
      );
      writeBlock(
        gFormat.format(65), '"c:/cncm/system/probe_bore.cnc"'
      );
      writeBlock(
        gFormat.format(65), '"c:/cncm/system/probe_update_x.cnc"'
      );
       break;


and this last bit ("if (spindleSpeed != 0)..." etc to prevent outputting M3 when the set speed is 0 (ie probe tool etc):

if (insertToolCall ||
      isFirstSection() ||
      (rpmFormat.areDifferent(spindleSpeed, sOutput.getCurrent())) ||
      (tool.clockwise != getPreviousSection().getTool().clockwise)) {
    // changed spindleSpeed < 1 to "< 0"
        if (spindleSpeed < 0) {
      error(localize("Spindle speed out of range."));
    }
    if (spindleSpeed > 99999) {
      warning(localize("Spindle speed exceeds maximum value."));
    }
    if (spindleSpeed != 0) {
    writeBlock(
      sOutput.format(spindleSpeed), mFormat.format(tool.clockwise ? 3 : 4))
    }
  }

This is what it generates. Looks good to my semi-trained eye.
%
O00010 (Test Fusion probing functions)
(T10  D=6. CR=3. - ZMIN=-6. - probe)
N10 G90 G94 G17
N15 G21
N20 G28 G91 Z0.
N25 G90
(Circ hole)
N30 T10 M6
(Renishaw probe)
N35 G54
N45 G0 X55. Y20.
N50 G43 Z30. H10
N60 G65 "c:/cncm/system/probe_get_modals.cnc"
N65 G65 "c:/cncm/system/probe_bore.cnc"
N70 G65 "c:/cncm/system/probe_update_x.cnc"
N75 G80
N80 X0. Y0. Z30.
N90 G28 G91 Z0.
N95 M30
%

And yes, it works - sort of. The output is still full of my debug messages but the functionality is there. It's only proof of function at this stage and there are a few logical errors, such as line N80 which originally told the machine to go to X55 Y20 again after probing. Having reset the G54 origin to ~X55 Y20 at line N45 before probing, this would end up taking the tool to ~X110 Y40. I need to save the original coordinates somewhere and use those to set the corrected offsets so that the WCS tool position is "X55 Y20" in the current WCS at the end of the sequence. It should be close to the original X55 Y20, with only a slight movement due to the probing correction.

Thursday, 5 September 2019

Fusion 360 probing - updating the current WCS

Updating the current WCS after probing:
I will attempt to get the current WCS updated (corrected) after probing, as a first step. From what I can see, this should be something like:

       #2501 = #5021 - for the x coordinate

       #2601 = #5022 - for the y coordinate

where #2501 is the (read write) current WCS x coordinate (read / write) and #5021 is the (read-only) current x coordinate. 


This seems to work:
It's full of debugging messages, created using the G10 command. Without that I'd have had a royal time of trying to figure out WTF was going on. They can come out later on if I can be bothered.

Here's the macro I've been using in MDI (by typing "M72") to do the probing and updating - it initialises the probing parameters, calls the bore probing macro, then runs the update macro:




It may seem like great progress - and I suppose it's a lot better than what I had a week ago - but I'm still a LONG way off having anything ready to go, even if we overlook the post processor bit (which will need to generate the g code to actually run these probing macros).
  • It doesn't check to see if there is actually a probe fitted, which could be a problem for the probe tip if you start probing with the tool inserted but forgot to plug the probe in. There's a loop back circuit for just that purpose, so that safety function needs to be added.
  • You don't necessarily want to set the WCS origin to the final probe position. In many cases, you want to preserve the existing origin location.
  • ....

Wednesday, 4 September 2019

Centroid post processor for Fusion 360 probing - update

Gnnng, oooph. Yes, this is truning into quite the workout. Figuring this out - and indeed implementing it - requires a lot of work on several fronts:

Javascript:
Various textbook sources for this, such as Peter-Paul Koch on Javascript and A Beginners Guide to Javascript by John Pollock.

Also a video tutorial on Javascript by Mosh Hamedani - "Coding with Mosh" which is pretty good for $15. There's a taster on YT for free, which in itself is useful stuff:

Javascript tends to be used by website designers but it's what Autodesk chose to use for their postprocessors. To be fair, it's not too bad but much of the JS content out there is focused on stuff like CSS and HTML which is of no relevance here.

Post processor development:
As mentioned previously, Visual Studio Code is pretty neat, being more like an IDE than a simple editor, although I've been held back on using this in anger by the need to focus on learning enough Javascript to get by. In the meantime, I've been trying to digest the various Fusion probing posts, so I can get a feel for what is involved. These are the probing posts from Fanuc and the Path Pilot (aka LinuxCNC) post that seems to have been created by David Loomes up in Jockland, the land of my forefathers.

The Fanuc posts make use of special Renishaw probing macros. Obviously these are no use to me, as the Centroid probing system is quite different in operation. Also, the Fanuc Macro B syntax is (naturally) different to Centroid's own macro dielect.

The Path Pilot / LinuxCNC post is written for LinuxCNC, so the macro calls are quite different from both Centroid and Fanuc.

Probing macros structure:
At first thought, you might believe that probing is a pretty simple matter of running the probe into a surface (at controlled speed!) and noting the coordinates where the probe input changes state. But you'd be underestimating the work required. Generally, the work is broken down into a series of common macros that are in turn called by the various top level macros. So there's a sort of hierarchy of macros at play here.
These are the 6 main operations supported by the in-built probing functions within Centroid CNC12:
  • Bore (4 way probing a hole to find the mid point)
  • Boss (4 way probing a boss to find the mid point)
  • Slot (2 way probing a slot to find the mid point)
  • Web (2 way probing a web to find the mid point)
  • Inside corner (2 way probing a corner to find the apex)
  • Axis (1 way probing to find a surface)

I've plotted them out and listed the macros they call in turn. There can be as many as 10 nested macros called by the first. Some are high level macros ("Level 1" in my terminology), which call lower level macros, most are lower level macros and some are both.



They usually require to be passed parameters such as the feedrate, direction of feed, target coordinates etc. And will generally output information in the form of system variables in the range 34000 onwards.

Thus, probe_boss.cnc macro requires parameters for clearance distance and height, feed rates for horizontal and vertical moves, axis number and initial direction (X = clearance dist in X or y; Z = clearance height; E = axis number; D = initial direction; F = traverse rate; B = plunge rate), in the following format:

                probe_boss.cnc X[x]  Z[z] E[e] D[d] F[f] B[b]


It returns the measurements in system variables #34574  =#5041 (current x position); #34575  =#5042 (current y position); #34576  =#5043 (current z position); #34578  =#34562 (width 1 from boss macro); #34579  =#34563 (width 2 from boss macro).

That's all very well, but while I don't want to reinvent the wheel that Centroid has honed over many years, the existing Centroid probing macros don't do exactly what is required by the Fusion probing functions. So what have we got and what do we need to come up with?

Here's the list of Fusion probing moves and the closest available in the Centroid macro ("system") folder:


It actually looks as if most of them are sort of covered. The angle probing may well be doable, judging by the Centroid macros such as probe_angle.cnc but I can come to them later. I seem to recall that Centroid have implemented angular correction in their probing functions.

The main missing feature is the requirement to update the WCS reference point / origin with the probed coordinates. This is where I got a bit misled....

Centroid have their own system variable numbering scheme. In places, it's the same as used in Fanuc Macro B - and in other places it has its own numbering. Here's a link to a listing for the Fanuc variables.

Centroid's table:

As you can see, Fanuc variables #5221 etc are numbered as #2401 etc in Centroid, yet #5021 (MCS) and #5041 (WCS) are the same in both. The #5221 vs #2401 thing threw me for a while. I was getting an "undeclared variable" message when I tried to reference #5221 but hadn't seen the #2401 hiding in plain daylight. Even more confusing is the way the WCS variable numbering differs between Centroid and Fanuc - for instance, x coordinates increment by 1 as the WCS increments from G54 to G55 etc, yet Fanuc correspondingly increments by 100. Similar but different...

The probed value needs to be written back to the WCS variables in order to correct the offset as a result of the probing measurement. As an example, I think this is how you would place the current X WCS number in variable #34831, which I will use to update the current WCS X coordinate offset:

       #34831 = 2501 + #4014 - 54

The X coordinate for WCS G54 is held in variable #2501. For G55, it is held in #2502 and for G56 it's held in #2503 etc. Similarly, the number of the current WCS is held in variable #4014, starting at 54 for G54. So subtracting 54 from that variable gives 0 for G54, 1 for G55 etc etc.

The corresponding expression for the current WCS Y variable number would be:

       #34832 = 2601 + #4014 -54

Of course, Fusion actually increments the WCS before updating the offset when doing in-program probing, leaving the initial WCS offset unchanged. For example, probing in G54 will create a G55 origin where the corrected G54 origin should be. I must figure out how that is handled at some point...

Sunday, 18 August 2019

Fusion 360 post processor - create a post processor for Centroid with probing??

WTF?
This must the the definitive rabbit hole. I've been aiming to attempt a modification to the existing post processor that is provided for use with the Centroid controller. Fusion 360 now implements a fairly comprehensive range of workpiece probing functions for use within a machining operation. The issue is that the existing Centroid post processor doesn't incorporate the required content to handle those features. Most of the main, generic posts have (by definition) a large user base, so one way or another, the effort has been applied to create the required modifications. Centroid on the other hand is more of a minority sport and as far as I can tell, there are no plans afoot to do the required work.

I never expected it to be a simple matter but the more I get into it, the more convoluted the challenge reveals itself to be. Hence the Lewis Carol reference.

The scope:
Here's how I saw the task, around 2 weeks ago, as posted on the Centroid forum:

This may be naive on my part but I'm looking at the possibility of creating a modified post processor to enable Fusion 360 probing. There are several Fanuc-based posts available that support Fusion probing and I have been digging in to the details to understand what I'd need to do to create a Centroid equivalent. Looks to me as if there are several elements to it:

* Replace the basic probe move macros (G38.2, G38.3 etc) with equivalent Centroid macros. Can I simply use M115 and/or M116? Can I access / edit M115 / M116 if they aren't quite right?
* Modify the higher level Fusion probe macros (slot, boss, corner etc) that call them. That sounds less challenging unless I misunderstand. I have been given Fusion-Fanuc versions that implement the required functions.
* Re-reference any called system variables from the Fanuc numbering to the Centroid numbering
* Copy over / modify the post processor probing content into the Centroid post to create a "Centroid with Fusion probing" post.

From my current position (of massive naivety?) it's looking almost achievable. One critical element though is replacing the Fanuc system variables with the equivalent(?) Centroid ones, so they can be called. In Fanuc Custom B, the variables are typically in the 5000 range. From the list of variables in the Centroid probing folder, I see a section at the top named "return values and modals". This looks promising. Could somebody help to confirm / clarify for me what they mean? My questions are in {brackets}.

#34000 ; Probing feedrate {this seems fairly obvious}
#34001 ; Clearing feedrate {is this the retract rate back to the clearance height?}
#34002 ; PLC bits start ;50001 for cnc11 6001 for cnc10 {so Acorn starts at 50001?}
#34003 ; Probe PLC bit variable {indicates the PLC probe input and whether it's NC or NO??}
#34004 ; Probe PLC bit tripped state {the probe input state?}
#34005 ; M115/116 probe input number {eg 7 for INP7? - not sure how M115 differs from the PLC input}
#34006 ; Last X probe point ; also single axis probe return values {at the moment of tripping}
#34007 ; Last Y probe point ; also single axis probe return values
#34008 ; Last Z probe point ; also single axis probe return values
#34009 ; Probe diameter {presumably this is read from the tool table in CNC12?}
#34011 ; comparison tolerance {what is this for?}
#34012 ; Last boundary crossed value (M227) {I can't see any reference to M227 in the manual)

Am I on the right track? Are Centroid about to release a Fusion probing post? Is there any obvious roadblock I'm not seeing?


Finally, are the values for feed and distance in the default metric / imperial units? Questions, questions...

So I started out by printing out the various macros and post processors that seemed to be most relevant to the case i hand:
  • Fanuc generic post (which incorporates probing functions)
  • Tormach / PathPilot (LinuxCNC) post (ditto)
  • Centroid latest post (as discussed, no probing functions at all)
Given that Centroid have recommended the use of Notepad++ for some time now (and continue to do so) - and Autodesk initially recommended it too, I started out using it to edit, print and notate these puzzles. It's certainly better than a std, simple text editor such as Notepad but doesn't come close to the more modern alternatives such as Brackets or (more compellingly) Microsoft's Visual Studio Code, which is both free and available with Fusion-specific support for the Javascript code that the Fusion post is written in.

Post editing options - Visual Studio Code:
The required post processor editing stuff is linked to in the Autodesk HSM website, including the Fusion-specific extension. The easiest way to install the extension (in my view) is via the VSC environment itself, by searching in the extensions marketplace for "HSM" and grabbing the post editor extension from there. On my workshop PC I found I had to go into extensions and enable some of the options for running the loaded post when an intermediate file is loaded.

There's some VSC-related guff here too. For Javascript-specific info, there's a VSC page here.

If you prefer a video overview of VSC and its use here, this is the link.

The vital resource for anyone believing they are about to attempt edits to a post processor is the 180 page Post Processor Training Guide from the HSM team

Editing posts with VSC and the HSM extension:
Once you have set up the JS extension provided by Autodesk, you need to install a dedicated post processor that supports VSC. This generates an "intermediate" file (with a ".CNC" extension) that can be used by the JS editor. 


In VSC, this file appears in the left hand column in the "CNC SELECTOR" panel under the "CUSTOM" area. Alternatively, there is a range of standard intermediate files preloaded there which can be used to test out post processor edits. Along with the active post processor (shown in the middle panel), you can generate g-code output in the right panel (press Ctl-Alt-G). 

This is where things start to get really horny. If you select a line in the g-code, the editor will highlight the line in the post that generated it.


This is a lot smarter than Notepad++. However, there's simply no avoiding the need to digest the Post Processor Training Guide, all 180 pages of it. That'll shut me up for a while. It's almost enough to drive me to working on the bathroom again....

Parametric (re)model for motor housing

What up, Fatty?
So, one or two improvements came to mind last time round. I've been busy building an ensuite bathroom in the house, so had little in the way of serious workshop time. 

A couple of weeks ago I set to on the motor / drive housing (yet again), hopefully for the last time. There's only so much you can bugger about but when you sit back and look at what I've created so far, although it looks pretty nice, when you ask why certain features are the way they are - and more to the point - what purpose they serve, I must admit there are one or two legacy features that complicate the design and its production while adding no obvious functional benefit. That's one of the problems with humans.


Parameterisation(?)

The housing is currently dimensioned to suit the Leadshine closed loop stepper I bought several years ago (iSS57-20). I'm aware that there is no clear standard for the flange and register design, despite all the NEMA etc stuff. So the chances are that most other motors of this approximate size would require different dimensions. I have also be buggering about with different pulley and bearing sizes and belt lengths. So why not use "User Parameters" to control the dimensions in Fusion 360? That way, it should be possible to change some of those variables without having to dive deep into the design history to find where they are defined. Obviously there will be a practical limit on the range of variation possible but nonetheless I should be able to accommodate some.

At this point, The Stupid Fat Bloke got into the CAD seat and predictably got rather carried away, trying to parameterise(?) almost every possible dimension near the thing, based on a single master sketch. Obviously that was never going to work, due to the sheer number of lines and constraints at play. This became evident when it came to creating extrusions etc from the master sketch. And as for the idea of creating offset shapes from chains of segments, forget it! Some happy(?) medium exists between a single master sketch and a whole series of sketch / extrude / sketch / extrude operations.


Here's a "middle way" - a fair degree of parametric dimensions for the core model, which will be extruded and then modified later:




And an initial parameters table:





A bit more buggering about...


...and this is what I've got now. Sort of simpler in many areas.


Top view:


It's mostly parameter driven and has lost quite a few silly (unnecessary) features. I need to finalise the key measurements such as the distance of the ballscrew from the spindle (currently 50mm but almost certainly an imperial 50.8mm?) and the motor dimensions. A couple of features still missing such as a mans of fixing the lid. Otherwise, seems like a reasonable result for now.

I've also reduced the bearing size to a 4200 (30x14x10 double row), which gives me more modesty space between the bearing and the quill, while still having plenty of margin on the max loadings etc. Combined with an 18t driven pulley and a 10t driving (motor) pulley, I've reduced the belt length. This in turn reduces the size of the housing slightly. 

Monday, 5 August 2019

10t pulley arrives - trial assembly

Finally (a couple of weeks ago) the new 10t XL (3/8" toothed belt) pulley arrived from China. This has a large (relative to the actual pulley) diameter boss which features 2 grub screws. This solves the question of how to lock the pulley to the motor without having to resort to Loctite or similar. I wouldn't have a big issue with Loctite apart from the challenge of trying to remove it if the need ever arose. Heat is the answer but that might not be so good for the rotor and bearings, so best avoided.

Here they are. 8mm bore fits the motor shaft and the max diameter is small enough for it to fit through the hole (= slot) in the housing.


So now I can see how well it all goes together. I'm planning on having some adjustment on the radial position of the ballscrew relative to the 16mm hole in the head casting but in the event, I made some of the dimensions close to the nominal and will need to do some finessing before it fits together as I intended.

Pressed the new bearing into position - wasn't too tight a fit and I could alsmost imagine being able to press it out again if required. I'm wishing I'd gone for the sealed version of these bearings, as they are at risk of attracting dust. Obviously I left the procurement to The Stupid Fat Bloke, with predictable consequences.


I can now see (access) the bearing outer race, so it would be possible to turn up a drift if / when I need to remove the bearing later, rather than try to drive it out using the inner race which would most likely bugger the bearing entirely..

The 2 mounting holes have been opened out to 6.8mm. Given that these are for M6 caphead screws, they should never have been 6.0mm to start with. Furthermore, as I plan to allow a fair degree of slop in these fixings for final alignment of the ballscrew, they should end up closer to 7.0 or even 7.5mm diameter.



Now I can trial fit the ballscrew, sleeve and ballscrew retainer nut and see how it plays with the head casting. My design concept would allow for the motor / bracket / ballscrew / bearing / belts to be pre-assembled together, inserted into the head casting and then fastened in place with these 2 machine screws. The aforementioned slop would then allow the assembly to be aligned correctly with the ballnut so that the ballscrew doesn't end up going out of vertical as the quill moves.

Finessing required:

  • Open up the holes for the M6 fixings, as described above. Possibly also the counterbores for the capheads.
  • Reduce the diameter of the ballscrew down to 15mm - up to a height of 15mm above the casting. This will allow some radial slop on the ballscrew within its bore, without which it will be difficult / impossible to insert the ballscrew and its assembly into the head. Obviously I need to avoid compromising the "active" part of the ballscrew where the balls will do their thing but I know I have some margin here. I'll need to do some measurements and sums to figure out what can be achieved safely.
  • Reduce the OD of the ballscrew where it sits within the casting. Until now I've done this by fitting a thin walled sleeve but it would be better simply to reduce the shaft. As well as reducing the part count, it would have the added benefit of allowing a beefier shoulder for the bearing to abut against. The sleeve is only required to support the bearing preload.
  • Provide a (turned) concentric feature at the "top" of the ballscrew. This would be nonfunctional but would be useful when it comes to aligning the ballscrew. There is already an M8 threaded hole for the ballnut keeper at that end.
  • Provide a bit of clearance between the housing and the head casting. Otherwise, we won't be able to take advantage of the slop. Currently it sits right against the vertical face
  • Draw up a drilling jig for placing the two M6 tapped holes in the head. Getting these halfway right is somewhat helpful.
  • Make the ballnut bracket narrower where it pokes through the head casting onto the quill. I have left minimal clearance in my desire to reduce any rotational movement of the quill. I measure about 16.10mm across the bracket feature and closer to 16.00mm across the slot. I'm guessing it's designed to clear a 5/8" feed stop, which would be about 15.87mm or so.
  • Seems pretty clear that the ballscrew is still positioned too far from the quill. That's down to the bracket dimensioning. I'll need to check how the ballscrew / ballnut / yoke line up with the bore of the head casting to see if the yoke is OK or the problem is confined to the housing....
  • Yoke (ballnut bracket) - round off the top to maximise the allowable vertical travel. A square body will stop 8mm from the top of a 16mm slot with rounded ends. In fact the quill stops with the fixing screw centre ~13mm from the top of the slot, which coincides with the top of the bracket reaching the top of the slot. I simply need to round off the bracket feature to a radius of ~8mm.
Should be pretty quick and simple, then.

Chinesium Leeb (rebound) hardness tester

Another mouse accident: I bought one of these  portable Leeb hardness testers  from AliExpress. Arrived fairly promptly but of course TNT ...