Thanks! If it's still a problem, please post your pause.g and resume.g files, and any other macro files that they call.
Thank you for your participation here. I will run tests as soon I have more time. (Family, but maybe tomorrow which actually means today) I did already upgrade to 3.01-RC10 but did not test with that firmware. What I did today was changing the UI (based on Duet Web Control 2.1.5) to - show 3 digits in Z. - And to show more of the object model. (Compensation, Misc, Workspace number, Tools number) - I split up the position group to show me both at the same time. (Machine and Tool Position) With this modded UI I will hopefully see what changes. Live. Thoughts about future testing: - I tricked the printer into probing this: This is fully negative. No zeroes, the whole file is automatically generated. I want to retest if that shift changes the toolchange offset. - I run 4 tools but the fourth not connected. Maybe that confuses the firmware? Dont know. I will test removing the not connected tool and all configurations of it. - I run my toolchanger on other stepper driver numbers than original. I switched the ports because of the cable lengths. I guess that is not triggering my bug but who knows. I am very happy that I might have one problem less with the RC10. I will test this as soon as possible! Thank you
I find the problem still occurs. In this report, I'm testing only pause and resume. The only tool change is to collect Tool 0 and return it at the end of the print. Here's my setup. The job gcode Code: M929 P"z-offset.log" S1 ; start log M98 P"homeall.g" G29 T0 G1 X0 Y100 Z3 F99999 G1 X300 F500 G1 X0 F500 G1 X300 F500 G1 X0 F500 T-1 G1 X150 Y-35 F99999 M929 S0 ;stop log At the start of the job, after the tool selection, DWC reports Z as 3.00 as expected. As the tool then moves slowly from left to right, I run a series of pause/resumes. Over the space of 8 or so repeats, Z drops from 3.00 to 2.92. I attempt to log output using echo in pause/resume, sadly these only report to DWC, and this seems to be inconsistent (sometimes the whole echo string does not make it); it would be great if they also reported to the log file, or that there was some method to construct a string to be output in the log file. Anyway, the log file does show the proof that Z is dropping, which due to rounding only begins to output once Z is less than 2.95: Code: 2020-04-26 09:02:50 Event logging started 2020-04-26 09:04:12 70 points probed, min error -0.315, max error 0.042, mean -0.152, deviation 0.096 Height map saved to file 0:/sys/heightmap.csv 2020-04-26 09:04:27 Resume state saved 2020-04-26 09:04:32 Error: in file macro line 15 column 4: Q0: unknown value 2020-04-26 09:04:33 Printing paused at X100.0 Y100.0 Z3.0 C90.0 2020-04-26 09:04:38 Printing resumed 2020-04-26 09:04:42 Resume state saved 2020-04-26 09:04:53 Error: in file macro line 15 column 4: Q0: unknown value 2020-04-26 09:04:54 Printing paused at X200.0 Y100.0 Z3.0 C90.0 2020-04-26 09:05:01 Printing resumed 2020-04-26 09:05:08 Resume state saved 2020-04-26 09:05:11 Error: in file macro line 15 column 4: Q0: unknown value 2020-04-26 09:05:12 Printing paused at X266.7 Y100.0 Z3.0 C90.0 2020-04-26 09:05:16 Printing resumed 2020-04-26 09:05:20 Resume state saved 2020-04-26 09:05:21 Error: in file macro line 15 column 4: Q0: unknown value 2020-04-26 09:05:22 Printing paused at X300.0 Y100.0 Z3.0 C90.0 2020-04-26 09:05:25 Printing resumed 2020-04-26 09:05:31 Resume state saved 2020-04-26 09:05:35 Error: in file macro line 15 column 4: Q0: unknown value 2020-04-26 09:05:36 Printing paused at X233.3 Y100.0 Z3.0 C90.0 2020-04-26 09:05:40 Printing resumed 2020-04-26 09:05:44 Resume state saved 2020-04-26 09:05:50 Error: in file macro line 15 column 4: Q0: unknown value 2020-04-26 09:05:51 Printing paused at X166.7 Y100.0 Z2.9 C90.0 2020-04-26 09:05:54 Printing resumed 2020-04-26 09:05:56 Resume state saved 2020-04-26 09:06:04 Error: in file macro line 15 column 4: Q0: unknown value 2020-04-26 09:06:05 Printing paused at X100.0 Y100.0 Z2.9 C90.0 2020-04-26 09:06:08 Printing resumed 2020-04-26 09:07:56 Event logging stopped I recall, but have not repeated, that if I remove the G29 line and reset the machine, this dropping of Z will not occur. Here's my pause.g: Code: echo "start of pause.g" echo "machinePosition : " ^ move.axes[2].machinePosition ^ ":" ^ " userPosition : " ^ move.axes[2].userPosition echo "difference : " ^ (move.axes[2].machinePosition-move.axes[2].userPosition) M83 ; relative extrusion G10 ; fw retract G91 ; relative motion G1 Z5 F1200 ; up 5mm G90 ; absolute motion ; swap spot G1 X150 Y-30 F50000 ; eject if if sensors.analog[state.currentTool+1].lastReading > 30 if state.currentTool=3 M98 P"eject-hemera.g" else M98 P"eject.g" M18 E0 ; disable extruder motors to permit refeeding with wheel M18 E1 ; disable extruder motors to permit refeeding with wheel M18 E2 ; disable extruder motors to permit refeeding with wheel M18 E3 ; disable extruder motors to permit refeeding with wheel echo "end of pause.g" echo "machinePosition : " ^ move.axes[2].machinePosition ^ ":" ^ " userPosition : " ^ move.axes[2].userPosition echo "difference : " ^ (move.axes[2].machinePosition-move.axes[2].userPosition) and my resume.g Code: ; Resume macro - executed manually from the web interface or control panel to resume printing following a pause for a filament change. echo "start of resume.g" echo "machinePosition : " ^ move.axes[2].machinePosition ^ ":" ^ " userPosition : " ^ move.axes[2].userPosition echo "difference : " ^ (move.axes[2].machinePosition-move.axes[2].userPosition) ;prime nozzle if sensors.analog[state.currentTool+1].lastReading > 40 if state.currentTool=3 M98 P"prime-hemera.g" else M98 P"prime.g" G10 G1 R1 X0 Y0 Z5 F99999 G1 R1 Z0 F500 M83 ; relative extruder moves if sensors.analog[state.currentTool+1].lastReading > 40 G11 ; fw un-retract echo "end of resume.g" echo "machinePosition : " ^ move.axes[2].machinePosition ^ ":" ^ " userPosition : " ^ move.axes[2].userPosition echo "difference : " ^ (move.axes[2].machinePosition-move.axes[2].userPosition) The console reports from the echoing are as follows: Code: 4/26/2020, 9:08:00 AM Finished printing file 0:/gcodes/nibbels.gcode, print time was 0h 3m 4/26/2020, 9:06:11 AM Printing resumed 4/26/2020, 9:06:10 AM start of resume.g machinePosition : 12.889: userPosition : 7.932 difference : 4.957 end of resume.g machinePosition : 12.889: userPosition : 2.932 difference : 9.957 4/26/2020, 9:06:08 AM start of pause.g machinePosition : 7.889: userPosition : 2.932 difference : 4.957 Error: in file macro line 15 column 4: Q0: unknown value Printing paused at X100.0 Y100.0 Z2.9 C90.0 4/26/2020, 9:05:59 AM Resume state saved 4/26/2020, 9:05:57 AM Printing resumed 4/26/2020, 9:05:56 AM start of resume.g machinePosition : 12.900: userPosition : 7.943 difference : 4.957 end of resume.g machinePosition : 12.900: userPosition : 2.943 difference : 9.957 4/26/2020, 9:05:54 AM start of pause.g machinePosition : 7.900: userPosition : 2.943 difference : 4.957 Error: in file macro line 15 column 4: Q0: unknown value Printing paused at X166.7 Y100.0 Z2.9 C90.0 4/26/2020, 9:05:48 AM Resume state saved 4/26/2020, 9:05:43 AM Printing resumed 4/26/2020, 9:05:42 AM start of resume.g machinePosition : 12.910: userPosition : 7.953 difference : 4.957 end of resume.g machinePosition : 12.910: userPosition : 2.953 difference : 9.958 4/26/2020, 9:05:39 AM start of pause.g machinePosition : 7.910: userPosition : 2.953 difference : 4.957 Error: in file macro line 15 column 4: Q0: unknown value Printing paused at X233.3 Y100.0 Z3.0 C90.0 4/26/2020, 9:05:34 AM Resume state saved 4/26/2020, 9:05:29 AM Printing resumed 4/26/2020, 9:05:27 AM start of resume.g machinePosition : 12.927: userPosition : 7.969 difference : 4.957 end of resume.g machinePosition : 12.927: userPosition : 2.969 difference : 9.958 4/26/2020, 9:05:25 AM Printing paused at X300.0 Y100.0 Z3.0 C90.0 4/26/2020, 9:05:24 AM start of pause.g machinePosition : 7.927: userPosition : 2.969 difference : 4.957 Error: in file macro line 15 column 4: Q0: unknown value 4/26/2020, 9:05:23 AM Resume state saved 4/26/2020, 9:05:19 AM Printing resumed 4/26/2020, 9:05:18 AM start of resume.g machinePosition : 12.936: userPosition : 7.978 difference : 4.957 end of resume.g machinePosition : 12.936: userPosition : 2.978 difference : 9.958 4/26/2020, 9:05:15 AM Printing paused at X266.7 Y100.0 Z3.0 C90.0 4/26/2020, 9:05:14 AM start of pause.g machinePosition : 7.936: userPosition : 2.978 difference : 4.957 Error: in file macro line 15 column 4: Q0: unknown value 4/26/2020, 9:05:12 AM Resume state saved 4/26/2020, 9:05:04 AM Printing resumed 4/26/2020, 9:05:03 AM start of resume.g machinePosition : 12.942: userPosition : 7.985 difference : 4.957 end of resume.g machinePosition : 12.942: userPosition : 2.985 difference : 9.957 4/26/2020, 9:04:58 AM Printing paused at X200.0 Y100.0 Z3.0 C90.0 4/26/2020, 9:04:57 AM start of pause.g machinePosition : 7.942: userPosition : 2.985 difference : 4.957 Error: in file macro line 15 column 4: Q0: unknown value 4/26/2020, 9:04:45 AM Resume state saved 4/26/2020, 9:04:42 AM Printing resumed 4/26/2020, 9:04:41 AM start of resume.g machinePosition : 12.958: userPosition : 8.000 difference : 4.958 end of resume.g machinePosition : 12.958: userPosition : 3.000 difference : 9.958 4/26/2020, 9:04:36 AM Printing paused at X100.0 Y100.0 Z3.0 C90.0 4/26/2020, 9:04:35 AM start of pause.g machinePosition : 7.958: userPosition : 3.000 difference : 4.957 Error: in file macro line 15 column 4: Q0: unknown value 4/26/2020, 9:04:31 AM Resume state saved 4/26/2020, 9:04:16 AM 70 points probed, min error -0.315, max error 0.042, mean -0.152, deviation 0.096 Height map saved to file 0:/sys/heightmap.csv 4/26/2020, 9:02:54 AM File 0:/gcodes/nibbels.gcode selected for printing As you can see here, console echoing is somewhat flaky. Sometimes echoing from resume.g does not appear. The macro error referring to Q0 does not always appear. From what I can tell, this Q0 error referrs to a 'resurrect.g' file that the firmware writes, but which does not persist, so I do not have one, but I suspect I could grab one during a pause if that helps. For completeness, you will want any other macro that could be called in the entire process. Given that the tool is cold for this test, prime and eject macros are not executed. T0 is selected, but the error occurs before tfree0 so I'll leave that out. tpre0.g Code: ; tpre0.g ; called before tool 0 is selected ;Unlock Coupler M98 P"/macros/Retraction-V6-Bowden.g" M98 P"/macros/Coupler - Unlock" M400 ;Move to location G53 G1 X-5.8 Y200 F50000 ;Move in G53 G1 Y239 F50000 ;Collect G53 G1 Y242.4 F500 ;Close Coupler M98 P"/macros/Coupler - Lock" ;WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! ;if you are using non-standard length hotends ensure the bed is lowered enough BEFORE undocking the tool! G91 G1 Z10 F1000 G90 ;Move Out G53 G1 Y165 F4000 tpost0.g Code: ; tpost0.g ; called after tool 0 has been selected if sensors.analog[1].lastReading > 30 ;; move in G0 X-33 Y200 F50000 ;heatup M116 P0 ;pickup current fan speed setting M106 R1 ;prime nozzle M98 P"prime.g" Retraction-V6-Bowden.g Code: M207 S5.5 R0.3 F6500 T6500 Z0.5 Coupler-Unlock Code: G1 C250 F50000 M400 Coupler-Lock Code: G1 C90 F50000 M400 Hopefully this is everything required to replicate the issue. Fingers crossed.
I upgraded the bed heater to be RC10 compatible this evening. First I run my default test-file again. The behaviour did not change. MachinePosition[Z] - ToolPosition[Z] always seems to have the value of the Z-Offset of the tool. But still both get shifted when I change the tools. I will try to insert G4 S5 at start and end of all my tool-change-config-files (tpreN.g, tpostN.g, tfreeN.g) Maybe I see where the shift happens exactly.
I eventually found the cause of the problem. In the automatic move back to the restore point, it wasn;t allowing for the tool XY offset when calculating the bed compensation. Now fixed in the source code.
Interesting. So it was taking the bed comp from a fixed point instead? Fixed to where? If it was using 0,0, that should be my zero position, so I guess that wasn't it. In any case, great to know that this will be resolved.
It was taking the bed comp from the head reference point, which on a TC is normally configured as the location of the Z switch. So any difference in the height map between the point at which the print paused and the position of the Z switch when the nozzle is over that same point would be added to the Z position.
@dc42 , @Spoon Unit I just printed my test part which always failed except when - the auto bed leveling was off or - the height map only contained zeroes It looks like you solved my issue with 3.01 RC11! Thank you so much! My toolchanger is finally a working and precise toolchanger Details: I had to adjust my toolchange code to conditional "if homed" like written here: https://github.com/dc42/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md That is how it looks: https://github.com/Nibbels/e3d-tool...f45fc#diff-8ce5dfd486aac1a6d5ab670b3cac1d95R5 Then I did a full rescan of the height map with Z homed at the most top point of my bed. After that I started the print and everything works as expected. Problem 1: The shift when changing the tools is gone. I just saw: "Tool 1: 0.2mm Tool 2: 0.2mm Tool 3: 0.2mm Layerchange to 0.4mm Tool 1: 0.4mm and so on." Problem 2: Pause and resume does not shift my level of Z anymore. Plus both Symtoms are removed: - The display within the duet web controll shows the layer height as expected. - The layers look even now.
Sorry for not replying sooner. Been a bit busy lately. So originally I carefully measured per the instructions. I adjusted the tool 1 offset for optimal squish on the 1st layer and then set the Z offsets for tools 2-4 per tool 1 using the printed test pattern. But overtime I eventually found (after printing with a prime pillar) that it seems to work better having all 4 tools with the same Z offset. All 4 tools are V6s (the V6s that we got are really good good when it comes to minimal variation in Z length). Sorry I'm not familiar with the TitanAeros and I avoid 3mm diameter filament extruders at all cost. Try printing a 4 color object with a prime pillar. If the layers are not exactly the same height it will have crashing problems. I'm still using RRF version 2.04. Is there a good reason to go to 3.0? Unless there's added value to the FW upgrade I'd rather not bother.
Ultimately, the upgrade will cost you some time. No one can figure out if that's worth your time except you. Best thing I can suggest is to have a look at the What's New documentation that dc42 writes: For version 2 up to 2.05: https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md The so far on RRF: https://github.com/dc42/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md You'll find many bug fixes and feature additions, not all relating to your needs. There have been countless changes to DWC also in that time. I guess the primary reason I decided to make the switch was to gain access to the potential for control with conditional GCODE. https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands. This allows me to pick up a tool, but then not wipe it because it's clearly not hot enough to be extruding yet, as an example. You can find many interesting examples of what you might implement using conditional GCODE on the Duet forum (https://forum.duet3d.com/search/?term=conditional&in=titlesposts). Control of this nature is keyed alongside the developing object model. An early version can be found here - https://duet3d.dozuki.com/Wiki/Object_Model_of_RepRapFirmware, but there's a lot more added since that documentation was created. Another interesting feature in RRF3 is to be able to cancel 1 of a number of copies of a print. Let's say you're trying to print 10 of the same thing and one of those prints comes loose. In RRF3 the copy that failed can be removed from the printing process provided the GCODE is marked up sufficiently. At present, there's no associated UI to add with the removal, but that will eventually come.