RepRapFirmware 3.01-RC1 released

MattOBAMF

Good Afternoon,
I have recently updated to this firmware from the 3.01 Beta3 release and have been experiencing crashing during prints.
These were the following errors that were displayed on the console:
13/02/2020, 14:49:06: : Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin)
13/02/2020, 14:49:06: : Connection to Duet established
13/02/2020, 14:49:06: : Discarded msg src=2 typ=4510 RID=30 exp 31
13/02/2020, 14:49:06: : Error: M308: Response timeout: CAN addr 2, req type 6011, RID=30

I was not experiencing these errors when on the release 3.01 Beta3 firmware.

I also ran a diagnostic on the error, and this was the output:

=== Diagnostics === RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 version 3.01-RC1 running on Duet 3 MB6HC Board ID: 08DGM-9T66A-G63SJ-6JTDL-3S86Q-T80MA Used output buffers: 1 of 40 (8 max) === RTOS === Static ram: 153800 Dynamic ram: 163008 of which 0 recycled Exception stack ram used: 504 Never used ram: 75904 Tasks: NETWORK(ready,1980) HEAT(blocked,1228) CanReceiv(suspended,3380) CanSender(suspended,1460) CanClock(blocked,1436) TMC(blocked,76) MAIN(running,4944) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:01:02 ago, cause: software Last software reset at 2020-02-13 15:08, reason: Assertion failed, spinning module GCodes, available RAM 75564 bytes (slot 1) Software reset code 0x4123 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a80f BFAR 0x00000000 SP 0x2045feac Task 0x4e49414d Stack: 00000194 0047d2d4 0045de99 00000026 2044c610 2042e088 2043ca40 00000001 2043c8b8 2043cadc 2043cad8 Error status: 0 Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest block write time: 0.0ms, max retries 0 MCU temperature: min 38.7, current 39.5, max 39.6 Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0 Driver 0: standstill, reads 43343, writes 17 timeouts 0, SG min/max 0/545 Driver 1: standstill, reads 43343, writes 17 timeouts 0, SG min/max 0/564 Driver 2: standstill, reads 43344, writes 17 timeouts 0, SG min/max 0/545 Driver 3: standstill, reads 43344, writes 17 timeouts 0, SG min/max 0/558 Driver 4: standstill, reads 43344, writes 17 timeouts 0, SG min/max 0/559 Driver 5: standstill, reads 43345, writes 17 timeouts 0, SG min/max 0/582 Date/time: 2020-02-13 15:09:39 Slowest loop: 8.52ms; fastest: 0.07ms === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 367, MaxWait: 24625ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 10, completed moves: 10, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === Heat === Bed heaters = 6 7 8 9 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null http* is idle in state(s) 0 telnet* is ready with "M122" in state(s) 0 file is idle in state(s) 0 serial is idle in state(s) 0 aux is idle in state(s) 0 daemon* is idle in state(s) 0 queue is idle in state(s) 0 lcd is idle in state(s) 0 spi is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 0.41ms; fastest: 0.01ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 0 of 8 - Ethernet - State: 0 Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 314, longest wait 8ms for type 6027 === Linux interface === State: 0, failed transfers: 0 Last transfer: 12ms ago RX/TX seq numbers: 6358/1943 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v1.2.4.0 Code buffer space: 4076 Configured SPI speed: 2000000 Hz Full transfers per second: 30.71 ok

I hope this helps,
Thank you in advance!
Matt O

dc42

Thanks for your report. From the stack trace I can see where the code is failing, but not why. Please tell me a little about your machine configuration. In particular, are you using any CAN-connected expansion boards, and if so, what devices have you configured on them?

PS - also, what type of Z probe are you using?

[Note to self: assertion failed at line 404 of port.c. It appears to be trying to enter an interrupt critical section while executing the SysTick ISR.]

spllg

@dc42 sorry for my late reply

these are the results of my measurements

1000 ohm -> 160c
33o ohm -> 215c
220 ohm -> 237c

which are roughly consistent with https://e3d-online.dozuki.com/Wiki/Thermistor_table. . so i feel, it's the thermistor which provides too low resistances. consequently there is no reason to blame duet.

thanks for your assistance.

zerspaner_gerd

Wouldn't it be time for RF3 to open a new Gcode site?
That would be much clearer.
I was just looking at the upcoming change of M581, and it's getting a bit confusing for me.

zerspaner_gerd

A question of understanding
What is the expected behavior if this macro is called by trigger when printing / filament change

; trigger6.g
; M400 

abort "TEST abort"
; M400

I just get a message otherwise no reaction
With this macro:

; trigger6.g
; M400 

abort "TEST abort"

The print head stops and when pressed again (trigger) the printer status changes to idel.
Restarting the printout has no reaction, first requires an emergency stop to start a new print job

Has anyone already successfully used the abort function?
For me, this doesn't work as expected at all.

Board: Duet WiFi 1.02 or later
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-RC1+1 (2020-02-09b1)

dc42

@zerspaner_gerd said in RepRapFirmware 3.01-RC1 released:

The print head stops and when pressed again (trigger) the printer status changes to idel.
Restarting the printout has no reaction, first requires an emergency stop to start a new print job
Has anyone already successfully used the abort function?
For me, this doesn't work as expected at all.

It's a bug in RC1, fixed in the forthcoming RC2.

bondus

@kir09Bes said in RepRapFirmware 3.01-RC1 released:

We've used the RepRapFirmware 3.01-RC1 on Duet 2 for Five Bar Parallel SCARA configuration. It produces some sort of jerking when passes through 0 of thetaR (see the picture in https://duet3d.dozuki.com/Guide/Five+Bar+Parallel+SCARA/24?lang=en). Could you suggest how to eliminate the jerking?

Nice to see more fellow 5bar'ers.

I did much of the later coding of the five bar scara and just now got to testing the RRF3 firmware. It was ported by the Duet guys from RRF2 to RRF3.

And as you say it has problems with thetaR < 0. In my testing it goes catastrophically wrong and sends the right arm way off.

I have to update my dev environment to RRF 3 and debug it...

bondus

@kir09Bes
... and after some building woes I got a firmware compiled. That made the board go black on the network. I have to remember how to hook up the serial port and dig deeper...

kir09Bes

@bondus
Nice to see that you have advanced in it. I hope you'll have fast results.

bondus

@kir09Bes I found the problem after staring at the code for a few minutes. The firmware didn't treat the X and Y motor axises as rotating. When it tried to move from 1° to -1° (or 359°, same place) it tried to take the long unreachable way to get there.

I made a tiny pull request for the firmware to fix it. If you want a fixed binary firmware please contact me.

bondus

@kir09Bes, I also noticed the jerking issue you mention. It only occurs at certain places when doing fast moves. The stepper motors are stuttering.

https://youtu.be/PS9_fSJLDxM

It turns I was hitting the limit for step-rate. By changing microstepping from 256 to 128 it moves smooth again.

The 5-bar has to spin the arms pretty quickly at some positions to move the head at a decent speed. There probably is a way to limit the motor speed with a configuration.

JoergS5

@bondus looking the video, I think at this position the actuators need a lot of force *)because the angle at the hotend is very big, near the singularity. Precision in left-right-direction will be low also. High microstepping means low torque which may explain the 256-128 difference. If you move the hotend further away, it will be more precise imho.

I mean the forces need to be high for a movement from right to left.