Duet Wifi keeps wrecking my printer, not happy!
-
@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.
-
@splathammer Yes I feel you pain. By the way, I have no affiliation with Duet - I'm just a user like you (although it's fair to say that I am a huge fan of the product).
I think you've been unlucky that's all. There are a lot of users who get the board and it works out of the box. Of course it may seem like there are a lot of users with problems on these forums but those who don't have problems don't bother to post. Or if they do post, it's just a one off question in the majority of cases. Hang on in there if you can. Things are moving in the right direction. We'll get to the bottom of it between us and you'll end up a happy bunny. -
@deckingman I do really like the board or I wouldnt still be trying to get it working properly!
I have a question, is there a command which will create a running log which will constantly write to file? Like last time I will be watching todays print like a hawk ready to pull the plug if there is a problem so I need to know if there is a way of logging which wont be lost when the board looses power and which will have the last few commands saved. -
@deckingman By the way thanks for all the help, you have spent so much time on this I did actually think you worked for them!
One thing that would help is if the temperature here dropped, its been 37C - 42C in the shade here for a couple of months and it is getting pretty tiring, especially as sleep is really difficult. of course 2 of our 3 aircons decided to pack up in the first couple of weeks and as they are mounted way up on our 3 storey house I need to hire a cherry picker to put in new ones which will have to wait until autumn. The heat makes thinking hard and frustration/anger easy! -
@splathammer I'm no expert on logging - DC42 is the man. I'd imagine that constantly writing to say the SD card would bugger things up, and there is also limited memory available to hold a log file. The only thing do know is that M122 reports a load of stuff which must have been logged. So running that command after things go pear shaped and reporting back what it shows would help people like DC42 diagnose what's happening.
For info - DC42 writes the firmware and his company is one half of Duet. Tony and Roland are the other half of Duet. The rest of us are all just users (plus a couple of distributors) trying to help each other.
Yes, sleep deprivation is a killer. Every Mole hill becomes a mountain.
-
@deckingman Hey Ian, I hope you're well! I've had to go a bit dark on the forums and email lately due to our multiple impending launches. Just skimmed over this and I wanted to indicate one thing about logging. Logging, similar to the way most software systems/operating systems handle it, is done at prescribed 'levels' on the duet.
If you send an M111 you'll get a list of modules; On a Duet Maestro, this is what I am provided:
M111
Debugging enabled for modules: none(15)
Debugging disabled for modules: Platform(0) Network(1) Webserver(2) GCodes(3) Move(4) Heat(5) DDA(6) Roland(7) Scanner(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) WiFi(14)While enabling all of the modules will most certainly fill your sdcard quickly, my recent troubleshooting has really only utilized Platform and Move; and with intense testing my Log file is only a few kb in size. I personally will likely keep my 'Platform' logging set to on no matter what.
I don't suppose your schedule is open today for a bit of a chat, is it? I wanted to discuss some firmware retract stuff with you, as well as some recent slicing milestones.
Thanks,
David@M3D
