RepRapFirmware 3.0RC2 now available

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

chrishamm

I see, thanks. I'll try to reproduce that.

Danal

I had the same behavior (although I did not capture the error) when moving from Beta 12 to RC1.

Same fix, M997 S0

daavery

@chrishamm same here too from rc1 to rc2