Help with DWC layer chart

Marco Bona

@droftarts, I ask you why you gave me a very clear explanation yesterday about the problem I had with M207.
This is certainly a simpler thing.
I don't understand why in DWC I can't correctly visualize the timing of the layers, in reality the counting starts about halfway through the printing.
Layer chart.jpg
The other problem is that the same layer number (1850) is always displayed when printing and the Object Height (370) does not change in the file directory either.

As a slicer I am using the latest version of Cura (4.5)
I publish the last file I am printing.
HA_BackLid.gcode .

droftarts

@Marco-Bona When I upload your file, I get the same as you.

However, I think it's caused by this line G1 Z370 F1200 ;go to Z370 in the end gcode:

;---------------------------------
;;; Hyper Additive End Script Begin ;;;
;_________________________________
M117 Finishing Up        ;write Finishing Up

M104 S0                  ;extruder heater off
M140 S0                  ;bed heater off (if you have it)
G1 Z370 F1200            ;go to Z370
G91                      ;relative positioning
G1 E-1 F300              ;retract the filament a bit before lifting the nozzle, to release some of the pressure
G1 E-5 F9000             ;move Z up a bit and retract filament even more
G28                      ;homing all axes
G90                      ;absolute positioning
M84                      ;steppers off

M117 Print finished      ;write Print finished
;---------------------------------------
;;; Hyper Additive End Script End ;;;
;_______________________________________

RepRapFirmware has to parse the gcode file and extract the information it needs from it. However, certain things can trip it up, and cause incorrect information to be used. The G1 Z command in your end gcode is confusing the object height detection. If you change it to:
G1 Z370 F1200 ;E go to Z370
it works correctly:

Is it 7mm high?

Ian

Marco Bona

@droftarts ,That's right, it's 7mm high, how can I go about moving the axis at a high speed to Z370 without causing the DWC to crash?

droftarts

@Marco-Bona said in Help with DWC layer chart:

how can I go about moving the axis at a high speed to Z370 without causing the DWC to crash?

Is this a different issue from what you were talking about in the other thread, ie one motor doesn't move? As I said, you need to find the maximum speed where the Z axis movement is reliable. This will depend on the motors, mostly, as there is a limit to how fast they will step before motor inertia can't keep up with the step rate, and also as a stepper motor turns faster, the amount of torque reduces. So find the speed at which the axis moves reliably, and that will be the limit for the motors you have chosen.

How does DWC 'crash'?

Ian

Marco Bona

@droftarts , sorry I said badly, how can I move the Z at the end of the program without changing object heigh and keeping the layer chart correct?
If there is a solution, otherwise I delete the line in the program.

deckingman

@Marco-Bona said in Help with DWC layer chart:

@droftarts , sorry I said badly, how can I move the Z at the end of the program without changing object heigh and keeping the layer chart correct?
If there is a solution, otherwise I delete the line in the program.

When there is a G1 Z command in your end gcode to raise the print head when the print is complete, and that command is confusing the object height detection, the remedy is to add a comment starting with ;E to that line.

droftarts

@Marco-Bona Like I said, you just have to add 'E' to the comment. You can still do the move. You just have to disrupt the way RRF reads the file to extract information. I'm not sure why it's looking at that, rather than using the statistics at the beginning of the file:

;FLAVOR:RepRap
;TIME:7463
;Filament used: 15.047m, 0m
;Layer height: 0.2
;MINX:-63.44
;MINY:-78.44
;MINZ:0.2
;MAXX:63.44
;MAXY:78.44
;MAXZ:7
;Generated with Cura_SteamEngine 4.5.0

Where MAXZ = 7. I'll ask @dc42.

Also, just noticed; you probably want to flip the order of these two lines, so G90 is before G28:

G28                      ;homing all axes
G90                      ;absolute positioning

Ian

Marco Bona

Very clear, thanks again for the informations

droftarts

@Marco-Bona If you don't want to put 'E' in the comment, you could change the G1 Z370 F1200 move to a relative move, because that's the other way RRF will ignore it. While this may cause a move beyond the length of the carriage (eg if the print stops at 100mm, and you move +370mm, it will ask to move to Z470), but if you have your axis limits set correctly, it shouldn't matter, and it will stop at the Z axis limit, which I assume is Z370. eg:

M117 Finishing Up        ;write Finishing Up

M104 S0                  ;extruder heater off
M140 S0                  ;bed heater off (if you have it)

G91                      ;relative positioning
G1 Z370 F1200            ;go to Z+370
G1 E-1 F300              ;retract the filament a bit, to release some of the pressure
G1 E-5 F9000             ;retract filament even more
G90                      ;absolute positioning

G28                      ;homing all axes
M84                      ;steppers off

M117 Print finished      ;write Print finished

I assume your Z axis homes at maximum Z (Z370) rather than minimum Z (Z0)? If it homes at Z0, you probably only want to home X and Y, not all axes (G28), or the print may strike the nozzle/X axis.

Ian

Marco Bona

The origin of the machine where I have the sensor is at Z374, then it is the IR probe that zeroes the axis for the first layer.
However I corrected the lines in the print file but I continue to have problems with the correct visualization of the layers.
I also tried to restart the machine but I still have some problems.

droftarts

@Marco-Bona Okay, post another file (perhaps the one shown printing) and I'll take a look. Can you remind me what firmware version you are on, by sending M115 and posting the response.

Ian

Marco Bona

@droftarts , The firmware is RRF3.01 RC5 while the version of the DWC is 2.0.7.
If it can help, I noticed that at the end of the print the Layer chart is not reset, so in the next print I believe that I continue to display the layer of the previous print.
The strange thing is that it always stops on the second layer.
I send you a couple of print files, surely I would have been wrong to insert something in cura even if I don't notice anything strange in the gcode.
HA_Bridge01F.gcode
HA_Mast.gcode
HA_Bridge02.gcode

Marco Bona

M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.01-RC5 ELECTRONICS: Duet WiFi 1.02 or later + DueX5 FIRMWARE_DATE: 2020-03-27b3

droftarts

@Marco-Bona Actually, I'm mid-print, and experiencing exactly the same thing with 3.01-RC5 and DWC 2.0.7!

I just checked with @dc42, and he has confirmed this is a bug in RRF 3.01-RC5. It counts the start of the print from when the printer was turned on! Will be fixed in next release. If this is important to you, and you don't need changes in RC5, revert to 3.01 RC4 firmware.

Ian

Marco Bona

@droftarts, Thanks for the reply, you took a heavy weight off me.
Viewing the layers is not a problem, I will wait for the next build, but at least I know that my cura file is correct.
Thanks again!!

chrishamm

If this issue still persists in DSF 2.1.1 and RRF 3.01-RC6, please provide some more details. Do you leave the web interface running in the background or do you close it, open it back up, and then it is no longer updated? How can you reproduce this?

Marco Bona

@chrishamm, I'm using Duet Wifi for the moment, I don't have DSF.

Marco Bona

If it can help, this morning I noticed that after power on, the DWC print starts from layer 0, performs homing, probing and head cleaning cycle but when the first layer (layer0) starts, it is in progress that the layer2 / XX and does not change.
I saw that a new DWC build has come out, tomorrow I install and check it.

Marco Bona

@droftarts, @chrishamm , @dc42, I updated the DWC to 2.1.1, but the problem persists.
I found what causes the error, this line in the startup script

G1 X-137 E25 F500         ;move to X-137 and extrude 25mm of feed stock

creates some problems. It seems that after deleting the first part of the command is working properly

G1 E25 F500         ; extrude 25mm of feed stock

If it cannot be solved, it is not a problem for me to bleed the nozzle while holding the head steady.
I point out that at the beginning of the printing, the estimation of the layers is still incorrect, it is then corrected around the tenth layer.
Layer Time.png

Phaedrux

Can you post the entirety of your slicer start gcode?

One way to work around it is to move some or all of the slicer start gcode into start.g in the /sys folder. Start.g will be run at the start of every print before any of the sliced gcode file is executed. Same can be done with stop.g and the ending slicer gcode. Stop.g is called by M0 when present. So the slicer end gcode can simply have M0.

start.g in combination with other macros called with M98 can allow you to have most of the print prep gcode live outside of the slicer. This has the benefit of making it mostly slicer agnostic so you can use multiple slicers and only need to change the start code in a single place, and it's a workaround for any issues DWC may have when scanning the gcode file.

For example, my start.g does a preheat and homing, then passes off to the slicer start gcode to get the heater temps set for printing, then it calls a macro to prime wipe the nozzle and then starts the print. At the end of the print M0 is run to call stop.g which then does a cool down cycle, etc.