RepRap: Blog

Well, my initial efforts to build physical things on the next step down on the Feynman Path are proving to be quite frustrating. Turns out hardware is more difficult than software - who knew? Still, no matter, one keeps pressing on.

While the physical side of the project slowly gets its act together I thought I would report on an interesting variation of the “Graphical Stigmergy” technique mentioned in my previous post. This has now manifested itself as Experiment 005.

Basically, this experiment demonstrates an effective method for the 2D filling of an area if you are using inaccurate and imprecise actuators.  I call it Stigmergic Fill and there is a short (8 min) video demonstrating it.

 

Stigmergic Fill lets reality be its own model and, using it, there is no need for a complicated mechanism to build an internal representation of the system state. Things are what they are and, however an inaccuracy or disruption may have happened, the discrepancy between reality and the ideal is immediately obvious and the control software can take steps to address it.

More and more I’m thinking that control at the micro and nano scales will probably be much less of running through a sequence of “go to this exact point and definitively do that” type operations and much more of a general “this needs to be done, activate events which should cause that to happen” and then monitor things to see what actually did happen.

Unavoidable errors and lack of precision at smaller scales will make perfect control impossible to obtain and it is interesting to try and develop compensatory methods in anticipation of that.

I thought it might be a good idea to compare the SVG that I'm using as source for these logo probe etchings with the actual observed output. So I fired up Inkscape and overlaid a microscope image on the SVG. It looks like this:

Now there's a bit of shuffling around which may be speculative, and I have had to distort for a best fit. But there are a number of interesting things going on that give hints to issues with hardware and software:

Yeah, my scaling is stuffed because I had to distort the image. Fair cop. More calibration needed.

There is quite a bit of consistent displacement on the Y axis that does not come out with scaling or distorting. The tip of the logo is too low, and the lowest part of the μ is too high. Backlash, maybe. I suspect a Y-specific hardware fault here,as the problem is not exhibited on the X axis. Mebbe I should swap the X & Y axes and try again? Hmmmm....

Looking at the line around the outside of the logo you will see a number of Control Points used to define the curve. The distortion of the outside of the logo is consistent with the transitions between these points. I strongly suspect I am asking the software to do things it was never expected to do.

Dear Santa, I would like:

My GRBL settings to pretend to be in millimetres but actually be in microns so the GCODE converters don't run into floating point or precision errors.

Proper calibration measurements with simple shapes.

Backlash tests and a hardware overhaul.

My 3D designs for all the things to magically appear on github.

Lots of beer.

P.S. Please give the people who haven't discovered Open Source yet a nice present too, and pat  Rudolph for me.

Two extremes of operation here. One digging in the probe hard enough to tear up a strip of 25μm foil and lift it up off the bed:

Completely accidental, but may be interesting to carve up foil at some point and make circuits? Next one is more interesting technically.

At 3mm/s I redid the 400μm logo with the probe, within errors, 5μm higher than the last etching. Here it barely skims the marker dye layer and is quite hard to see, requiring more creative lighting. Looking at the corners on the μ (if you can make it out) you can see that they are substantially better defined than previous efforts. So, stay slow and don't tunnel the probe into the ground.

Another thing that came out of this: I don't like the look of the curves either side of the point of the teardrop. They should be straight on the diagonal. The straight bits on the μare straight. What's up? Perhaps the GRBL software is doing clever things and has an "allowable margin of error" setting somewhere that becomes more apparent at micron-level movement. Further investigation ongoing...

[EDIT]

$11=0.010 (Junction deviation, millimeters)
$12=0.002 (Arc tolerance, millimeters)

Hmm, that might do it. Let's make that a wee bit finer. Ah, GRBL only takes it down to 0.001mm - fair enough, it'll do for testing. I get to a micron where it matters and I'll be happy.

Couple of important things about this otherwise ordinary-looking logo attempt, scratched with a hypodermic tip on a Sharpie-coated glass slide by Maus. First off, the top one was printed with an X axis speed of 6mm/s and a Y axis speed of 20mm/s. The bottom one with X&Y set to 5mm/s. So there appears to be a speed limit on smoothly driving flexures and that needs investigation. Mind you, the bottom one looks pretty darn good, though the corners are not yet as sharp as those from the OpenFlexure stage.

Second off, these were done by getting the probe height using a Z Touch plate. This was made by sticking aluminium foil to a glass slide. The procedure was to take a clean glass slide and drag lines of a very small amount of 3D printer resin around one end of it in roughly a 25x25mm patch. 25 micron aluminium cooking foil was then placed on the resin. A piece of 80gsm printer paper was laid on that, and rubbed hard with the base of a smooth, thick-walled polyethylene bottle. This created a very flat foil surface, and exuded much of the already small quantity of resin.

Microscope slide, left side coated with aluminium foil. Black mark is Sharpie marker. 0.4mm object engraved at 47mm mark, just below centre line.

The underside of the slide was then exposed over a 4W UV LED to cure the resin film. This foil acts as the Z Touch plate, and when connected to the GRBL board inputs together with the probe wire, the CNCjs Probe Touch function operated normally. The touch plate thickness was set to 25 microns, but this may not necessarily be the true thickness of the foil for many reasons. Repeated touches in the same spot eventually gave CNC readings consistent to +/2 microns though the true error is unknown.

Note: Acceleration of the Z probe is problematic for Z Touch operation. GRBL will only decelerate at the same rate as the maximum acceleration value for that axis. Basically, when the probe touches, it takes a while to slow down. I have set the Z axis acceleration rate to 1mm/s/s and at this rate it does not deform the foil. X & Y are currently set to 0.1mm/s/s as an estimated initial starting value for testing.

 With that new probe I fired up a quick test using the same 400μm logo GCODE file and got this:

Looks like I got the Z probe height a bit wrong, and I could see the tip flexing as it was dragged kicking and screaming across the slide - note vertical slash in the middle where it should have been clear of the bed. I may have scratched a wee divot or two in the middle before I started as well while manually adjusting probe height, but I'll call it a valiant first attempt for Maus.

Must devise a finer manual height adjustment for the Maus stage, but this will matter less if I can get Z Touch working and I'm tempted to go for that.

Might reinforce the probe shaft with a bit of epoxy too, to reduce potential flexing. Currently it's 6mm long, and I think that may be too much.

First of the new probes for the Maus prototype. I use hypodermics initially as they are robust, then make delicate etched ones. The hypodermic needle is crimped on to a piece of tinned 0.25mm wire, which in turn is clamped on by the nut. The needle is held in the plastic body with CA glue.

 

The screw is thus electrically connected to the probe tip. The new Z stage will have a hole this screw goes in, and that'll have the probe connection to the controller board in it. So I won't have to worry about specifically connecting every probe with a dodgy and intermittent wire. Bad news: I need to make a bunch more probes. Such is progress.

Side note: I now have a presentation ready for Everything Open, so in between Xmas stuff I can get back to μRepRap work.

One of the major problems with the Feynman Path approach is minimizing and correcting the unavoidable errors as large tools make smaller tools. One way forward is to simply accept that the machinery will be imprecise and use a closed loop feedback system to help eliminate those errors. Developing such a control system is the reason why most of the work on the FPath Project has so far been software. 

In Experiment 004 the Walnut software was used to demonstrate a path following and error correction behavior using real time object recognition. A rather crude XY stage was used to move a 5mm red circle along a green path. The green path is entirely virtual and is overlaid on the video stream by software. 

The video documentation for Experiment 004 can be found at the link: https://youtu.be/bCb2k8tKX6k 

If you watch the video you will see that cheap DC motors glued to LEGO bricks are used to move the tool head. Why do this? Surely something of higher quality would be better? Well, yes and no. Yes, the quality of the movement could be improved and it certainly would not be hard to find better alternatives to the gear motors currently in use.  But no, I actually want the poor quality movement. The goal here is not to have accuracy handed to me on a plate but rather to get experience taking inaccurate tools and making the resulting output accurate. This is a simulation of what needs to happen when larger machines make smaller machines and there is no realistic way to improve the accuracy of the parent. Errors must be corrected and it is much easier to get some practice at this while still at the macro scale.

Stigmergy is the use of the environment to coordinate actions. If you watch the video you will get a sense of how Graphical Stigmergy could be a useful part of an error correction system.

Hello RepRappers!

You may be interested in the FPath project which is intended to explore the possibilities of the Feynman Path to Nanotechnology. In 1959 the rather well known physicist Richard Feynman gave a talk entitled There's Plenty of Room at the Bottom during which he pretty much invented the idea of nanotechnology and suggested a method of achieving that result. Feynman’s fundamental idea was to use big tools to make small tools which then make even smaller tools and so on until one is able to perform atomically precise fabrication. 

Of course the FPath project is nowhere near the nano scale yet or even at the micron scale that Vik is operating in. FPath is still at the scale of centimeters and working towards building actuators and tools at the millimeter scale. 

There are many issues with the top down approach of the Feynman path. However, there are also problems with the bottom up approach – billions have been spent and we still don’t really have all that much in the way of viable nanotechnology. Maybe the Feynman path is worth a try – after all, it has been given very little attention since the day it was proposed.

Empowering people to create tools would seem to fit right in with the RepRap philosophy and everything is open source.

https://www.OfItselfSo.com/FPath/

The new X & Y stages are moving smoothly enough in 10μm steps. Remember this isn't corrected for arc movement on the flexures, but what it does it is pretty repeatable. I've tested it at ranges of +/-4mm against a 0.1mm grid, and in the photos below against a 0.01mm per fine division grid. Sorry about image quality, but my homebrew test system involves sticking bits of painter's tape on the screen viewing the USB microscope. Painter's tape does not screenshot well. Here's my view at (0,0) and offset by 0.2mm & 0.3mm on both axes simultaneously:

So from this I'm getting 15-ish microns from where I'd expect to be, but like I say this is repeatable rather than linearly accurate. Not getting any indications of backlash above a micron either (a guestimate based on sub-pixel flicker, which is bloody obvious on low refresh rate cheap USB miscroscopes). So if I can map out a grid and apply corrections, and they turn out to be consistent with long term use, then near enough to micron accuracy looks achievable.

This is good. It gives some validation to the performance of the XY table and the long flexure rods used to drive it. With motion ranges of a few mm the X axis position doesn't seem to be affected visibly by the Y axis within margin of error of my microscope. Here's a picture of the current setup:

The connections between the drive stage and the flexure rods are a bit rough. The new driver stages are a different size, in a different location, at a different level, and I haven't had the chance to fix it all up properly. It was thrown together from what was at hand and needs all-round improvement - though didn't wobble at all during testing.

Next up, I'll get working on a Z axis. When I know where that needs to be I'll improve the bracing and fixture locations all round. Then we need a probe and end stops, and we'll be in the same position as we were when the OpenFlexure stage died.

Except this time I can put it all on github under the GPL. This needs to be done in time for Everything Open 2025 on the 25th January, because guess who is doing the first presentation of the conference in Room A after the keynote: https://2025.everythingopen.au/schedule/

I made two black PLA driver stages and they worked fine. I made a white one and it didn't. Hmm, time for science. I made two 100mm beams with a flexure and anchor on one end, and put 20g (OK, two 158 grain .357 lead projectiles, which is close) on the end of each.

Camera lens positioning is tricky here, but the anchors are 38mm above the desk. The black PLA drops to 22mm, and the white PLA only drops to 28mm. My maths is generally suspect, but this indicates to me that the white PLA is significantly stiffer (10mm deflection vs 16mm deflection) and that this is affecting the performance of the flexures in the stage.

For reference, the PLA is the stuff I used to make as Diamond Age using Ingeo 3251D PLA (a relatively low molecular weight). The white is '3DEA Paper White' and I have no idea what they use but I suspect (a) most manufacturers are using higher molecular weights these days, and (b) it is packed with a lot of whitener which will affect the stiffness anyway.

So from here, I make another in black and see if it works, then produce modified flexure designs to match the flexibility with the white and test a stage using those flexures. [Edit: A third black PLA drive stage works fine.]

It may be that I need to include a stiffness test article for people to use to optimise their μRepRaps.

I've been quite busy in the background. I've been through about 5 iterations of the stage, finding out there to reinforce, lengthening arms, changing mount points, testing various drive nuts, changing flexure profiles etc. I've eliminated the vertical flexure in the arm as the drive nut translating left/right has an unexpectedly large impact on stage movement. I've also had to shorten the flexures to 2.5mm reduce twisting. Here's a part of the prototyping debris:

I was getting some curious flex at one point, which counteracted the movement of to top of the stage, making the movement appear uneven. This is because I was supporting too close to the motor, which it turns out needs to free-float. This has lead to a change in mounting. I've increased the mechanical advantage to 3:1, and the range of accurate motion should still be in the +/-2mm area with inaccurate motion possible +/-4mm without breaking anything.

As you can see on the yellow stage at the front, I've the beginnings of a new probe arm coming together which is much lower profile, allowing the USB microscope to get much closer and thus provide better resolution.

The M3 Nylok nuts appear to wear out after a few assembly/disassembly cycles, so I'm back to locknuts on the drive screw. The drive nuts are back to ordinary M3 nuts again rather than sections of brass pillar, which had just too much slack in them. The modules are slowly getting easier to assemble/disassemble, and there are a few spare mount points that can be trimmed off now I know where things are headed.

With the new arm/pivot lengths and new mount points the drive stages don't match the XY table quite so well, so more tinkering required there. The blue Z stage drive won't fit the new probe holder, so that has to change. I'm planning on using the same stage driver for all axes to keep things simple. From the development viewpoint anyway.

The black is a much more optically sound colour, but it is much more difficult to determine what is going on. Unfortunately, I have a lot of black PLA, and the bright colours are being nicked by the family for Xmas decorations, so black it is.

Season's Greetings all.