Duet Wifi keeps wrecking my printer, not happy!
-
@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? -
@dc42 I think I have solved the problem and have posted this reply to deckingman as well:
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? -
Just FYI you can use G30 S-1 to probe and report the height at which the z-probe is actually triggering.
Then you just enter that value into the G31.
I have a macro which does ten pairs of a G1 Z10 and a G30 S-1, which allows me to easily see if I am getting a consistent trigger value.
Frederick
-
@splathammer Dunno is the quick answer. I'm glad you've found something but it doesn't explain the "randomness" of what you were seeing. It also doesn't explain the Z moves mid-print.
Are you by any chance using config-override.g? i.e using M500 to store the G31 trigger height then using M501 in config.g to read it? It's caught people out before. You edit the values in config.g but the behaviour doesn't change because the values are overridden by what is in config-override.g.
-
@deckingman No, as I said nothing custom just the output of the online configuration program. My gcode and mcode knowledge is precisely 0 at the moment so I had to rely on the online tool. if it isnt default in the original software or in the output of the configuration tool its not on my machine.
But it does make sense if at some point when it went to move it referenced the 1.9mm and thought the noz was actually 1.9 below the trigger point and tried to go to it or to 0.6mm layer height from it.
I must admit if I had realised how complex it is to set this thing up compared to the ramps boards I wouldnt have bought it at the moment as I just dont have time for this, I thought it would work pretty much out of the box and I could get fancy with it later when I had the time. Judging by the number of people asking for help with problems I am not the only one! I would definately have upgraded to it in the future when I had time but I am working on new models of my companies products and sorting suppliers, designing circuit boards and basically this is not the time for experimenting! -
@splathammer said in Duet Wifi keeps wrecking my printer, not happy!:
@deckingman No, as I said nothing custom just the output of the online configuration program. My gcode and mcode knowledge is precisely 0 at the moment so I had to rely on the online tool. if it isnt default in the original software or in the output of the configuration tool its not on my machine.
M500 on RAMPS writes some stuff to EEPROM. M500 on Duet writes some stuff to "/sys/config_override.g". So your past ramps knowledge may have caused you to enter a command that created that file without you realizing it...
Take a look, in the "system editor" and see if config_override.g is present or not.
