Duet Wifi keeps wrecking my printer, not happy!
-
@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
-
This is a massive long shot, but I have seen a printer (not a Duet) execute a downwards move, when instructed in gcode to move slightly up. In fact it's even repeatable. My Mendel Max 3, using a RAMBO will do the following:
Home all routine:
Home X
Home Y
Move Z up 10
Move XY to center of bed
Move Z down until probe reports
Move Z up 1... any intervening commands are irrelevant, unless Z shifts up or down.
Manual 'move Z up' less than 9 will result in a downward movement.
For example, Manual 'move z up 1' will result in moving Z down 8 ... a crash of about 6mm. Which isn't fun.
-
@streamliner said in Duet Wifi keeps wrecking my printer, not happy!:
..............
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
I'm hardly ever in a position where I can just drop everything and have a chat but you can always email me. Of course, I can only discuss what works (or doesn't work) with a 5 colour Diamond mixing hot end. It may or may not read across to the quad.
-
@deckingman Just tried to update the firmware. Note the use of the word "TRIED". It detected I had uploaded the combined firmware file, asked if I wanted to install it then said it couldnt find it. Tried it multiple times, tried putting "-2.01" after the name and it said it couldnt rename it. Tried to do the upload all at once install variation and it instantly upgraded the web control without asking. Took out the sd card, deleted the firmware then tried again, same crap about not being able to find the file. So it detected the file had been uploaded, knew what it was but says it cant find it, wow impressive!
I am not going to try one of the "fallback" installation methods, I am going to try printing a scaled down version of my last print attempt and see what happens.
I did check the sd card and its ok.
I belong to the local pistol shooting club and if i have many more problems with this thing it is going to make a very nice if rather expensive target ; ) -
What version were you updating from and to?
Certain combos require specific procedures.
Aside from those few special cases I have found updating to be reliable and that is on all four of my printers.
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
@deckingman I just got it to install! I suddenly noticed the error message said it couldnt find "DuetWiFiFirmware.bin" and the file is named Duet2CombinediFirmware.bin on github AND in the installation instructions. What a load of C··P!
-
@fcwilt Just got it to install, the error message I got listed a different name than the name of the file you download from github. I renamed it to the name in the error message and it installed and is running. It was 1.9 to 2.01
The download is Duet2CombinedFirmware.bin but it has to be renamed to DuetWiFiFirmware.bin
Would be nice if they included that in the ······· instructions! -
@splathammer said in Duet Wifi keeps wrecking my printer, not happy!:
@deckingman I just got it to install! I suddenly noticed the error message said it couldnt find "DuetWiFiFirmware.bin" and the file is named Duet2CombinediFirmware.bin on github AND in the installation instructions. What a load of C··P!
Hi. Sorry I've been busy all day otherwise I would have stepped in earlier and saved you some grief. I see you've got it sorted and from now on, you'll be able to use the combined firmware without any problems. It changed around 1.21. It is documented here and in the release notes https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware#Section_Upgrading_a_Duet_WiFi_or_Ethernet_to_firmware_1_21_or_later_from_1_20_or_earlier.
I've been caught out myself before when upgrading firmware and I've now learned to always read the release notes which you can find here. https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md
Suggest you bookmark that link and refer to it whenever you upgrade the firmware.
I'll save you some time with the next thing you are going to run into which is that you can't jog or move axes until they are homed, and when you try you'll get an error message "insufficient axes homed". It's in the release notes and was introduced as a user request. There are a couple of ways around it. The easiest IMO is to add M564 H0 to config.g which will restore the old behaviour. If not and if you try to home X or Y and those homing macros have a Z move in them, you'll need to add S2 to those Z moves.
It is all in the release notes.
Cheers
