Duet Wifi keeps wrecking my printer, not happy!
-
I have had serious problems with the board doing random stuff and it just rammed the hotend into the bed and damaged the printer again for the third or forth time and I have had enough. The machine is industrial grade with highwin and CPC linear rails, 8mm machined bed, dual 16mm ball screws and 1500 watt AC bed heater and cost a lot of money to build. The machine is intended to run every day and is vital to developing my business. I cant afford to have it self destruct every few days.
It was printing the first layer of a 15cm x 25 cm box and when it finished one section and went to move to the other side to finish the layer, it raised the bed and rammed the hotend into it then went to move gouging through the 0.6mm layer (volvano hot end with 0.8mm nozzle) all the way to the bed and wrecking the mount. Luckily I was actually watching the printer and quickly pulled the plug. This is not the first time it has done something like this (its the third or forth) and I have hardly used the machine at all as I only recently finished building it and as it set up for large prints (volcano and large nozzle) I use one of my old smaller printers for most prints which are just hobby stuff.
It also has a habit of changing the Z height zero by 4 or 5 mms, so it will be perfectly set up and print several items no problem, then when I turn it on again its completely off by several mms. Sometimes it will be high with zero now being 4 or 5 mm off the bed, sometimes it will be low and ram the hotend into the bed.
I have been 3D printing for about 18 months and have never had a problem with either of my RAMPS board based printers.
I would like to hear your thoughts on this, maybe its my fault but I really really doubt it. This is not me setting it up wrong and getting problems as it will work fine ( yesterday I test printed a small section of the object with no problems then it screwed up again) for 1 or 2 prints and then bugger up again.
I have to say I now have absolutely 0 confidence in the controller, actually less than zero as I know it is 100% likely to bugger up at any time.
Unless someone can tell me why this is happening and a definite cure I will be taking it out and replacing it with a RAMPS board or maybe a smoothie board.
It is a shame as I love the features, flexibility and interface but my main need is for something that works reliably.
The printer is a normal cartesian with the bed on ballscrews for Z axis.
-
@splathammer Actually thinking back, this has happened in one form or another about 8 or 9 times if you include the times it hasnt even started printing when it hits the bed and starts ploughing aluminium shavings out of it, the times it suddenly decides 0 on the Z axis is some random +- height and the times it just goes crazy part way through the first layer! Given that I have only made a few test prints I would say it screws up about 1 in 3 times I have used it.
-
@splathammer The fact that there aren't numerous other people reporting similar problems indicates that this is a one off scenario. That kind of rules out any problem with the firmware as there are hundreds, if not thousands of people using it right now. I really can't think of any reason why the Z height would change the middle of a print unless it is commanded to do so. For the Z axis to move like that, it needs a G1 Znnn command or something that commands the Z axis to move. Are you by any chance using using Z hop in your slicer? Are you using firmware retraction and if so, is there a Z hop command in that? If so, disable it. Do you get the same behaviour with every gcode file? Are you using bed level compensation? I guess a dodgy height map would initiate the behaviour you describe. If your bed is flat and level which it sounds like it is, you don't need to use compensation.
Problems with bed crashing during homing are almost always to do with the Z probe (or switch) no triggering, or triggering at the wrong point. Again, this isn't a Duet board issue - it can only act on the information it receives from the probe.
Are you by any chance using BL Touch? If so, my advice would be to ditch it. Just look through these forums and see how many threads are related to BL Touch issues. That's not a Duet product - in fact it's not even open source. Yet the Duet guys get all the flack when people can't get it to work.
-
@deckingman I am not using Z hop, auto bed leveling or bed level compensation. The bed is a perfectly flat, machined 8mm slab. Its mounted on 3 very heavy duty die springs and 8mm bolts and has not shifted a micron since first leveled.
I am using slic3r and the settings are identical to those used on the other printers with no problems. I have even used the same design that caused a problem and resliced it with the same settings except bed and nozzle size then printed it with no problem on another printer.The bed crashing cant be caused by z probe because I have have checked the height is correct after the z axis has homed and before the print has started, also the z axis doesnt re-home part way through a print! The z probe is a new type inductive designed to work on 5V and is connected to the board via a magnetic isolator which also does the 5V - 3.3V conversion. I have exhaustively tested it including with a dial indicator and it has been 100% accurate.
The bed does NOT crash during Z homing, it crashes at the start of printing when it moves to the start position or as yesterday part way through the print.
This is the big mystery as I have already tried to think of and eliminate any possible causes.
-
That's an odd problem. First, a few questions:
- Can you confirm that you are printing your GCode files from the built-in SD card?
- What firmware version is your Duet running? Check using M115.
- Have you set up any triggers using M581?
- Is Telnet disabled (the default), or have you enabled it?
- Does your system include a PanelDue, if so how long is the cable connecting it to the main board?
- Please post a M122 report, taken after the machine has been printing for a while
- Please post your config,g file
The only reasons I can think of why Z would move in the middle of a print are:
-
Bad GCode file. In which case the behaviour would be consistent if you reprint the same file.
-
Undetected errors reading data from the SD card (I presume you are printing from SD card). Recent firmware versions retry SD access failures and report SD card errors better than older ones. Maybe you should move the SD card to a PC to check it for errors, and/or replace it.
-
Command to move Z received from another input channel during printing. The channel could be USB, HTTP (e.g. Duet Web Control), PanelDue, Telnet if you have enabled it, or a trigger you have set up.
-
Pause command encountered in the GCode file - but then the printer would pause, not continue printing.
-
Firmware running out of memory. Shouldn't happen unless you have configured a very large number of tools.
-
A firmware bug that we haven't found yet and that nobody else has encountered (or if they have, they haven't reported it).
-
A hardware problem, e.g. bad memory cell in the MCU.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@splathammer I have just checked the g code file for the print from yesterday and there are NO odd G1 Z commands. It goes to 0.6 the 1.2 with nothing in between.
-
@dc42 Hi
I will have to get back to you this evening as I am busy and away from the printer. I can say that everything is default, the config file is set from the online configuration tool, I dont have the panel duo I am using wifi, I havent set any gcode commands and as the files were sent via the web interface they should be coming from the sd card if that is default. The board was purchased in January and had the latest software version at that time.
As I mentioned in another post I have checked the g-code and the only ones are:G1 Z5 F5000
G1 Z0.6
then
G1 Z1.2 etc.I will post a photo later which shows where the hotend made a hole in the print down too the bed, then a score mark where it dragged along the plastic then another hole where it stopped when I pulled the plug. the holes are where the heat allowed it to actually force its way through the plastic, I dont know exactly how far it had shifted as I immediately rebooted it and lowered the bed to relieve stress on the hotend and gantry, but it looks like several mm´s as the hotend was forced about 20 - 30 degrees from the vertical!
The only thing I can think of is that I may have had the web interface open on both my PC and mobile as I have sent the file from my pc but was using my mobile by the printer and had decreased the distance to the bed by 0.05mm to improve adhesion as I had problems with an earlier print attempt which I aborted.
-
@splathammer Clutching at straws to find a reason here. What you said about baby stepping made me think. My mind was rambling along the lines of a stuck keyboard key or faulty mouse or some such which meant that multiple babystep commands were sent. Like I said, clutching at straws but this is very odd problem you have.
Edit. We believe you - although we are struggling to find a reason for it. No need to post a picture of the damage. If you could possibly make a video of it happening this might help but I understand that you likely don't want to suffer any more damage.
-
the firmware has moved on an awful lot since January maybe worth upgrading it all to latest versions and try again also please post your Config files there may be something that has crept in (The configurator has some bugs I believe, it is getting better but I tend not to use it and hand graft all my config's)
-
@deckingman I sent the baby step command from my mobile and can guarantee that it was only one - it was the first time I ever used it and I checked that it was reading 0.05, it did solve the adhesion problem!
I would be willing to send a video, the mount was designed to flex a bit to minimise damage - one of the first times I used the printer this happened and as the original mount was printed in thick carbon fiber reinforced petg the result wasnt pretty - the heat break did as its name suggests and broke! BUT since it is the wonderful intermittent problem (doesnt happen every time and or at the same point) it would be virtually impossible. I will send the photo just in case it can help and it does actually show what happened almost as well as a video. -
@splathammer Intermittent problems are a bugger to find. The usual cause on 3D printers is a wiring issue - usually a bad crimp that gets moved around as the axes move, but I can't think of any reason why such a fault would cause the Z axis to move when it shouldn't. It might stop or pause but not randomly move by some amount.
When it's printing, and especially when the problem occurs, does anything show up in DWC on the console page? Any unexpected commands logged? I guess another thing to try would be to send M122 when the fault occurs. This might provide some information that DC42 could decifer.
-
And to get support properly I think you will need to be on at least the latest Stable Firmware which if as you say your's is whatever was on it in January it will be well out of date. the 0.05mm baby steps also leads me to believe you are quite old DWC has been at 0.02 I think it is for some time now.
Doug
-
It's a long shot, but make sure you've set maximum ajax retries in DWC to 0. Last time I checked, DWC retries any failed XHR requests, including execution of G-Code. Failed requests include ones where it reached the printer, executed, but failed to deliver the response back to the client (because the client cannot tell the difference). This can cause G-codes to be executed multiple times. I've seen it happen where my printer homes twice when I click the Home button, for example.
(I reported it as a bug, but the issue was closed)
-
@tomasf Thanks for that, it was set to 1 so I will set it to 0 next time.
I have worked out a course of action based on all the feedback, see my comment below! -
@dougal1957 Thanks, I will. I have worked out a course of action based on all the feedback, see my comment below!
-
@deckingman No unusual log entries, just the usual. I have worked out a course of action based on all the comments, if you can think of anything I have missed let me know. This is my course of action:
- As someone with a background in science and engineering I believe the first step should be an exorcism, we are talking full on bell, book and candle here as demonic possession seems the most likely cause (also I am watching Ash VS Evil Dead at the moment)!
- Replace the SD card
- Update the firmware and make sure telnet etc is off and I am using a fixed IP outside the DHCP range of the router.
- Set Ajax retries to 0
- Ensure only 1 device is connected to the Duet
- Run the M122 report command.
- Pray really sincerely.
-
@splathammer Sounds like a plan. I'm glad you are continuing the fight and not throwing the towel in as you indicated you might in earlier posts. Glad not just for you but also if this issue crops up in the future, so that others can benefit from what we learn. Nothing like this has been reported before but there has to be an answer. I'll keep racking my tiny brain, as I'm sure will others.
Edit - keep us posted on anything you find.
-
@splathammer said in Duet Wifi keeps wrecking my printer, not happy!:
... we are talking full on bell, book and candle here ...
Off Topic: "Bell Book and Candle" is one of my favorite movies of all time. 1958. James Stewart, Kim Novak, Jack Lemmon.
Well worth the watch...
-
@danal
Looks like a fun movie! I was actually referring to the fact the Catholic demonic exorcism ritual involves those items!
If you liked the original Evil Dead movie check out the brilliant Ash VS Evil Dead series. Same humor, horror and gore same Bruce campbell oh and as a bonus Lucy Lawless as well. -
@deckingman I think I may have solved the problem but I would like your opinion before I test it!
Ok, I had the z probe trigger height set to 1.9 (G31 P500 Z1.9) which is what I had set originally. I had altered the hotend mount and also added the volcano heater block but had NOT changed this value - what I had done was simply repeatedly homed the z axis and adjusted the height of the inductive sensor to get the nozzle the correct height from the bed when the z height read 0mm. I thought this was ok as it did work as I was able to get some prints. Under these circumstances when I homed the z axis it read 1.9mm when it had finished homing and dropping it to 0mm with the machine control got me the right 1 sheet of paper gap.
What I just did was move the nozzle until it just touched the bed then raised it until the sensor triggered (or untriggered if you like!) and got a difference of 0.7mm. I have changed the G31 to G31 P500 Z0.7 and it homes correctly and dropping it to 0 gives me the 1 sheet gap.
What do you think? And why did it work at all before if this was the problem?
