Topics created by TC

@TC Maybe try higher bed temp. Print faster when printing the base and slow down printing when printing the upper wall. Also If make the upper walls with more infill that will also slow down the print and keep more heat in the print.

With large parts, a heated chamber makes larger parts easier to print.

Can you try PETG? It doesn't shrink as much.

Nice work around 👍
Thx David!

@jameswood It would also be fantastic if the list of filaments that's displayed when clicking "Load Filement" was sorted alphabetically or something. Currently it seems to be sorted by filesize? Custom sorting would be even better, or, if we're wishing really hard, subfolders!

@dc42 Ah that is a nice idea. What would be the best way to store this information about a former retraction in RRF 3.1.1?

And are there more than 3 restore points? if so I could save the last position for each tool so it could go back to where this exact tool left the print last time.

I'm not a tool changer user but from what I gather on the E3D tool changer the head has an endstop switch to set the bed position relative to the head and then the tools each have an offset from that point which is set in the tool change macro at pickup. Again, I could be totally wrong about that because I have only used one myself very very briefly.

Thanks for the feedback.

My first guess is that if you're seeing an constant offset across the board, that'd be the discrepancy from programmed Z height, likely related to some missed steps traveling fast / accumulated after homing to the first probe point. I would reduce the travel speed in M558 to something fairly low to and see if it clears up. If it does, then you can play around with adjusting acceleration/ jerk settings to make it go away. If it doesn't, try lowering the feed rate too. Hopefully you'll find something with that.

New links:

https://github.com/TC1991/RepRapFirmware/blob/v3.02-dev/src/Movement/Kinematics/VerticalPlotterKinematics.h
https://github.com/TC1991/RepRapFirmware/blob/v3.02-dev/src/Movement/Kinematics/VerticalPlotterKinematics.cpp

Use RRF3 conditional GCode. If the bed sensor is sensor 0, something like this:

while sensors.analog[0].lastReading > 30.0 G4 S1

@TC If you bought it in August, that would unfortunately mean that it is out of the 6-month warranty period; see https://www.duet3d.com/warranty

The SD card socket, WiFi module, and processor is pretty much the order of failure if there is a short between +3.3V and VIN. This can happen if the voltage regulators fail, or if there is a short in your wiring. See https://duet3d.dozuki.com/Wiki/How_to_destroy_your_Duet_2#Section_Methods_that_are_very_likely_to_write_off_your_Duet

If you can post the pictures I asked for (a good, high resolution, in focus picture of the board), we can check if there are any obvious failures, particularly of the U2 and/or U3 voltage regulators. While it still means that the board may not be economically repaired (too much has already failed) it may at least show what needs to be checked/tested.

The important thing is to carefully check through your wiring before connecting another board, or the same thing may happen. I also have an unfounded theory that voltage spikes through the PSU at power-on may cause the failure of the regulator, as power-on is often when they seem to fail. But then I'm not an electrical engineer!

For boards out of warranty that fail in this way, we do keep a stock of refurbished boards, for a low price on exchange. Contact Roland on sales@duet3d.com if you're interested.

Ian

I just tried the internal build dc42 recomanded in the RRF 3.01 RC2 thread and it solved the problem 😉
Will let this topic online in case someone else has the same issue.

@dc42 said in G54-59 not working in start.g?:

Commands in macro files in the /sys folder always ignore workplace offsets. This is so that movement commands in homing files, pause.g and so on always go to the same places regardless of what coordinate system you are in.

Very interesting and good to know. THANKS!

@TC said in Filament type assignment:

"state.currentTool

Thanks! I'll look into that. Actually I think after my update to 2.05.1 my filament config.g macros aren't even working. Going to check into that.

@TC I want to do almost exactly the same thing but I haven't had time to look at conditional gcode. May I ask you to share your "script" once you get it working please? Thanks in advance.

@Danal thanks a lot

Thanks so much!

Ah so it is really bound to the tool change... ok thanks for the fast reply 🙂

Thanks for the link. In the description about how to replace a fan mosfet it sounds like a special handling is necessary... is there a reason not to just use a very thin solder iron to replace it?

Yes uneven cooling will cause uneven crimpage...