Posts made by darookee

@djdemond No Problem! Unfortunately I gave up for now, as I could not get it to not trigger before probing or even while probing, but not yet touching the bed as it needed to be very sensitive to trigger when the nozzle touched the bed.
I'm planning on rebuilding my Z and getting rid of the springs on the corners of the bed. Do you think this could help with triggering at a lower sensitivity?

The print just finished. It occasionally clicked and clacked a bit, I tried loosening the screw a bit more, but that does not do anything. But I guess it's not a Duet problem. Thanks for the help!

I disconnected the motor and tried turning on the black gear. It was a bit hard to move. I disassembled the extruder body and tried turning and it moved freely... So then I reassembled everything and did not tighten any of the screws, than turned the gear and tightened one screw after another. When I tightened the one through the bearings and gear it started to get harder to turn, than I unscrewed it a bit. I'm currently heating the printer up. I checked the screws multiple times but never noticed this... gnah

The pinout seems to be the same for both motors and cables. The motor that is currently installed was installed with the same cable for about one year, but with an MK10 extruder. Now that is 'in' the Titan Aero it is giving me troubles. Also the Titan Aero with the pancake motor was working fine for at least a few days. Could this be a problem with the bearings (that E3D had a while ago...)?

Yes, well. I already swapped the cable, and that did work at first. As for the motor, I guess the E3D pancake motor is busted, I did not try it again after it didn't work with the new cable, the other motor I'm currently using worked flawlessly in my old extruder assembly and worked fine until I installed it on the Titan Aero with the new cable and printed for a while (didn't work with the old cable).
I'm running on 12V. The E3D pancake motor is a 0.9° 12V motor rated at 1400mA, the other motor is from an 'old' Wanhao i3 and the specifications are not clear, but it is a 1.8° 12V motor, and it ran for about 1 year at 1200mA without problems.
My settings are as follows:

M201 X2000 Y2000 Z100 E250
M203 X18000 Y18000 Z300 E1200
M92 X80 Y80 Z400 E418

It was connected to E0, after your post I moved it to E1 and added M584 E4:3 to my config, before any M906 and M350 commands. Then restarted the printer. (It was also powered down while swapping the connectors).

Thanks for the suggestion. I just tried it, but it also does stutter. Just to confirm, M584 E4:3 just remaps the driver internally, the output still is the on marked as E1 on the board?
Yesterday I did try E1 with reconfiguring the tool (M563 P0 D1 H1), also with stuttering.

A few days ago my Titan Aero started stuttering while extruding and retracting. After a lot of troubleshooting I was conviced that it was a bad cable, but that does not seem to be the only problem.
I used the pancake motor that came with my Titan Aero and it was running successfully for a few days after finaly installing it on my printer. Then one morning when I wanted to change filament it startet suttering a bit while retracting. I didn't think much of it so I inserted the new filament and startet to print. While printing it stuttered more often so I cancelled the print and got on with the troubleshooting. Trying higher temperatures, doing cold pulls, pushing the filament manually,... I could cofirm that it was not a clogged nozzle. I then disassembled the extruder and tried to run the motor on its own which resultet in more stuttering and ended in the motor only stuttering and not moving at all. I then tried the motor from my old extruder, which also did stutter. I then tried another motor driver (was using E0 exclusively before that) but it also stuttered. Than I used another motor cable and the motor turned without a problem. So I reassembled the Titan Aero, first with the pancake motor, but it started stuttering again, then with the other motor and I finally got filament extruding. I then tried a print, not bothering with finetuning the extruder steps, just modifying it for the 1.8° stepper instead of the 0.9° pancake stepper. The print started fine, but after a few layers it began to stutter again. I cancelled the print, tried again with higher temperatures and slower extrusion speeds, but it begins to stutter more frequently again. I now stopped everything because I don't want to damage another motor.
I'm at a loss. It's not just the motor, it was not just the cable, it's not a clogged nozzle and it does not seem to be too high pressure on the motor shaft. What can I look for now? I also tried adjusting the motor current (was set to 1200mA for my old extruder, which I also used with the Titan Aero pancake motor without problems, that one is rated for 1400mA), but that doesn't do anything, either...

I need help, please

I did a bit more testing and foud out that the piezo will trigger, just much later than I expected. And much less reliable. I did G29 and got this:

After moving everything around one lead of my piezo broke and I had to replace it, but just had 27mm discs. I stuck one below the lowest screw of the mount and got this G29 result

Now I'm happy...

After fiddling a bit more I glued the disc in place, this got rid of the constant triggering when the fan is turned on (YAY!).

Unfortunately I discovered that my design is pretty flawed. As I said the idea was that the bed touching the nozzle would pivot the 'arm' with the triangle on top around the whole in the bottom to press the piezo. Touching the bottom of the motor mount does just that. Touching the coldend part of the Titan Aero does it, too. Touching the nozzle doesn't…

I also found that the top of the triangle is touching the solder point on the piezo, I'm trying to file it down a bit so that it does not touch it anymore and see if that does anything...

I tried reversing the polarity, but still got the same results. It's triggering on every movement that in any way affects the printer, be it touching the frame or placing a hand on the table. I already use M558 R0.8, and now also lowered the acceleration. That helped with the triggering right after the probing starts.

The other problem is that it either it is constantly 'triggered' when the coldend fan turns on or, if I adjust the sensitivity while the fan is on, it will still trigger when I touch the printer, but not when the bed touches the nozzle.

I'm thinking maybe my carriage design is not optimal. It looks like this:

The piezo sits in the round part at the top, the idea was to push on it with the triangular part, which is flexed a bit backward when the nozzle touches the bed, but maybe it is too tight when resting?

As this is currently a setup in testing and I only have one piezo disc ( ) I did not glue the piezo in. Do you think the problems could be caused by the disc itself vibrating inside its slot?

Thanks, I will try.

The problem is that when the bed moves up it triggers the piezo, so homing is not possible at the moment

I just installed the Percision Piezo probe on my self-designed X carriage on my HyperCube and can't seem to get the tuning right.

It either does not trigger when knocking on the nozzle, or it does trigger on every move of the printer, or even when you touch the printer frame or the table on which is sits… Is there a trick to get it right?

@okercho:

If you use the "Filaments" feature in DWC, you can just change some params (PID, retraction…) when loading the filament, although those params are just executed during load and unload, and not after a reboot...

That is why I have a file [c]current_material.g[/c] which currently contains this:

M98 P/macros/Settings/PLA
G10 P0 R150 S210 

The Settings/PLA contains the retraction settings.
My Filament load macros use M28 and M29 to write the [c]current_material.g[/c]
for PLA:

; create file to set options on startup

; current_material.g
M28 /sys/current_material.g

M98 P/macros/Settings/BDP

M29 /sys/current_material.g

; load settings from startup file
M98 P/sys/current_material.g ; Load material.g to apply general settings

And I added [c]M98 P/sys/current_material.g[/c] to the end of [c]config.g[/c] so that it gets executed after boot. Voila!

Oh, my favourite topic.
This is my start:

M140 S[first_layer_bed_temperature] ; set bed temperature with 
;M104 S[first_layer_temperature]         ; set extruder temperature tool selection
M98 P/sys/before_print.g

```and this my end g-code:

M98 P/sys/after_print.g

T0 ; Select tool 0
M116 ; Wait for tools

G32 ; call bed.g

; Purge line
G1 Z0.2
G1 Y2 X25 F15000 ; move out of build volume
G1 X175.0 E24 F1200 ; finish purge line
G4 P5000 ; Wait to let the plastic cool a little
G1 X100.0 Y100.0 F15000 ; Move to middle to rip plastic off tip
G92 E0 ; set reset extruder position to 0

after_print.g:

M400 ; Wait for buffer to be cleared
G91 ; relative positioning
G1 Z+30 E-1 ; move Z up and retract filament 1mm
G90 ; absolute positioning
G1 X0 Y200 F5600 ; move extruder to the back
M98 P/sys/cool_down.g ; call cooldown
M1
M81 S1

and cool_down.g

M106 S255 ; fan at 100% to cool nozzle
M1 ; heaters and motors off
G4 S360 ; Wait for 6 minutes
M106 S0 ; fan off

@Phaedrux:

I wonder if it would be possible to just do a pull request for Slic3r PE to take the Duet connectivity from the main Slic3r dev branch that already has it working.

It looks like it is this commit https://github.com/alexrj/Slic3r/commit/1c74067da09a9a23ce66227b55146af6182d747d, it should be possible to pull it in and build your 'own' slic3r version, but I guess that these are not the only changes needed. 5fbb245b9790193b6924735fd985dc3cd2350ee6 and 13f121e3d952cca33b1ee5fdd73c12d85bf54d0e also mention the duet.

Edit: As I said before, I doubt that this would get accepted

0 emaker committed to alexrj/Slic3r

Octoprint settings functionality expanded to allow upload to RepRapFi… (#4028)

* Octoprint settings functionality expanded to allow upload to RepRapFirmware on a Duet controller.

* octoprint_host renamed to print_host to enhance code readability.

Fixes #4022

I doubt that this feature will be integrated into the prusa edition - the main audience of the software are users of prusa printers, which don't use Duet boards.

Check the gcode file if it contains 'M117' commands like 'M117 Printing… tw@L 120'. If it does you should check your slicer settings (layer change script for example) if there is something that will make the slicer add these.

Usually your router assignes IP addresses to devices that 'ask' for one (using DHCP), and on most routers you can set an option to 'always youse this address' for a specific device, or even manually assign addresses to devices the router knows.

I recently stumbled uppon IceSL, which looked very interresting.

The included printer profiles did not generate G10 and G11 for firmware retraction, so I needed to create a new profile. Maybe this is of use for someone else, so I put it on github: https://github.com/darookee/icesl-duetwifi.

I use scripts and macros for a lot of things, so instead of generating a start and end g-code the generated g-code file relies on macros stored on the Duet. This has the advantage that you don't need to re-slice a model for everytime you change something in your start and end procedures. It also just generates the code to set the bed temperature, as selecting a tool with Tn will heat the tool up to the temperature set with G10, in combination with the filament feature of the WebUI the files generated with this profile are almost material independent.