RepRapFirmware 3.0RC2 now available
-
@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.
-
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 -
Is it up on the unstable package server?
-
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.
-
@chrishamm
Hi are you aware of M291 error "command not known" in DSF -
-
Ok cheers!
-
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
-
I had that happened as well.
If you run M997 S0, the firmware is still updated -
@jay_s_uk said in RepRapFirmware 3.0RC2 now available:
I had that happened as well.
If you run M997 S0, the firmware is still updatedYep, I was just doing an edit. That's exactly what I did.
-
Error code 16 means Device or resource busy. From what version did you upgrade?
-
@chrishamm RC2
-
I mean from what DSF version
-
@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)
-
@chrishamm 1.2.1.0 for me too
-
I see, thanks. I'll try to reproduce that.
-
I had the same behavior (although I did not capture the error) when moving from Beta 12 to RC1.
Same fix, M997 S0
-
@chrishamm same here too from rc1 to rc2
-
I believe I know why it's happening. I've added a delay to the RRF package script to work-around this problem. Please let me know if that fixes it.