RepRapFirmware 3.0RC2 now available

[nraynaud]

@dc42 said in RepRapFirmware 3.0RC2 now available:

M122

I see the software got afraid of the boss, here is my log now (I don't think I changed anything, probably a race condition):

19:24:18M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.0RC2 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6JKD4-3S46L-92X3W
Used output buffers: 3 of 24 (16 max)
=== RTOS ===
Static ram: 30516
Dynamic ram: 93164 of which 44 recycled
Exception stack ram used: 256
Never used ram: 7092
Tasks: NETWORK(ready,640) HEAT(blocked,1240) DUEX(suspended,160) MAIN(running,3668) IDLE(ready,156)
Owned mutexes:
=== Platform ===
Last reset 00:08:29 ago, cause: software
Last software reset at 2019-12-29 19:15, reason: User, spinning module GCodes, available RAM 7100 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 35.1, current 35.4, max 36.0
Supply voltage: min 24.0, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2019-12-29 19:24:16
Cache data hit count 1397321660
Slowest loop: 128.51ms; fastest: 0.10ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
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
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 200.23ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
- WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 1
WiFi firmware version 1.23
WiFi MAC address 60:01:94:34:3b:19
WiFi Vcc 3.37, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24312
WiFi IP address 192.168.0.28
WiFi signal strength -59dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
19:22:24Connection established!
19:22:23Disconnected.
19:22:15M98 P"config.g"
Error: M558: Missing Z probe pin name(s)
Error: G31: Invalid Z probe index

all of a sudden it spits the error message. I'll look at the documentation, the error was probably here before.

Thanks.

[nraynaud]

@Phaedrux I am using the old page at /reprap.htm# it's more confortable and shows more things for diagnostics.

@dc42 actually after commenting M558 and G31 I still get the reboot:

19:32:11M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.0RC2 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6JKD4-3S46L-92X3W
Used output buffers: 1 of 24 (17 max)
=== RTOS ===
Static ram: 30516
Dynamic ram: 93164 of which 44 recycled
Exception stack ram used: 256
Never used ram: 7092
Tasks: NETWORK(ready,640) HEAT(blocked,1240) DUEX(suspended,160) MAIN(running,3676) IDLE(ready,156)
Owned mutexes:
=== Platform ===
Last reset 00:00:46 ago, cause: software
Last software reset at 2019-12-29 19:31, reason: User, spinning module GCodes, available RAM 7432 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 34.3, current 35.7, max 36.2
Supply voltage: min 24.0, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2019-12-29 19:32:09
Cache data hit count 105424755
Slowest loop: 128.25ms; fastest: 0.09ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
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
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 116.61ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
- WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 60:01:94:34:3b:19
WiFi Vcc 3.37, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24608
WiFi IP address 192.168.0.28
WiFi signal strength -60dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
19:32:06Connection established!
19:32:05Disconnected.
19:31:41Connection established!
19:31:41Page Load complete!

I deny that this reboot was directly asked by me, I don't see any reboot command in my files, and it is the result of the M98 P"config.g"

[dc42]

@nraynaud said in RepRapFirmware 3.0RC2 now available:

I deny that this reboot was directly asked by me, I don't see any reboot command in my files, and it is the result of the M98 P"config.g"

It's not requested by you, the diagnostics make that clear. Can you pin down which line causes the reboot? For example, take a copy of config.g, and delete about 50% of the lines at the end of the copy. Then use M98 to run that copy. If it still crashes, delete 50% of the lines remaining at the end; otherwise reinstate some lines that you deleted. Then try again, and so on.

[nraynaud]

thanks for your help, I'll start right now.

[nraynaud]

I may have been chasing a red herring:

M552 S0 ; awaken wifi module and set to idle
M587 S"NUMERICABLE-B290" P"PASS" ; send this line to be saved in wifi module
M552 S1 ; connect the wifi module to the network

of course, those lines looks like a reboot.

[dc42]

@nraynaud said in RepRapFirmware 3.0RC2 now available:

I may have been chasing a red herring:

M552 S0 ; awaken wifi module and set to idle
M587 S"NUMERICABLE-B290" P"PASS" ; send this line to be saved in wifi module
M552 S1 ; connect the wifi module to the network

of course, those lines looks like a reboot.

Not a reboot, just turning the network off and on again. The only one of those lines you need is M552 S1.

[nraynaud]

yes.

I don't have a reboot in my configuration, but I still have a weird hang during homing.

is there a way to dump the state of the machine? I feel like it's waiting for something.

here is a log during homing:

21:59:09M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.0RC2 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6JKD4-3S46L-92X3W
Used output buffers: 10 of 24 (16 max)
=== RTOS ===
Static ram: 30516
Dynamic ram: 93164 of which 12 recycled
Exception stack ram used: 488
Never used ram: 6892
Tasks: NETWORK(ready,640) HEAT(blocked,1184) DUEX(suspended,160) MAIN(running,3676) IDLE(ready,156)
Owned mutexes:
=== Platform ===
Last reset 00:27:43 ago, cause: software
Last software reset at 2019-12-29 21:31, reason: User, spinning module GCodes, available RAM 6788 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 33.9, current 35.2, max 35.7
Supply voltage: min 24.0, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 359/1023
Driver 1: standstill, SG min/max 344/1023
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max 56/1023
Driver 4: standstill, SG min/max 0/196
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2019-12-29 21:59:08
Cache data hit count 4294967295
Slowest loop: 8.01ms; fastest: 0.09ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 165, MaxWait: 1652015ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 8, completed moves: 3, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 1
Stack records: 2 allocated, 1 in use
Movement lock held by http
http is doing "G53 G1 Y-415 F360 H1" in state(s) 0 8, running macro
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 15.86ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
- WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 60:01:94:34:3b:19
WiFi Vcc 3.37, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 19376
WiFi IP address 192.168.0.28
WiFi signal strength -57dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
21:58:58G28 Y

[dc42]

@nraynaud said in RepRapFirmware 3.0RC2 now available:

http is doing "G53 G1 Y-415 F360 H1" in state(s) 0 8, running macro

Looks like it thinks it is executing the Y homing move and waiting for the endstop to trigger. Maybe the Y motor current or motor current percentage is set to zero? Or the Y motor mapped to the wrong driver?

[nraynaud]

; homey.g
; called to home the Y axis
;
; generated by RepRapFirmware Configuration Tool on Wed Nov 15 2017 23:36:04 GMT-0700 (MST)

; Lift Z relative to current position
G91
G1 Z2 F6000
G90

; M98 P"outdanger.g"

; Move quickly to Y axis endstop and stop there (first pass)
G53 G1 Y-415 F10000 H1

; Go back a few mm
G53 G1 Y3 F40000

; Move slowly to Y axis endstop once more (second pass)
G53 G1 Y-415 F360 H1

G53 G1 Y2 F10000

; Lower Z again
G91
G1 Z-2 F6000
G90

it has moved and done the coarse homing right before that.

executing it line by line seems to work ok:

22:48:41G90
22:48:35G1 Z-2 F6000
22:48:28G91
22:48:22G53 G1 Y2 F10000
22:48:16G53 G1 Y-415 F360 H1
22:48:05G53 G1 Y3 F40000
22:47:56G53 G1 Y-415 F10000 H1
22:47:47G90
22:47:40G1 Z2 F6000
22:47:32G91
22:47:31Connection established!

I really don't know. running `M98 P"homey.g"' triggers the issue too.

edit: I get the bug both with and without the pullup, but I don't see any influence of this setting the web interface anyways (the switch works perfectly in my tests in the web interface)

[dc42]

You really ought to be using relative movement commands with G1 H1. Also, i still donm;'t understand why you think you need the G53 prefixes. What happens if you use relative movement and no G53 prefixes?

[nraynaud]

In my limited testing (the software side of this project feels like being a ball at a rugby game, everything is just hard, I don't know what conclusion actually hold), homing without G53 was placing the tool center at the switch trigger point instead of placing the machine zero there.

I will look into the relative movements, I need to find the original example files, thanks.

[nraynaud]

I found it! Thanks for your help.

I need more time or more distance to back out of the switches after the coarse homing (what's weird is that I had the same issue in X and Y). That's why I couldn't find the issue line by line.

have you de-bounced the switches or changed the execution order?

[dc42]

@nraynaud said in RepRapFirmware 3.0RC2 now available:

I found it! Thanks for your help.

I need more time or more distance to back out of the switches after the coarse homing (what's weird is that I had the same issue in X and Y). That's why I couldn't find the issue line by line.

have you de-bounced the switches or changed the execution order?

There has been a change in behaviour when you execute a homing move and the switch is already triggered. Previously, the move would be started and when the first microstep was due, at that point it would recognise that the switch was triggered. Now it checks the switches before starting the move. If they are triggered, it should cancel the move, unless there are other motors being homed using different switches. It sounds to me that it is behaving as if there is another switch waiting to be triggered.

[stewwy]

Is manual bed probing working in 3.0RC2, (my IRprobe is not working,a different problem). I've changed the probe type to P0. This worked in 2.05 giving me the manual menu in DWC/Paneldue but not in 3.0RC2. Is there something else I need to do? I have noticed that the Z endstop is showing as constantly triggered.

EDIT: It gave me this error--
G28
Error: SetPositions called when DDA ring not empty

[blt3dp]

Is it up on the unstable package server?

[chrishamm]

The latest version on the unstable package feed is now RC2+1 because I found another DSF-related issue involving macro files. If anyone wants to compile it, those changes are on my v3-chrishamm branch of RRF.

[chas2706]

@chrishamm
Hi are you aware of M291 error "command not known" in DSF

[chrishamm]

Yes, see https://github.com/chrishamm/DuetSoftwareFramework/tree/dev#known-issues

[chas2706]

Ok cheers!

[blt3dp]

@chrishamm

Doing sudo apt-get update and then apt-get upgrade gives this error on reprap firmware package.

Setting up reprapfirmware (1.2.2.0-1) ...
[error] Failed to connect to Duet
   System.IO.IOException: Error 16. Cannot put line into event mode.
   at LinuxDevices.InputGpioPin..ctor(String devNode, Int32 pin, String consumerLabel) in /home/christian/duet/DuetSoftwareFramework/src/LinuxDevices/InputGpioPin.cs:line 60
   at DuetControlServer.SPI.DataTransfer.Init() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 65
   at DuetControlServer.SPI.Interface.Init() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/SPI/Interface.cs:line 65
   at DuetControlServer.Program.Main(String[] args) in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/Program.cs:line 92

Everything else updated except for the firmware, still on 3.0RC1

I noticed the Duet3Firmware_MB6HC.bin on the virtual SD card had today's timestamp so I ran M997 and it updated, now it shows 3.0RC2+1