Unofficial RRF 3.4.0beta7+4 files

dc42

@joeko I'm sorry your BLTouch didn't deploy. What type of Duet main board or expansion board is the BLTouch connected to? I am currently investigating an issue with M280 when the port is on an CAN-connected expansion or tool board.

dc42

RRF 3.4.0beta7+4 has the following bug: the M280 command does not work properly if the servo or BLTouch device is connected to a Duet 3 expansion or tool board. In particular, this will prevent a BLTouch attached to a tool board or expansion board from deploying.

I expect to have a fix for this later today. [Edit: see next post.]

dc42

I have replaced the Duet 3 MB6HC and Duet 3 Mini main board binaries at https://www.dropbox.com/sh/i5vox3xmkd55gaz/AAC19mI0WEC5GmEjLOBRbKs-a?dl=0 with build 3.4.0beta7+5. This corrects the problem with servos and BLTouch connected to expansion and tool boards.

joeko

@dc42 said in Unofficial RRF 3.4.0beta7+4 files:

I have replaced the Duet 3 MB6HC and Duet 3 Mini main board binaries at https://www.dropbox.com/sh/i5vox3xmkd55gaz/AAC19mI0WEC5GmEjLOBRbKs-a?dl=0 with build 3.4.0beta7+5. This corrects the problem with servos and BLTouch connected to expansion and tool boards.

yes this combination i use.
duet3 6hc with toolboard

MikeDC

@dc42 thankyou
I have updated to b7+5,
i will let you know how I get on later

oozeBot

@dc42 Curious if anything was done about the chamber heater faults we've reported in 3.3b7+5? I see some changes from around the same time you released it in the repository, but don't know what they targeted. Thanks

PetrKroupa

@dc42 Looks like there's something wrong with calling filament_error.g. I'm for sure have both files (with _ and with -) but still pause.g is called when fillament error. (6HC + 1LC + SBC) In beta7 work OK. beta7+5 no.

Argo

@joeko
It does not help you now but I lower my currents to about 60% during homing or probing moves so the motors never have enough torque to cause damage.

dc42

@oozebot said in Unofficial RRF 3.4.0beta7+4 files:

@dc42 Curious if anything was done about the chamber heater faults we've reported in 3.3b7+5? I see some changes from around the same time you released it in the repository, but don't know what they targeted. Thanks

We've reduced the occurrence of spurious heater files in RRF 3.4b7 and further increased the tolerances allowed before reporting a heater fault on a bed or chamber heater in 3.4beta7+2.

When you turn the chamber heater on, how long does it take before the associated sensor shows a temperature rise; and at what rate does the temperature then rise? You can measure these when you start a heater tuning cycle.

dc42

@petrkroupa said in Unofficial RRF 3.4.0beta7+4 files:

@dc42 Looks like there's something wrong with calling filament_error.g. I'm for sure have both files (with _ and with -) but still pause.g is called when fillament error. (6HC + 1LC + SBC) In beta7 work OK. beta7+5 no.

Thanks, I've put this on my list to try to reproduce.

oozeBot

@dc42 The fault always seems to occur 15-20 minutes after heating. The temp begins rising almost immediately upon enabling the heater, but does take a long time to reach the target temperature.

Please watch this 25s movie I've linked below where it was ramping to 60c. Note the temp jumps around by .1-.2c. That's pretty typical while heating and what I feel is the cause of the fault.

https://vimeo.com/665779274

What I can't wrap my head around is the error states Heater 0 faults, but Heater 2 is the chamber and is what really faults. Maybe that is an unrelated issue..

RomeoFox

Have installed the firmware due to file upload issues. Now I get the following errors on every move which make it impossible to work:

Error: Driver 0.2 error: ok
Error: Driver 0.3 error: ok
Error: Driver 0.0 error: ok
Error: Driver 0.1 error: ok
Error: Driver 0.5 error: ok

Furthermore an event notification window appears.

FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.4.0beta7+6 ELECTRONICS: Duet 3 MB6HC v1.01 or later FIRMWARE_DATE: 2022-01-13 18:24:07

dc42

@romeofox this is now fixed in the 3.4.0beta7+7files at https://www.dropbox.com/sh/i5vox3xmkd55gaz/AAC19mI0WEC5GmEjLOBRbKs-a?dl=0.

OwenD

In 3.4.0b7+7, filament_error.g is not being called.
pause.g is run immediately.
It was working correctly in earlier 3.4b versions

gloomyandy

@owend I think the file has gone back to filament-error.g with a "-" rather than "_" do you have one of those?

OwenD

@gloomyandy
You nailed it, but it's the other way around in the release notes.
I renamed to filament-error.g and it ran the macro when the sensor tripped.

RepRapFirmware 3.4.0beta7

Upgrade notes:

The handling of filament errors have changed. When a filament error occurs, an event is created. To handle the event, RRF runs macro file filament_error.g without appending the extruder number to the file name and without pausing the print first. The extruder number is passed as param.D along with some other parameters. If filament_error.g is not found then the print is paused (running pause.g) and the error is reported.

gloomyandy

@owend It used "_" in the original beta7 but has changed back to "-" in the most recent builds (and will be this way in RC1)....
https://github.com/Duet3D/RepRapFirmware/commit/3ac3345333659785dcd21088ae0b9b93ec914a4d

RepRapFirmware 3.4.0RC1
This release is still in preparation. Further items may be added before the release.

The macro files run after events are now heater-fault.g, filament-error.g (as in RRF 3.3), driver-error.g, driver-warning.g and driver-stall.g instead of these names with the '-' character replaced by '_'

a little confusing!

0

dc42 committed to Duet3D/RepRapFirmware

Replace '_' by '-' when generating macro name from event type name

OwenD

@gloomyandy
Thanks for that.
I had both files until yesterday.
I couldn't remember which to use, so I looked at the release notes, but in honesty I do now recall reading the snippet you posted, so my fault.

PetrKroupa

@dc42 - UPDATE: in BETA7+7 is called filament-error.g . Not filament_error.g.
(6HC + 1LC + SBC + MFM)