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":
      // move slowly always from clearance not retract
        gFormat.format(65), '"c:/cncm/system/probe_get_modals.cnc"'
        gFormat.format(65), '"c:/cncm/system/probe_bore.cnc"'
        gFormat.format(65), '"c:/cncm/system/probe_update_x.cnc"'

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) {
      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:

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??

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.


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.

Wednesday, 3 July 2019

Bearing retainer plate - CAM and machining

What is it?

This bracket retains the ball bearing at the bottom of the ballscrew. Modelled in a fetching chestnut brown here:

CAM for the bearing retainer bracket:

Found a bit of mystery metal that's about the correct size. Looks like cold rolled steel, about 1/4" thick. Should work nicely.

The CAM seems simple enough. Face off, drill and chamfer the fixings, machine the cavity, then contour the external profile, leaving support tabs which I will remove later. Finally, chamfer the hole and circumference.

This is what it should end up looking like:

Machining the bearing retainer:
The new Korloy APMT1604 PC5300 inserts arrived from China this week, c/o Aliexpress. Yes, they are a massive improvement on the Mitsubishi inserts. It illustrates clearly that there is a critical difference in the geometry, although it's not blindingly obvious at first glance when you compare them side by side. 

Yet again I've caught myself out by being too aggressive with stepdown and feedrate when facing off strip / thin bar. It managed to make a half decent job but squealed like a stuck pig and left a "suboptimal" surface finish. It's not rocket science but seems to be taking me a while to learn this simple lesson. It'll be OK for now.

The other issue which isn't obvious here is that the 8mm cutter slipped when machining the central pocket. The reason for that is fairly simple - the cutter doesn't have the Weldon flat on its shank, yet I insisted on using it in a side holder with grub screw. I've got away with it previously but here I was doing some fast plunges which caused the slippage. It required me to remeasure the tool length offset and repeat the operation (twice!). This is the final re-run, which at last gave the required result for the contour operation. I then had to repeat the operation for the central bore, which you can see didn't quite end up as a through hole.

The other issue highlighted here was that I had a rather aggressive plunge feedrate. And a rather aggressive speed and feed programmed for the cutter. Like 5000rpm, 800mm/min (feed) and 500mm/min (plunge). It was the plunge wot did it. When you add tabs to a 2D contour, the cutter plunges back in after passing the tab. Lucky I didn't bugger the cutter and / or work. And lucky it was a centre cutting end mill.

Here it is, ready for cutting the support tabs. Looks OK - apart from the chatter marks on the surface.

Seems to be as intended.

And yes, the pulley boss clears the central bore.

Some design tweaks and finish machining for the Bridgeport Z axis assembly

What's wrong, Fatty?
Most of the key compts are now pretty much complete. Overall I'm reasonably happy with the design concept and the relative simplicity(?) and ease of manufacture. However, some additional finessing / fettling will be required before I'm happy - and indeed before the parts will go together.

Thrust bearing:
The original design had a deep groove bearing (radial and axial thrust) at each end of the ballscrew. However, that isn't an approved means of supporting a ballscrew, since one end needs to be floating unless you want an indeterminate preload, possibly including zero preload (= backlash territory). Furthermore, there's really no benefit in having a bearing at the top of the ballscrew. I ended up shimming the bottom bearing on the first assembly but that's crap and fiddly.

For the revised scheme, I went with one bearing - at the bottom of the ballscrew. Obviously this needs to be a dual row bearing, so it can take bidirectional axial loads as well as the radial loads from the belt drive. Stupidly, I left the specification(?) of the bearing to The Stupid Fat Bloke. He simply carried over the existing Chinesium "5201" deep groove bearing. 

The 5201 bearing is a 12mm ID / 32mm OD bearing with an O/A length of 16mm. That's way OTT for what I want / need.

The 4201 is very similar (same ID and OD) but is shorter at 14mm. 
I like the look of that better and have ordered some SKF branded examples from Bearingboys

That of course requires some modification to the design of the motor bracket.....

Remachining the motor bracket bearing housing:
So now I have to shorten the length of the bearing bore by ~2mm. However, I machined the bore to a nominal 32mm and although it came out very nicely, The Stupid Fat Bloke didn't bother to actually check if the bearing would fit in the hole. Details, eh. 

The bearing can just about be forced in with the application of a lot of force / blows but that's not the way to do things. I need to machine a few 10s of microns from the bore. I suspect some of the problem is due to slight noncircularity(?).

In fact it's quite easy to create a new setup in Fusion to allow you to go back in and finesse the final dimensions / modify the design - as long as this only involves material removal of course.

In order to be able to drift the bearing out, it makes sense to reduce the diameter of the shoulder, so I'll do this at the same time.

In the new setup, select the final CAD model as the stock, then define a convenient local origin. In my case, I simply picked up the axis of the bore and the internal flat surface of the housing using the Renishaw probe. The operation doesn't look as if it should be removing any material but in fact it works fine. 

Bearing retainer bracket:
Having shortened the length of the bearing by 2mm, I can increase the thickness of the retainer bracket accordingly. It could do with beefing up somewhat and this is an ideal opportunity to do so. That also requires me to be back in and increase the depth of the cavity in the housing that receives the bracket. The process is similar - modify the CAD model, then apparently cut air. In this operation, I went for a 3D Adaptive to rough out the bulk oif the material, then a 2D Contour to provide a nice finish:

Picking up the part origin using the Renishaw is deadly accurate in comparison with the tolerances I actually get from the machining operation itself.

Went nicely. Sorted.

Sunday, 30 June 2019

Compaq Portable keyboard "Retrobrighting" and repairs - it lives and talks again!

Explained in Wikipedia(?)

Disassembly and cleaning / retrobrighting:

Tool for removing the keys, made from shim steel:

All off:

The keys are both grubby and browned off: 

I cleaned these with washing up liquid, then let them sit in 12% hydrogen peroxide with a spoonful of "oxy" washing powder. They were in broad daylight (and heat) on the 2 hottest days of the year here so far. 

Foam and foil replacement:
Now, I have to remove all of the perished "foam and foil" pads: 

Quite a PITA to remove the little disks at the bottom of the opening. I used a scalpel:

A week later, the replacement "foil and foam" pads arrived from the US. Although they only cost $25, I'm paying 2/3 that again in VAT, by the time the UK postal service has helped itself to £8 in "handling fee". At that price. the handling should include a "happy ending". Fuck 'em.

It was a royal PITA getting them seated properly. There are 4 little fingers that you must get the lower disk to click past. I used a scalpel again. 

Quick clean of the PCBA pads with IPA. The pads appear to be electro tinned at best. Not silver (probably a good thing) or nickel.

Almost back together:

Done. Looks a lot better now but not artificially so.

Rebooting with the repaired keyboard:
Yes, I simply reassembled everything and powered it up. It's all very well trying stuff out step by step but in this case, it was simply a matter of the pads being fucked and, as I was pretty certain I'd done a good job of the replacement process, it was bound to work surely?

But does it work? Yes, every key produces what it should on the screen. Phew!

On the Western Digital Filecard 30 (30MB hard disk - whoooaaarrr!), I can see a few familiar programs, such as Norton Utilities:

Lotus 123:

Norton Commander: 

And there's also WordPerfect 5 for what it's worth. Here's what Norton's System Information tells us. I have the full 640k of RAM(!!!!) and am running DOS 3.31

Although the internal Filecard HDD appears to have DOS 5 on it, the machine won't boot from it. I don't recall its history but it appears to have ended up in an Elonex 386 (possibly 486) machine after its initial duties in the original Compaq Portable, judging by the QEMM386 Memory manager entries in the config.sys file. 

Next - try to make the Filecard bootable (, FDISK etc). It's all a bit hazy after all these years but it will come back. I still have the original Norton's DOS guide and Norton Utilities books from back in the 80s / 90s.

I've got some useful support from the retro PC forums

Sunday, 23 June 2019

Finishing operations - Z axis bracket

Counterboring the fixing hole:
Not much point bothering to create a toolpath for this. The hole needs to be bored out 12.5mm to clear the bolt head, so I'll use a handy 1/2" 4 flute end mill. The shoulder is 44mm below the top surface.

I set the origin in the middle of the top of the 10mm hole, then double checked that the bottom hole was at the same X,Y position. The Renishaw probe only just manages it. The reported hole centre was claimed to be within 10um, which is fine by my standards.

Done. The bolt sits just flush within the counterbore:

And I drilled the 3 fixings using Fusion 360 CAM.

Manually tapped the three M6 holes:

And made up three matching bolts to suit the ballnut dimensions:

The slight issue-let is that the holes in the ballscrew are claimed to be 5.5mm diameter ie for M5 clearance. Of course, Fat Boy has committed to using M6 fixings and the holes in the ballnut certainly aren't M6 clearance. The screws I have made up (22mm long) are almost but not quite able to go through. 

Lesson: change to M5 threaded holes (4.3mm tapping?) next time (if there is a next time) and somehow open the 3 ballnut holes out sufficient to get the M6 fixings through on this example. I would use a carbide burr if I had one - or possibly use a carbide end mill. I'll check to see if I have a 1/4" end mill which would be ideal, having a degree of additional clearance over an M6 fixing, then use The Shiz to place them and control the feed carefully.

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 "Centroi...