Rotational Printer

CliveB

Hi
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.

dc42

@CliveB said in Rotational Printer:

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

CliveB

@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

@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.

CliveB

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.

CliveB

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.
https://github.com/dc42/RepRapFirmware/releases/download/3.01-RC4/DuetMaestroFirmware.bin
https://github.com/dc42/DuetIAP/blob/v3-dev/Release/iap4s.bin

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.

dc42

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.

CliveB

Thanks for that, the early morning lack of brain, I did go through the notes but obviously missed it - my apologies.

dc42

@CliveB said in Rotational Printer:

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.

CliveB

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
M409 K"move.axes[].machinePosition
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?
I think that I can do all the calculations in javascript on a dedicated web page and make an easy controller for the printer, leaving the RepRap software as standard.
Clive