Side note: If you havent PID tuned your bed yet, do that too. The pulsing of a bang bang controlled heated bed can deceptively look like z wobble ...

@leckietech I'll add auto-wrap to the firmware work list.

@diy-o-sphere said in Separate P and S declarations in M950:

@fcwilt
I got that. It is the numbering of channels. S0 and P0 are not 2 channels, it is just the same. That wasn't obvious to me.

Understood.

Frederick

@dc42 said in Some questions about firmware retraction on a toolchanger:

Yes. But would you ever do T0 G10 followed by T1 G10 without an intervening G11?

I could foresee a scenario where that might occur. A purge macro might consist of a G10 retraction, a non-print move to a "bucket" followed by a G11, then an extrusion, then another G10 to end the purge - probably followed by a nozzle wipe for which a G11 would be undesirable. One might run that as part of a pre-print routine but also after selecting a tool. If the pre-print purge ended with (say) T5 - G10 but the first command in the gcode file was T0 which instigated the tool change macro, then one would get another G10 without an intervening G11.

@oliof
supported, since it would make gears mesh of my 'Hitchhiker' U-axis easier to adjust.
Too tight and it suffers top speed or even skips steps, too sloppy and it's less accurate.

Also other drives with gear(box) would love this feature
v-slot_N20-test.jpg

https://github.com/Duet3D/RepRapFirmware/issues/new/choose

Perhaps consider also making a feature request on github?

@jphilly Homing to zmax is an option, but the distance between Z0 measured at the start of the print to the actual position where the zmax endstop triggers must be measured accurately.

For what it's worth, I have 1mm lead screws and after a power outage I don't rehomed to zmax even though I could. I just find the approximate height of the print, check it against the sliced model to find the exact layer it was on and then use that to set the Z position with G92 and resume the print. There may still be a slight line visible on the print, either due to inexact position or simply just the effects of cooling and shrinkage. But if that's not important at least you have a saved print.

Just to put the icing on the cake, if you have G28 to home automatically at power up, what happens when you have a power blip mid print? When the power returns and the board starts up, it will home the printer and crash into whatever print is left on the bed.

I've just done the same investigation and come to the same conclusion looking at DWC and how it grabs the info from the RRF printmonitor.

DWC uses the height of the object to calculate total layers at https://github.com/Duet3D/DuetWebControl/blob/1121469e780d213df0cda6e85fbf1bb2000a8c33/src/store/machine/modelItems.js#L435. After some scanning around, it doesn't look like RRF passes back numLayers hence always dropping into this approximation logic. Please correct me if I am wrong on this.

Given it is dropping into that approximation, the specific issue is that height is not calculated correctly where there is a none print move. This is especially prevalent when you have ending GCode to move the extruder out of the way of the printed part. The logic to calculate the height is done in the printmonitor code at https://github.com/Duet3D/RepRapFirmware/blob/123d4362a04a709103971dd10b94e916b8790ef8/src/PrintMonitor.cpp#L145.

Must admit that having the height parsing logic look forward for subsequent extrusions would likely cause parsing to slow down considerably. Given this, I wonder if implementing the parsing of numLayers to pull it out of the GCode header with a specific format is the best way to go.

@o_lampe all Duets use hardware PWM on all the PWM-capable ports. So no CPU time is used to generate PWM. Note, this does not apply to ports of RRF to some other boards.

@fcwilt Sorry, I could have been clearer.

Let me give an example. My mill is controlled by a tablet. I do things like carefully calculate X,Y zero by moving the head and touching the part I'm going to mill. Then I do an M114 to read that zero value in the console so I can save it in case I have to emergency stop. I may also run one or two small jobs (milling a part requires running 10 or 15 jobs). So, there are a lot of little tweaky things happening with console output.

If there's a mistake or something I want to slightly redo I go to my upstairs office and use a large desktop PC to run Fusion360 to 3d model / generate machining operations. While doing that I need a reminder of offsets and results from the last few tasks (or even just know which mill job I last ran) but I can't read the Duet console because I'm at a different computer.

@jay_s_uk That's a really good idea - I didn't know that existed. I think I'll look into adding something timestamped to my config.g that saves logging info and see how that works out.

Mark

@phaedrux Thanks!

You could create two thermostatically controlled fans that monitor the same CPU temp. No UI, but if you tune the temp range it's just set it and forget it. Or do as I did in my case and wire the fans together in parallel.

@dc42 I'm experimenting with closed loop control from a computer that reads video frames at 60 fps so I wanted to match that update frequency with the true position of the machine (this video talks about the video sensor https://youtu.be/5vjdLNiMfcc)

Not sure I see where I'm messing with the USB but I'm probably just missing something. Seems to work well enough for a prototype so I'm going to keep going with it.

@droftarts THANK YOU! That will work.

I missed that feature in the description of changes. I will try that.