print finished before end of start.g

JawsN3D

@jawsn3d
for posterity

m115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.3 ELECTRONICS: Duet Ethernet 1.02 or later + DueX5 FIRMWARE_DATE: 2021-06-15 21:45:03

m122

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3 (2021-06-15 21:44:54) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-917NK-F2MS4-7J1F4-3SJ6Q-1YUJG
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 23876
Dynamic ram: 71752 of which 320 recycled
Never used RAM 15612, free system stack 130 words
Tasks: NETWORK(ready,24.5%,233) HEAT(delaying,0.0%,314) Move(notifyWait,0.1%,313) DUEX(notifyWait,0.0%,24) MAIN(running,75.4%,445) IDLE(ready,0.0%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:23:23 ago, cause: power up
Last software reset at 2021-09-04 08:06, reason: User, GCodes spinning, available RAM 19236, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 18.7, current 30.9, max 31.5
Supply voltage: min 23.9, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/8/8, gc cycles 0
Driver 0: position 24000, standstill, SG min/max 24/487
Driver 1: position 14000, standstill, SG min/max 0/287
Driver 2: position 6300, standstill, SG min/max 0/950
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0, standstill, SG min/max 4/464
Driver 6: position 0, temperature-warning, standstill, SG min/max not available
Driver 7: position 0, standstill, SG min/max 0/881
Driver 8: position 0, standstill, SG min/max 0/943
Driver 9: position 0, standstill, SG min/max 0/867
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-09-04 09:36:31
Cache data hit count 4294967295
Slowest loop: 19.73ms; fastest: 0.14ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 3.8ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 177260ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 10, completed moves 10, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== DueX ===
Read count 1, 0.04 reads/min
=== Network ===
Slowest loop: 16.96ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
Interface state active, link 100Mbps full duplex

fcwilt

@jawsn3d said in print finished before end of start.g:

@fcwilt

on full reboot i get a heater temp error as it seems to energize the hotend momentarily during bootup.

during a reload/reset that message never appears.

im thinking its time to look at the v3.4 tree and see which of the beta's is solid. i may have a corrupted 3.3?

I am currently only using 3.3. I'm not sure how it would be possible to corrupt it.

Possibly a flaky SD card? Other folks have cured unusual problems with a new card. Easy enough to try - if you've got another card.

I don't get any heater errors on reboot like you are seeing. That worries me a bit. I will take a closer look at your config.g file

Frederick

fcwilt

@jawsn3d

Comment out that M84 in your config.g file and see what happens.

Frederick

JawsN3D

@fcwilt
We're going to go grab a new SD card now. as I've had some Oddities I can't explain. Such as bouncing off the x axis and stop repeatedly. As well as the heater reading 2000 degrees Centigrade during a hard reboot.

I edited out the m84 and now suddenly it's bouncing off of the Y end stop and making lovely noises.

I will retest with a new SD card within the next 2 hours hopefully and be able to report back.

I appreciate the help and third pair of eyes on our problem if you're ever in the west suburbs of Chicagoland give me a holler I owe you as some beers.

fcwilt

@jawsn3d said in print finished before end of start.g:

@fcwilt

I edited out the m84 and now suddenly it's bouncing off of the Y end stop and making lovely noises.

Actually that's good.

It suggests to me the aborted printing was caused by the M84.

And removing it has revealed problems with your Y endstop wiring and/or configuration.

You can use the DWC Object Model viewer to verify the operation of your endstop sensors.

For example:

Endstop Viewing.jpg

Frederick

JawsN3D

@fcwilt
Homing has been good since I finished the new rrf3+ syntax...only in the last 2 weeks ive had it bounced off of and jamming into the end stops a few times before I ever even commented out the m-84...
It actually seems to be doing that more and more.
which is why we're going to at least swap to a different SD card for further testing.

dc42

@jawsn3d do you have any tool change files? You are running T0 before you run G28, so maybe there is command in tpre0.g or tpost0.g that is failing and aborting the print because an axis hasn't been homed. In RRF3.3 and later, tool change files are run regardless of the homed status.

JawsN3D

@dc42
I'll post those momentarily but i believe they are setup properly.
i probablt shouldnt have started futzing with that stuff since im still only using 1 tool and it defaults to T0 iirc.
its pretty much just comments since i was trying to see what would show on the paneldue before i got the "print finished " notification which pops up before start.g finishes

; tpre0.g
; called before tool 0 is selected
;
; generated by RepRapFirmware Configuration Tool v2.1.5 on Sun Jan 12 2020 13:37:35 GMT-0600 (Central Standard Time)
M117 "tpre0 called for"

; tpost0.g
; called after tool 0 has been selected
;
; generated by RepRapFirmware Configuration Tool v2.1.5 on Sun Jan 12 2020 13:37:35 GMT-0600 (Central Standard Time)
; Wait for set temperatures to be reached
M116 P0
M117 "tpost0 called for"

; tfree0.g
; called when tool 0 is freed
;
; generated by RepRapFirmware Configuration Tool v2.1.5 on Sun Jan 12 2020 13:37:35 GMT-0600 (Central Standard Time)
M117 "tfree0 called for"

JawsN3D

@dc42 @fcwilt @deckingman

well gentlemen, i believe ive narrowed further the issue.
new sd card, reloaded all of 3.3, same issue every time.

did a buncha trial and error, and, after commenting out g28 in start.g....and making sure i was parked back at the origin after homing all axis individually.
the print is under way.

same pause at the m117 "g28 begins" comment (g28 disabled)...but proceeded to print after displaying "start.g ends printing should begin"

so somehow after the g28 calls homeall we have it kick out that print finished notification.

i cant see anything out of place but at least i feel safe enough to manually home and start enabling some playtime with g32/g29 and our 4 z screws.

still cant figure out how i have a bed thats tied to the hotend temps/control....but at least i have a cube!

deckingman

@jawsn3d So we know the cause of the error is in the homeall.g file. The next thing would be to comment out parts of it to see exactly where about in the file the error is. One thing I notice is that your homeall file has this:

M280 P0 S160 I1      ; Re-Set the probe

I don't use a Bltouch so I can't be of much help. But in the wiki, the comments for M280 state this - quote:

"RRF3: The I parameter is no longer supported in M280. Instead, specify an inverted pin name in M950 when you create the GPIO port."

So your M280 should not have that "I1" parameter. Whether that could be the cause of your issue, I cannot say.....

dc42

@jawsn3d please post your homeall.g file.

JawsN3D

@dc42 @deckingman

i retested with the cleaned .g files.
I get the m117 the first probe Point message and then right after probing is when it indicates the print is finished. That's well after that... you may be right that is definitely a missed syntax change

; homeall.g
; called to home all axes
;
; generated by james williams for rrf 3.1.1 4-17-2021

M280 P0 S160 I1      ; Re-Set the probe
M117 "PROBE RESET"

; X AXIS HOME
G91               ; relative positioning
M913 X50 Y50         ;SET X Y TO 50% CURRENT
G1 H2 Z5 F5    ; lift Z relative to current position
;G1 H2 X10 F2200    ; go back a few mm on X
G1 H1 X-810 F2200 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 F1000    ; go back a few mm
G1 H1 X-100 F200  ; move slowly to X axis endstop once more (second pass)
;G1 H2 Z-1 F10   ; lower Z again
;G90               ; absolute positioning

;Y AXIS HOME
;G91               ; relative positioning
;G1 H2 Z1 F10    ; lift Z relative to current position
G1 H1 Y-215 F2200 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y5 F600    ; go back a few mm
G1 H1 Y-215 F200  ; move slowly to Y axis endstop once more (second pass)
;G1 H2 Z-5 F5   ; lower Z again NOT USED WITH G30 FOR Z HOME
M913 X100 Y100 ; SET X Y TO 100% CURRENT
M117 "MOTOR FORCE CURRENT AT 100%"
G90               ; absolute positioning
G1 X300 Y175 F6000 ; go to first probe point
M400
M117 "FIRST PROBE POINT"
G30              ; home Z by probing the bed

;G29 S1				; disable and put in start.g    load stored bed height map

; Uncomment the following lines to lift Z after probing
;G91 ; relative positioning
;G1 S2 Z5 F100 ; lift Z relative to current position
;G90 ; absolute positioning

;M280 P3 S90 I1 ; retract mechanical Z probe

Phaedrux

@jawsn3d said in print finished before end of start.g:

G1 H2 Z5 F5 ; lift Z relative to current position

5mm/min is very very slow. That 5mm Z move would take 5 minutes to complete. Is that correct?

JawsN3D

@phaedrux

ah yes it should take a minute. i had it set slower to confirm homeall was being run. i never timed it but it was far longer than the x,y,z individual macros.

i havent gotten around to commenting out homeall from the bottom (g30) up and do some trial and error testing with g28 re-enabled in start.g

we sorta have it pulled apart at the moment, trying to do optical end stops for a "softer" home stop, as well as a second x endstop for the y to home perpendicular to x.

as well as double checking the heaters/hotend wiring to make sure i only have a code problem causing the extra heater display.

so Al or I will update this as soon as possible.

Regards, James W