Firmware 1.19RC1 released - please help us with testing!


  • administrators

    I am pleased to announce the release of firmware 1.19RC1 on the usual Edge folders. A lot of work has gone into this release - the code size has expanded by about 50Kbytes.

    Because of manufacturing schedules, we have a tight deadline (Monday!) for the full 1.19 release. Therefore, I would really appreciate the help of as many users as possible to test the release over the next 3 days. In particular, I don't have the kit to test the following:

    • IDEX printer support, in particular tool changes
    • Automatic bed levelling using multiple leadscrew. A user (lars) has tested the 3-leadscrew case, but I have no feedback on whether the 2- or 4-leadscrews cases are working.
    • Mixing extruders. Tool mixing no longer needs to be enabled explicitly. Mixing will always be used if a tool is configured for multiple extruders but only one extrusion parameter is present in a G1 command.
    • Some aspects of CoreXY support, in particular homing

    The full change list is at https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md. Very important: read the upgrade notes! - especially if you haven't used a 1.19beta release before.

    Caution: you may wish to reduce your motor currents when you first try this release, to reduce the likelihood of damage if something isn't right.

    Please report your experiences (good as well as bad in this thread)



  • On it! Thank you!



  • Getting this error repeated while printing. Did not have this prior to this version:

    Error: GCodes: Attempt to read a GCode float before a search.

    John



  • I have a delta diamond hot end mixer. Not sure why, but when I go to change tools on the fly while printing, the method of the printer tool change appears completely random. Sometimes it just stops and starts various filaments without retraction. Sometimes it will stop all filaments and retract/extract the activated ones very aggressively. And just now, all it did was retract the activated filament about 10mm and extruded nothing for several seconds. Not sure what's going on, but it'll need to be fixed of course.


  • administrators

    Can you post your config.g file and the Gcode file to a file sharing site, and link to them?

    Apart from the messages, are there any problems with the print?


  • administrators

    Do you have any tools that are configured with just one extruder drive instead of all 3?

    Is your file sliced with absolute or relative extrusion?



  • Okay, here's a link to the g-code generated by Slicer Prusa Edition:
    https://1drv.ms/u/s!Aj8zwnOgeBYCwTKUbHVhAmi2ImEB

    Here's a link to my config.g:
    https://1drv.ms/u/s!Aj8zwnOgeBYCwTPerlixbih-PG8f

    To answer your questions:

    1. No, the print appears to be okay and the messages are generated during but not stopping it.
    2. No, I don't have any tools that are configured with just one extruder drive instead of all 3.
    3. It appears that it is using absolute extrusion distances.

    Thanks,
    John


  • administrators

    Thanks, I'll simulate that print tomorrow. In the meantime you may wish to downgrade to main firmware version 1.19beta11 and keep everything else the same. I don't think it will show either of those issues, but shout if it does.



  • I did have the tool change issues in 1.19beta11 and they are the same as far as I can tell. The g-code message though only appeared in this release.


  • administrators

    I've found and fixed what's causing the error messages. One is generated every time the firmware processes a G92 E0 command. They are harmless provided that the E parameter is zero.


  • administrators

    When you say " when I go to change tools on the fly while printing", do you mean that you are sending T commands from the console while the machine is printing - or perhaps you are editing them into the gcode file? If so, I know exactly what's happening, and here are two different workarounds:

    1. Slice the file using relative extrusion instead of absolute.

    2. Instead of changing tool, just change the mix ratio of the current tool using M567. This has the advantage that the print won't stop and start.

    If on the other hand the T commands are ones inserted into the file by slic3r, then this is a problem that I need to investigate.



  • Im getting random resets of the duet, running 1.19 RC1, wifiserver beta 10, its happening when I home all (to mech endstops, it crashes after it homes z).

    EDIT - it seems to be doing it when I run this macro after homing.

    I tried running the individual commands, it crashes after initiating the first G1 command.

    ; Z Zeroing sequence using piezo probe
    
    ;slow down movement to delineate bed touch from travel moves
    ;M201 X250 Y250 Z250 		; Accelerations (mm/s^2)
    ;M566 X100 Y100 Z100 		; Maximum instant speed changes mm/minute
    
    G1 X130 Y97.5 Z10 F1000		;move to be centre slowly.
    G30				; probe for z=0
    G1 Z10 F1000			; raise nozzle
    G30 S-1				;check z gap
    G1 Z10 F1000 			; raise nozzle
    
    ;restore speed settings to normal printing speeds
    ;M201 X2000 Y2000 Z200 E1000            ; Accelerations (mm/s^2)
    ;M566 X600 Y600 Z30 E20              ; Maximum jerk speeds mm/minute
    

    m122:

    M122
    === Diagnostics ===
    Used output buffers: 3 of 32 (8 max)
    === Platform ===
    RepRapFirmware for Duet WiFi version 1.19RC1 running on Duet WiFi 1.0
    Board ID: 08DDM-9FAM2-LW4SD-6J9FL-3S46P-K0X3W
    Static ram used: 21144
    Dynamic ram used: 96336
    Recycled dynamic ram: 1304
    Stack ram used: 1304 current, 4832 maximum
    Never used ram: 7456
    Last reset 00:00:12 ago, cause: software
    Last software reset reason: User, spinning module Move, available RAM 7456 bytes (slot 0)
    Software reset code 0x5004, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f80f, BFAR 0xe000ed38, SP 0x2001fdac
    Stack: 0043460b 00000003 ffffffe9 200076b8 00000002 200076c0 00000003 000007ff 00407c29 004268ce 81000000 00000000 00000000 0000000c 00000009 41a00000 41400000 00000000
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms
    MCU temperature: min -269.8, current 29.6, max 29.6
    Supply voltage: min 12.2, current 12.3, max 12.4, under voltage events: 0, over voltage events: 0
    Driver 0: stalled standstill
    Driver 1: stalled standstill
    Driver 2: stalled standstill
    Driver 3: standstill
    Driver 4: standstill
    Date/time: 2017-08-04 14:43:15
    Slowest main loop (seconds): 0.004312; fastest: 0.000033
    === Move ===
    MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
    Scheduled moves: 0, completed moves: 0
    Bed compensation in use: mesh
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heater = 0, chamber heater = -1
    Heater 1 is on, I-accum = 0.0
    === GCodes ===
    Segments left: 0
    Stack records: 2 allocated, 0 in use
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle 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
    autopause is idle in state(s) 0
    Code queue is empty.
    Network state is running
    WiFi module is connected to access point 
    WiFi firmware version 1.19beta10
    WiFi MAC address 5c:cf:7f:ee:63:48
    WiFi Vcc 3.10, reset reason Turned on by main processor
    WiFi flash size 4194304, free heap 39664
    WiFi IP address 192.168.0.127
    WiFi signal strength -38dBm
    HTTP sessions: 1 of 8
    Socket states: 2 0 0 0 0 0 0 0
    Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
    

    I reverted back to 1.19beta11 and the error does not occur with the same sequence.


  • administrators

    DJDemonD, thanks for your report. The diagnostic info that indicates that the Move module was trying to print some debug info to USB but you didn't have a USB connection to a PC. The Move module only prints debug into when you send a M111 S1 command to enable debugging. Is it possible that you did that?

    If you don't think you did, please connect a USB cable and attach to the Duet using pronterface or similar, and see what it is trying to print.



  • Looks like CoreXYU is broken in RC1, I installed RC1 and tried to home all. Second carriage started to move jerkely in the wrong direction like steppers were moving the wrong way out of synch. Reinstalled beta 11 and everything worked again.



  • I turned on "Relative E distances" in Slicer Prusa Edition, resliced, and reprinted. Tool (filament) changes appear to work correctly now and without issue. The g-code error messages I was getting before have stopped as well. The Slicer setting was the only thing I changed.

    Thanks for your help!
    John



  • @dc42:

    DJDemonD, thanks for your report. The diagnostic info that indicates that the Move module was trying to print some debug info to USB but you didn't have a USB connection to a PC. The Move module only prints debug into when you send a M111 S1 command to enable debugging. Is it possible that you did that?

    If you don't think you did, please connect a USB cable and attach to the Duet using pronterface or similar, and see what it is trying to print.

    It produced this output just after a homeall

    ERROR] Traceback (most recent call last):
      File "printrun\printcore.pyc", line 241, in _readline
      File "printrun\pronterface.pyc", line 1713, in recvcb
      File "printrun\pronterface.pyc", line 1669, in update_pos
    ValueError: could not convert string to float: 
    

    But didn't crash this time, (i just reflashed rc1 and reset prior to doing this) this is the m122:

    === Diagnostics ===
    Used output buffers: 3 of 32 (12 max)
    === Platform ===
    RepRapFirmware for Duet WiFi version 1.19RC1 running on Duet WiFi 1.0
    Board ID: 08DDM-9FAM2-LW4SD-6J9FL-3S46P-K0X3W
    Static ram used: 21144
    Dynamic ram used: 96336
    Recycled dynamic ram: 1304
    Stack ram used: 1304 current, 5148 maximum
    Never used ram: 7140
    Last reset 00:04:55 ago, cause: software
    Last software reset reason: User, spinning module GCodes, available RAM 7440 bytes (slot 1)
    Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms
    MCU temperature: min -269.8, current 29.9, max 30.3
    Supply voltage: min 11.8, current 12.2, max 12.4, under voltage events: 0, over voltage events: 0
    Driver 0: stalled standstill
    Driver 1: stalled standstill
    Driver 2: stalled standstill
    Driver 3: standstill
    Driver 4: standstill
    Date/time: 2017-08-04 18:54:12
    Slowest main loop (seconds): 0.004898; fastest: 0.000033
    === Move ===
    MaxReps: 3, StepErrors: 0, FreeDm: 240, MinFreeDm 228, MaxWait: 82567ms, Underruns: 0, 0
    Scheduled moves: 56, completed moves: 56
    Bed compensation in use: none
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heater = 0, chamber heater = -1
    Heater 1 is on, I-accum = 0.0
    === GCodes ===
    Segments left: 0
    Stack records: 2 allocated, 0 in use
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle 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
    autopause is idle in state(s) 0
    Code queue is empty.
    Network state is running
    WiFi module is connected to access point 
    WiFi firmware version 1.19beta10
    WiFi MAC address 5c:cf:7f:ee:63:48
    WiFi Vcc 3.10, reset reason Turned on by main processor
    WiFi flash size 4194304, free heap 39760
    WiFi IP address 192.168.0.127
    WiFi signal strength -42dBm
    HTTP sessions: 1 of 8
    Socket states: 2 0 0 0 0 0 0 0
    Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
    


  • Also and it may be entirely unrelated to RC1 my grid compensation setup is:
    M557 X0:260 Y0:190 S50 ;define mesh
    M376 H10 ;taper off after 10mm
    But it only moves 20mm between probing points (same on beta11) are 20x20 the largest grid squares it will probe?


  • administrators

    20mm is the default, but it can use more, and I have just tested it. I suspect that your M557 command isn't working for some reason, e.g. because you have subsequently used G29 S1 to load a previous height map that used 20mm spacing.

    You can run M557 with no parameters to see what the current grid is.



  • Thanks David, I'll try not loading the grid in config.g but load it in start gcode instead.


  • administrators

    I've just released 1.19RC2:

    • Changed the way we handle tool offsets during a tool change to (I hope) better meet the needs of both IDEX and conventional dual-nozzle printers
    • Fixed spurious error message when G92 E0 is processed (this affected users who used absolute extrusion coordinates when slicing)
    • Fixed Duet3D filament sensor data receive code

Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.