The task: To regularise bamboo poles so that they may be used in mobility aids for a charity (www.kyaningacdc.org) in Uganda. The bamboo is anywhere from 35-45 mm diameter and not concentric.
The idea: Print collars directly onto the bamboo so that they provide positional accuracy.
The solution: Build a 3D printer with the Y-axis being rotational and probe the surface for a map driven print head.
I installed the Mk2 prototype in Uganda in January and I am now working on Mk3.
Being new to the subject, I designed the frame using 20x40 v channel (now 40x40) extrusion, NEMA17 stepper motors and the Arduino/RAMPS1.4/Marlin electronics combination.
The X direction is 1500mm and the Y is 360mm (360 degrees really) and the Z direction 60mm.
The testing the collars need to be 20mm long and a final diameter of 50mm.
I probed on a 10mmx5mm grid using home grown probe and new Gcodes.
In testing lumps and bumps on the bamboo meant that the probing has to be on a smaller grid. I reworked to software, changed the probe to a digital dial gauge (I added an Arduino nano to preprocess the interface and communicated via I2C to the main board) but ran out of memory. I explored adding more memory or using the SD card as external memory.
Standard bed levelling cannot be used as I have to calculate spacing as the printing takes place at different diameters and hence different surface areas.
I put out a plea for help on memory on another forum and @dc42 suggested I junked the 8bit processor and used a 32bit board. (He did mention his interest). When you have invested a lot of time down one route it is very difficult to change tack - but I did it, I ordered a couple of Maestros and saw the IR probe so got a couple of those as well (I had started to look at non-contact probes and had a couple of Sharp detectors on order).
So now with the wiring loom re-crimped, a new housing printed, I start configuring it.
Why did I not see this board and the RepRap version of software earlier! Wow - All the configuration in external files.
It is all up and running with all motion and homing working OK (no homing on Y direction Z&U homing on Z).
Then to the probe - oh dear! only a maximum of 441 plots supported - I dived into the code and saw the memory limit calculations. (I had moved to 32 bit to overcome memory limitations)
As the head moves mainly in the X direction and just steps round the Y direction at the end of each line, all the interpretive calculations are not needed so could save space here but like with the Marlin version, I would be stepping into code changes.
I started to look at probing smaller sections and offloading these to an external processor to calculate Gcodes and to feed them back to the Duet.
This morning whilst exploring macros, I came across the idea of condition macros in the v3 software - this would certainly answer all my probing problems, not yet sure if I could do all the arithmetic with it - a lot more exploring to do.
Thank you @dc42 for making me take a step backwards and do a lot of re-thinking.
I will try and get some photos of the beasties.
That sounds an interesting and worthwhile project!
How many probe points do you need? The Duet Maestro powered printer here has nearly 16K free RAM (twice as much as the total RAM on an 8-bit controller), so there is room to support many more probe points. I can do you a temporary special firmware build with an increased number if you need it to test things out. Likewise if you need more arithmetic functions in conditional GCode, let us know.
Thanks for the response.
Taking the worst case, the outer diameter is 50mm, so circumference of 157mm and at a print width of say 0.4mm gives 392 tracks in the Y direction.I did consider running the dial probe 20mm in front of the hot end and measure every next few points. With stored points, I do not expect that resolution, but lets run with that.
On the X direction with a collar length of 30mm I need to track every 5mm so 7 probe points.
That gives a total of 392x7=2,744.
Now with the 'normal' raising and lowering of the probe, this would just take too long.
I would like to experiment up to half this resolution so say a maximum of 1,400 points.
Until I test everything with the new settings, I do not know what the outcome will be.
With the dial gauge I was not lifting it off the surface between measurements and made sure that no matter how mis-shaped the bamboo was I would always get a positive result. I moved the head at each point to re-centralise the probe. This was quick, but I needed to store all the points - which where this all started.
I have briefly tested the IR probe and more to do. The first problem is that I do not have a starting point for probing - perhaps another course set probe into a trigger pin, whic would give me a point to slow down the probe and do proper measuring.
A few unknows yet. I'm going to play with the probe first to see whether I can run at a reasonable speed and accuracy.
Taking the worst case, the outer diameter is 50mm, so circumference of 157mm and at a print width of say 0.4mm gives 392 tracks in the Y direction.
Do you really need to measure the distance separately for every single track? It sounds to me that you are using 0.4mm resolution in one direction and 5mm resolution in the other. That sounds very unbalanced.
Is there a reason why you are printing along the length of the bamboo instead of around the circumference? I would have thought that if you print around the circumference, it would be simple to have the dial gauge or other probe 90deg or 180deg ahead of the print head and a few mm further along the length (just enough so that the probe doesn't foul on filament that has just been printed). You could print in a continuous helix along the length. Alternate layers could be printed with the helix in opposite directions
@dc42 There is much more variance around the circumference than along the length (and hence 'grain') of the bamboo.
By probing at an angle there would be more variance with any bow along the length of the bamboo and the probe not pointing to the virtual centre of the bamboo. Rethinking it, this may not be such a problem as I initially perceived certainly with the dial gauge. Initially I thought of building the whole software from scratch to create a helix printer but soon realised that others knew far more about stepper motors, filament feed etc and that I would be wasting my time trying to reinvent the proverbial wheel.
I then took the simplistic route that as there was less variance along the X axis that I need only probe at 5mm intervals, but the circumferential values need to be checked more carefully.
The Mk2 printer checks at 5mm in the X direction and is OK. My problem come as I step over the boundary of one rectangle to the next in the Y direction. I would only move in the X direction for printing and then move to the next Y position and not do any angular work.
I did think, and indeed tried, the inbuilt bed levelling routines but I would still need to know at what layer I was printing rather than the probed zero point. The variation between hills and valleys can easily be 10mm.
I will take another look - reviews are always an essential part of development.
@CliveB In one of the initial concepts I had the hot end being driven by the Z motor and the and the opposite side if the gantry being an idler, free running on the bearing rods. The U motor drove the probe in the Z direction. For the probe to be offset by say 90degrees, a new driven axis would be needed as I cannot guarantee that the eccentricity of the bamboo would remain within the range of the gauge (25mm) assuming that I have kept a safety margin to ensure that the gauge never gets to the zero point. Quite an extra structure to be included on the gantry base. Let me think some more.
I appreciate the suggestions.
I have worked out how to mount the dial gauge with sufficient measurement range that it does not need to move using a calibration steel rod of say 20mm diameter between the head and tail stocks, which is then removed when printing on the bamboo.
With the Marlin incarnation I did a 5mm X blocking move and then took a reading and then moved on again. This has the appearance of jerky movement. I don't know how the blocking move works in RapRep to ensure that the 'Z' reading I get is at a true XYZ position before taking the Probe reading.
As a circle is really polygon, how small could steps be made to print part of an arc on the bamboo? I suppose a Gcode could be written to augment the G1 code to work an arc as we know the start and stop degrees and the diameter of the bamboo at those points - interesting times.
This morning I have spent a couple of hours trying, and failing to update the Maestro2 from RepRap 2.05.1 with the latest firmware 3.01-RC4 so that I could try out the conditional macros and reading of object information.
I cleared the /sys directory on the SD card and only placed the following two files in it.
Using procedure fallback #1
The USB port dropped and became active again, I tried variations of dropping the line via Pronterface or YAT and by totally removing the USB cable and hence power
When I sent M997 S0 I and did not get any messages back
Sending M115 displayed the old system informtion
FIRMWARE_NAME: RepRapFirmware for Duet 2 Maestro FIRMWARE_VERSION: 2.05.1 ELECTRONICS: Duet Maestro 1.0 FIRMWARE_DATE: 2020-02-09
I can't see what I have done wrong.
Are the hardware and firmware compatible?
Am I completely mad.
You can't upgrade directly from 2.x to 3.01 (this is mentioned in the release notes). Upgrade to 3.0 first from https://github.com/dc42/RepRapFirmware/releases/tag/3.0, then you can upgrade immediately to 3.01-RC4.
Thanks for that, the early morning lack of brain, I did go through the notes but obviously missed it - my apologies.
Thanks for that, the early morning lack of brain, I did go through the notes but obviously missed it - my apologies.
No problem, it was some way down the document. I've added a copy near the top.
I have rebuilt the gantry to include the IR probe and managed to get an ethernet cable into the workshop, so now testing via the DWS.
I expect that there is still finetuning to do with speeds, acceleration etc, but the whole rig is running smoothly, so back to the surface probing.
For testing purposes, I wrote a macro to probe every 2degrees around the circumference ie 180 plot points.
G0 X150 Y0; start of collar - need sensor offset
G91 ; relative movement
; the next section was expanded 180 times as no variables and haven't explored testing against the object yet
G30 S-1 ; single probe
G1 Z0.5 F100 ; raise Z by 0.5mm
G1 Y2 ; move by 1 degree
G90 ; absolute positioning
This probed OK - it took quite a while though - but I was getting readings back in jason format.
So why am I not just using bed mapping and fade to build up the ring collar? Normal bed mapping assumes that the surface to be found is zero whilst mine is as some arbitrary circumference. All I know is that it will be above 20mm and below 48mm (to allow a 2mm accurate surface to be built).
When variables etc are in place for macros, I wonder if I could do all the arithmetic there assuming I could read the mapping points.
Could there be a key in the object model for the surface map?
At the moment I intend to export all the information to a laptop running the via the web services.
I know in Marlin that a displayed position may be given back before the head had reached that point as gCodes are queued and that the position request could be processed before the movement was finished. If I run the probing macro as above, can I be sure that the figures back from the M409 will be the probe position?
If I send direct codes rr_model?key=move.axes.machinePosition is this outside of the queue?