Posts made by mikeabuilder

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.

@dc42 - thanks for the clarification.

@dc42 - clarifying question. Is the rule you stated applied based on the location of the macro file in directory tree? And do tool offsets follow this rule?

Interesting problem to solve. I read the intro messages with a different assumption than @droftarts - I assumed you are trying to repair gouges in the PTEX, not dressing the whole base of the ski/snowboard, and my thought was that rather than try to map a gouge, why not have a two step system. Position the "gadget" over the gouge and clamp it to the ski/snowboard. Select one of many pre-defined "patch" shapes. Insert tool #1 in the gadget. Tool 1 is a Dremel tool (or similar and routes a patch to a predefined depth. Then insert tool 2- the PTEX extruder which fills the shape the first tool routed. I can also imagine "custom patch shapes" could be created from a photo of the gouged surface.

I'll add here that for builders of custom 3D printers, one important criteria for the board selection can be the quality of the support and community. In my view, Duet3D is unsurpassed in this measure. This forum has a lot of thoughtful and helpful members and is actively supported by the Duet3D engineering team. I've gotten lots of valuable advice and guidance that made my 3D printer (coreXY, NEMA23, 250mm x 300mm x 250mm) design/build much more successful.

You could also read jobs.duration, sleep for a couple of seconds, then read it again to see it it has incremented.

Sad news. His contributions will not be forgotten.