RepRapFirmware 3.0RC2 now available

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

jay_s_uk

@blt3dp

I had that happened as well.
If you run M997 S0, the firmware is still updated

blt3dp

@jay_s_uk said in RepRapFirmware 3.0RC2 now available:

@blt3dp

I had that happened as well.
If you run M997 S0, the firmware is still updated

Yep, I was just doing an edit. That's exactly what I did.

chrishamm

Error code 16 means Device or resource busy. From what version did you upgrade?

jay_s_uk

@chrishamm RC2

chrishamm

I mean from what DSF version

blt3dp

@chrishamm said in RepRapFirmware 3.0RC2 now available:

I mean from what DSF version

I was coming from DSF version 1.2.1.0 with with 3.0RC1

Unpacking duetsoftwareframework (1.2.2.0) over (1.2.1.0)
Unpacking reprapfirmware (1.2.2.0-1) over (1.2.1.0-1)
Unpacking duettools (1.2.2.0) over (1.2.1.0)
Unpacking duetcontrolserver (1.2.2.0) over (1.2.1.0)
Unpacking duetruntime (1.2.2.0) over (1.2.1.0)

jay_s_uk

@chrishamm 1.2.1.0 for me too