Posts made by mikeabuilder

I agree with Ian (Dr-O'farts, I think it might be Irish). A loose grub screw will let the motor move a bit when it switches direction without moving the belt.

If you're going to print more tests, you could make an 8-sided box to enable looking at X-axis, Y-axis, and also each motor separately. You might also make that shape a "stepped pyramid" to be able to see if artifacts are starting at the corner (which might imply something to do with print head acceleration or extrusion speed). Your pictures posted on 16 Fed look like they have a very slight step at the bottom of the part, which gave me this idea.

Other thoughts after looking at the picture of the printer posted on 11 Feb...

Is there anything other than the shaft couplers preventing vertical motion of your Z lead screws? On my printer, I had some issues with z-banding and I switched from couplers like those you are using to the spring kind (which allows more Z movement). Then I put a screw collar (https://www.amazon.com/Shaft-Collar-Aluminum-Thickness-Screws/dp/B0BNZ937MV) on each z-shaft and put a thrust bearing (https://www.amazon.com/uxcell-F8-16M-Miniature-Bearings-8x16x5mm/dp/B07QLTXJDH) between that the the top of the lower bearing. Finally, I designed a spring loaded thing to put above the top of the shaft and keep a downward force on it. That cleaned up my z-banding.

On another printer, I had an issue where the threaded z shafts were not perfectly straight and they were moving the cars on the Z tracks slightly (again, z-banding). On this printer, I added oldham couplings (https://www.amazon.com/2-Pack-Coupling-Couplers-Compatible-Printer/dp/B0B17QWTG2) between the lead screw nut and the bed supports. It looks like you've maybe got something equivalent there. If so, these would isolate shaft wobble., but you might look for anything else that might be applying a force to the bed supports or the bed itself. It looks like there's a cable that may be tie-wrapped to the rear 2020 bed support. Better to tie wrap that the the lead-screw nut below the wobble decoupler. Any forces it applies will be isolated by the wobble-decoupler. The wiring from there to the bed would them have constant forces.

I think I might also be seeing a spring for a bed leveler on the right front corner (hard to tell for sure in the picture. If there isn't a hard connection for leveling (meaning the spring is holding it in place), that's another possible place for movement to happen if there are small irregular forces on the bed assembly.

Another thing to thing about is how rigid the print head is on the slider on the bridge. If there is any "play" in the slider, then the cables going to the print head might be wiggling the print head. If the extruder is "far" from the slider, it will amplify tiny movements.

Here's a wild theory - there's some interaction between the bed heater and the extruder heater, such that when the bed heater turns on, the power to the extruder heater is reduced slightly, leading to small variations in the flow of plastic. If the duty cycle on the bed heater is regular, it could lead to a regular pattern in the output.

It seems unlikely because the relay you pictured shows your bed is heated by AC. But maybe something on the control side is sinking too much current.

You could test by monitoring the voltage and duty cycle to the extruder heater.

I recently went through this exact thing with my multi-tool printer. I discovered that with Prusa Slicer and multiple tools, if you use only tool 1 (tool number in slicer number = RRF tool0), Prusa slicer does not include a T0 in it's output. But if you use any other tool as the only tool, or if you use multiple tools, then T0 is included in the gcode. I added the following to my printer's custom gcode:

; set the tool if only the first extruder is used
{if is_extruder_used[0] and not is_extruder_used[1] and not is_extruder_used[2]}T0{endif}

And while I'm sharing, I also include the following to set tool active and standby temperatures only when the tools are used:

;Set standby temperatures for extruders that are used in this print
{if is_extruder_used[0]} M568 A1 P0 R{temperature[0] -5}{endif}
{if is_extruder_used[1]} M568 A1 P1 R{temperature[1] -5}{endif}
{if is_extruder_used[2]} M568 A1 P2 R{temperature[2] -5}{endif}

Note that in the user interface Prusa refers to extruders starting with #1, but in their gcode output, they start numbering at 0.

I had some temperature challenges with my tool changer and found I had some temperature settings in my filament config.g file which I was calling via M703 and those were messing me up. But I don't see any M703 in your tpost.g.

I've spent a fair bit of time working on this same problem and I'll describe the macros I've come up with to help me.

Step 1 - Manual adjustment
My first step in setting a z-offset is to use a feeler gauge to get the nozzle at .2mm (I don't use paper for this, a good set of feeler gauges is less than $10). After doing this, I run my first Macro that adjusts the z offset so that the current tool position is .2mm.

; This macro adjusts the zoffset of the current tool to make the current z value 0.2mm
; optional input is Z = value we want Z to be after changing the z offset
; use case:

var target_z_vale = 0.2

M291 P"This macro will reset the current tool offset to make the current tools Z value 0.2mm." S3 T0

;If no tools is selected, prompt the user
if state.currentTool =-1    ; menas there is no tool selected 
  M291 P"No tool selected. Select tool first." S1 T0
  M99

; Read the current tool offset
var current_Z_offset = tools[state.currentTool].offsets[2]

; read the current z value
var current_z = move.axes[2].machinePosition

; calculate z offset needed to make current Z = 0.2mm
var new_z_offset = 0.2 - var.current_z

; build the command string
var command = "G10 P"^{state.currentTool}^" Z"^{var.new_z_offset}


; Create the replacement for the tooloffset file 
echo >{"tool"^state.currentTool^"_Z_offset.g"} {"; This macro sets the Z offset for tool # "^state.currentTool}
echo >>{"tool"^state.currentTool^"_Z_offset.g"} {var.command^"  ;changed: "^state.time}


; run the new z_offset file
M98 P{"0:/sys/tool"^state.currentTool^"_Z_offset.g"}

I have a personal peeve about using M500 to store parameters, so I write little macro files. On line 24, you'll see I build the G10 command to set the new z-offset. Then, on lines 28 and 29, I write that command to a file. I also include the date and time the file is created in a comment. Finally, I run that macro (line 33) to set the new z-offset.

And since I have a problem with M501 to restore settings, I have a line in my config.g file to run that macro on startup.

Having the date and time in the macro means I can look at it to verify that a new z-offset really got saved.

Step 2 - folding baby steps into the z-offset
My second step in setting z-offset if to use baby stepping when the first layer is printing to get it dialed in better. This macro is something I run after a print finishes to "roll" those baby steps into the z-offset.

; Macro to 
;  1. Read the current babysteps
;  2. Read the Z offset on the current tool
;  3. Create a command to adjust the tool z offset to use zero babysteps 
;  4. Overwrite the zoffset file for this tool with the command
;  5. Set baby steps to 0
;  6  Run the new z-offset file

M291 P"This macro will reset the current tool offset incorporate the currently active babysteps." S3 T0

;If no tools is selected, prompt the user
if state.currentTool =-1    ; menas there is no tool selected 
  M291 P"No tool selected. Select tool first." S1 T0
  M99


; Read the current baby steps
var baby_steps = move.axes[2].babystep  ; Positive babystep means the bed is farther from the nozzle

; Read the current tool offset
var current_Z_offset = tools[state.currentTool].offsets[2]

; Calculate the new tool offset
var z_offset_new = var.current_Z_offset - var.baby_steps

; build the command string
var command = "G10 P"^{state.currentTool}^" Z"^{var.z_offset_new}

; clear the baby stepping
M290 R0 S0

; Create the replacemetn fro the tooloffset file 
echo >{"tool"^state.currentTool^"_Z_offset.g"} {"; This macro sets the Z offset for tool # "^state.currentTool}
echo >>{"tool"^state.currentTool^"_Z_offset.g"} {var.command^"  ;changed: "^state.time}


; run the new z_offset file
M98 P{"0:/sys/tool"^state.currentTool^"_Z_offset.g"}

This macro operates similarly to the first one, but makes an adjustment based on the current baby steps. It's important to clear the baby steps (line 30) in addition to changing the z-offset.

If you have multiple tools, and want to adjust z-offsets based on the baby steps differently for each tool, you need to include it in the tool change process. That's another macro and I'll leave it out for now.

I opened the gcode file in PrusaSlicer and I don't see anything that looks like it would cause those shifts. The layer thickness is .3mm and each layer in the gcode is following the same path, with a variation in the 3rd decimal. This means I don't think there is anything coming in from the slicer X and Y positions or extrusion rate.

One thing I wonder about (because I'm not a spiral vase user) is whether there might be any effect on printing due to the very small Z moves with each new segment extruded. Can your Z stepper resolve the typical .001mm move on each segment? What's the smallest Z step your printer can do? I assume that if a z move is smaller than the printer resolution, RRF will accumulate the Z moves unti a full step (or micro-step) is used to "catch up". But I don't think this is the cause because if it was, then I'd expect to see the sane defect in the same place on every layer.

Which brings me back to the possibility of the bed shifting slightly during printing. I'd look at the defects on opposite X and Y sides to see if the defect shows matching shifts.

And unrelated to the print defects, I think you might want to look at the tooth generator, assuming this is an involute gear profile. The gcode path looks like an involute at the outboard part of the tooth, but has a little kink about half-way to the root of the tooth. It should be a nice rolling path (an involute) .

@DIY-O-Sphere - Can you post the gcode file for the gear?

My go-to place to start debugging this kind of thing is the slicer. For the diagonal lines, is there something happening on every layer, but at a different location? I use PrusaSlicer and it has the ability to show you the exact path it's creating for the gcode on each layer. I can often see something like a seam, or the first part of a line on a new layer, or maybe a scarf joint (latest Prusa feature). Sometimes it's something on a line that's not the outer perimeter.

In your gear picture, it looks like you have some X an Y shifting of the print bed as a function of the Z position. This can make the repeating waviness. I had a problem like this on my home built printer and I found some wobble in the Z-lead screws was pushing my bed around. I added something called an "oldham coupling" ( https://www.amazon.com/gp/product/B0C55RRFF6 ) which allows the lead screws to wobble some without imparting any X or Y forces. It solved the Z-related movement for me.

Interesting. Your results make me wonder if macro execution is "blocking", meaning that the object model is not updated until after the macro finishes. I'm being particular by stating "object model". Your macro is getting the state of the IO from the object model, not a direct reading from the GPIO and if there is some lag in getting the object model updated, it could give the result you are seeing.

It's too bad that M42 cannot be used to return the state of a GPIO. Many other gcode commands return the current value if the value-setting parameter is omitted.

Using a trigger might be needed.

I also wonder about the M950 command you used to define this IO. Maybe different types of IO are handled in different ways when updating the object model.

I think the current "RRF-ish" way to store parameters would be to write each to the file as a gcode statement that will create the value in a global variable.

So if you have three calibration values you need to store : calib1 = 10, calib2 = 20, calib3 = .2
You could write them in a file called saved_values.g

echo >"saved_values.g"  set global.calib1 = 10 
echo >>"saved_values.g"  set global.calib2 = 20
echo >>"saved_values.g"  set global.calib3 = .2

Note the use of a single ">" on the first line which overwrites any previous file contents and ">>" on the others that appends a new line to the file.

To read in the values, you first create the global variables, then run the macro. This code is either in your config.g or is run when you want the saved values:

global.cabli1 = null  ; creates the variable and assigns it a dummy value
global.cabli2 = null
global.cabli3 = null

M98 P"saved_values.g"

In the M98 command, it's ideal to include the file location (something like 0:/sys/saved_values.g if the macro is saved on the local SD card and is in the "sys" directory)

If I understand correctly, the expected behavior when the input goes from low to high during the while loop is that on the next iteration of the loop, when the loop condition is tested (sensors.gpIn[2].value == 0) the loop does not exit.

Is it possible the input is returning to the low state before the condition is checked?

As a debug step, you might add a an echo of the sensors.gpIn[2].value at the end of your loop so that you can see that the value was high at that moment.

If you need to catch a short spike on the input, you might look into is setting up a trigger (https://docs.duet3d.com/en/User_manual/Tuning/Triggers) on the input. The trigger would catch a spike in the input and run a macro that could set a global variable (set global.my_sensor_triggered). Then your code loop above could loop on a number of iterations and break on the global being triggered. Downside of using a trigger is you need to reset the global when you know the sensor is low.

My 3D prints are paired 99% of the time with a custom 3D design in Autodesk Fusion. I almost never download a model to print.

My parts:
Loads of utilitarian things for around the house - custom hangers for tools in the garage and shower cleaning supplies. A made to fit basket for the kitchen sink to hold and drain a sponge. Stands for art pieces. Cleats to wrap the pull-cords on window shades. Custom corner fittings for electrical conduit, The housing for a heater to keep the hummingbird feeder from freezing in winter. Handles for hex wrenches.

Many repair parts to extend the life of something - replacement foot straps for a stationary bike (TPU), replacement sprinkling spout for a watering can, replacement hinges (PETG) and latch (TPU) for a picnic cooler, bracket for a replacement switch.

Proof-prints for personal engineering challenges (can I design X in Fusion?) - I think these technically fall into the "artistic/ornament" category. Gear trains for a Copernican orrery, a 1ft diameter spherical shell 6mm thick (smooth on the inside and outside), various print in place sliders and hinges.

And of course, parts and accessories for a 3D printer.

Thanks for sharing this macro. Some things to think about when adding extrusions to start.g.

• Has a tool been selected? If you have multiple tools, or are not setting it in config.g, there could be a problem
• Is the tool heated to the proper temperature for the particular filament?

I had started to write a macro like this for my multi-tool printer and eventually gave up because of challenges in coordinating different location for different tools, getting each tool heated up properly, and selecting the proper temperature for each filament. In the end, I opted to put these kinds of steps into the custom gcode of the slicer. That let me use the extruder temperatures defined in the slicer to set active and standby temperatures for each tool and ensure they are up to temp.

If you decide to accept the security risks that Tony pointed out, and if you have a PanelDue attached,you could make a very simple macro that puts the IP address on the PanelDue. The gcode is M552.

I've built two printers with two different solutions. The one in my garage has all the electronics mounted on a piece of 5mm plywood, and the one in the makerspace uses 1/4" acrylic. Both of these were cut using the laser at the makerspace. It leaves nice, clean holes, and the laser allows a complicated shape, if this is needed. People will probably complain that neither material meets safety regulations for fire suppression, so that's something to think about.

Do you have cats?

I'd have a close look at the eventlog in the sys directory for some clues. There may be an error or warning logged.

I think the parts must have come off on because something hit them. If the bed heater stopped and the bed cooled, adhesion might have gone down to make them easy to move.

The docking spaces on my tool changer are outside the soft limits of the machine. When I have had strange tool moves with my tool changer, it was because somewhere in my docking and undocking macros I applied a M564 S1 while the tool head was still moving and outside the soft limits. That causes all subsequent moves to be ignored until am M564 S0 is applied. I haven't had mysterious things like you show. Mine have all been tool crashes.

Now, I always have an M400 before every M564 S1. And we're adding docking sensors to the machine.

@dc42 - Yes, those are the labels I'd like to be able to change.

I'd like to change the tool numbers displayed on the PanelDue to be "1-based". Is there a way to do it?

I'm trying to have consistent labeling of tools/extruders between the PanelDue UI and PrusaSlicer. The slicer numbers the extruders starting with "1" (even though the gcode output is 0-based) and I'd like to have the PanelDue labels start with 1 also so there is a match.

I'm able to change the labeling in DWC through the S parameter in the M563 command. A new parameter in this command could do it, or another parameter in M575, or even a whole new macro or MXXX command for sending configuration parameters to the PanelDue.

@Chriss - I'm also one of those people that wants to know how things work in detail and ended up writing my own macros for tool changing on the printer we are building at our maker space. Our tool changer is a modification of the Jubilee tool changer, which was a modification of the ESD tool changer. Here are some concepts we learned along the way - meaning things I got wrong at least once before getting it right.

X and Y Tool offsets

• We designated tool0 to have X and Y offsets of 0. Why not? it makes stuff easier when setting up the other tools.
• We designed a two-color part that we print to help us dial in the offsets. Its two concentric square, like two square donuts nested together. Here are the stl files. XY_nozzle alignment inner ring.stl XY_nozzle alignment outer ring.stl If the X offsets are perfect, the total with of the right and left sides of the "donut" should be equal if they aren't equal, the different is twice the amount the offset needs to be changed. Same with the Y direction. We eyeball the alignment the first time, then use calipers to get the final adjustment.

Z offsets

• Each tool needs to have it's Zoffset set independently. We didn't designate roo0 to be the origin because we make Z offset changes often.
• We use baby steps to make final adjustments to the Z offset and we wrote a macro that will read the current baby steps and z-offset form the object model, and change the z-offset to "roll in" the baby steps if baby steps have been set. We run this macro whenever we park a tool (ie run tfreeN.g).

Moving outside soft limits

• We set the X and Y soft limits of the machine so that prints can't drive the printhead into the tool docking area. This menas that when we dock or undock a tool, we need to allow moves outside the limits (M564 S0). When we move back inside the limits after we pick up a new tool, we need to disallow moves outside the limits (M564 S1). Be sure to put and M400 (wait for moves to finish) before the M564 S1 or RRF may discover you are outside limits. We crashed the tool several times while learning this one.

tpre vs tpost

• This one confused us for a while until we understood that the "event" that the "pre" and "post" refer to is the changin of the tool number in RRF. This means that during a tool change RRF has no "awareness" the tool offsets, extruder settings, etc while it is running tpreN.g. If you have any gcode command in tpreN that has a parameter for "current tool", "current heater", "current extruder", "current filament", etc, they probably should be in the tpostN.g file.

simplifying the macros

• All three of our tools have the same docking procedure, with only the X location of the dock different. We ended up writing a single macro for each of tfree, tpre and tpost, using an input parameter for the X location of the dock. We called these macros tfree_all.g, tpre_all.g, and tpost_all.g. In the actual tpostN.g file, we just use an M98 to call our macro. With this setup, we can tweak the parking macros in one place.

The slicer

• We normally use PrusaSlicer and have one line of custom gcode for each tool. This line sets the standby temperature for the tool, based on the nozzle temperature set in the slicer. We did this to try to minimize the time a tool takes to re-heat after it's been picked up. We started with 25*C below active temperature, but this was giving us about 30sec of wait time per tool change and it felt like forever. When we kept the nozzle temperature at the active temperature we had some problems with the plastic melting beyond the cold-break when the tool was docked for a long time.

PanelDue

• In PrusaSlicer, the extruder numbering is "1-based" - and RRF it's "0-based". this leads to confusion for users when they are using the slicer. We can change the labeling for the tools in DWC to align with the Slicer numbering. Our main user interface is the PanelDue and we have not found a way to change the tool numbering on it.