Unofficial RRF 3.4.0beta7+4 files

[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 21 Dec 2021, 16:08 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)