New experimental firmware 1.19beta7


  • administrators

    I've just released this in the appropriate Edge subfolders within https://github.com/dc42/RepRapFirmware/tree/dev/Release. For the change list and upgrade notes, see https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md.

    Please note, there have been extensive changes in this release, so only users who need the new features or bug fixes, or who are already running an older 1.19 beta version, should upgrade to this one. Anybody upgrading a Duet WiFi from 1.18.2 or earlier should read https://duet3d.com/wiki/DuetWiFiFirmware_1.19beta first.



  • With Beta7, What would cause my X axis to move in sink with my extruder while purging before starting a print. Beta6 works fine.



  • My start script S3D
    G1 Y268
    G1 X250 F4000 ;Move to purge bin.
    T1
    M109 P1 S[extruder1_temperature] ; Wait for extruder current temp to reach
    G1 E20 F300 ; Purge E(xx) and F(speed)

    Config
    ; General preferences
    M111 S0 ; Debugging off
    G21 ; Work in millimetres
    G90 ; Send absolute coordinates…
    M83 ; ...but relative extruder moves
    M555 P2 ; Set firmware compatibility to look like Marlin
    M208 X0 Y0 Z0 S1 ; Set axis minima
    M208 X270 Y270 Z200 ; Set axis maxima
    M575 P1 B57600 S1

    ; Endstops
    M574 X1 S0 ; Define active low and unused microswitches
    M574 Y2 S0
    ;M574 Z1 S1
    M558 P1 X0 Y0 Z1 H5 F400 T3000 ; Set Z probe type to modulated, the axes for which it is used and the probe + travel speeds
    G31 P500 X0 Y0 Z2.11 ; Set Z probe trigger value, offset and trigger height
    ;M557 X65:270 Y20:240 S50

    ;Drives
    M584 X0 Y2 Z1:6 E3:4:5 ;Axis Remaping
    M569 P0 S0 ; (X axis) Drive 0 goes reverse (change to S1 to reverse it)
    M569 P1 S1 ; (Y axis) Drive 1 goes forwards
    M569 P2 S1 ; (Z axis) Drive 2 goes forwards
    M569 P3 S0 ; (Extruder 1) Drive 3 goes forwards
    M569 P4 S0 ; (Extruder 2) Drive 4 goes forwards
    M569 P5 S0 ; (Extruder 3) Drive 5 goes forwards

    M92 X87.58 Y87.58 Z1066 E77.34:77.34:77.34 ; Set axis steps/mm
    M566 X800 Y800 Z200 E500 ; Minimum speeds mm/minute
    M203 X2500 Y2500 Z800 E600 ; Maximum speeds (mm/min)
    M201 X250 Y250 Z250 E250 ; Accelerations (mm/s^2)
    M906 X1300 Y1600 Z1300 E1600 ; Set motor currents (mA)
    M84 S30 ;Set idle timeout

    ;Heaters
    M302 P1 ;Allow cold extuder
    M143 S275 ; Set maximum heater temperature to 275C
    M307 H1 A340.0 C140.0 D5.5 S1.00 B0
    M307 H2 A371.3 C155.0 D5.0 S1.00 B0
    M307 H3 A344.7 C158.5 D5.2 S1.00 B0

    M305 P0 T100000 B4388 C0 R4700 ; Set thermistor + ADC parameters for heater 0
    M305 P1 T100000 B4388 C0 R4700 ; Set thermistor + ADC parameters for heater 1
    M305 P2 T100000 B4388 C0 R4700 ; Set thermistor + ADC parameters for heater 2
    M305 P3 T100000 B4388 C0 R4700 ; Set thermistor + ADC parameters for heater 3

    ;Tools
    M563 P1 D0 H1 ; Define tool 1
    G10 P1 S0 R0 X-42 Y1.20 ; Set tool 1 operating and standby temperatures
    M563 P2 D1 H2 ; Define tool 2
    G10 P2 S0 R0 X0 Y0 ; Set tool 2 operating and standby temperatures
    M563 P3 D2 H3 ; Define tool 3
    G10 P3 S0 R0 X42 Y0 ; Set tool 3 operating and standby temperatures

    ; Network
    M550 PDuetWiFi Trio TEST ; Set machine name
    M552 P10.71.163.119 S1 ; Enable network and acquire dynamic address via DHCP

    ; Fans
    M106 P1 T45 H1 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
    M106 P2 T45 H2 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on
    M106 P3 T45 H3 ; Set fan 3 value, PWM signal inversion and frequency. Thermostatic control is turned on
    M106 P4 S255



  • When you say "Tool X offsets are now applied on the next move even if it has no Z parameter" does that mean that only the X offset has been fixed? - Or should it have said "Tool Z offset"?

    Kulitorum


  • administrators

    Joe, I'll see if I can reproduce that.

    Kulitorum, I meant the Z offset.


  • administrators

    Joe, the X movement is because the extruder priming move is the first move after the tool change command, so the X offset of the tool is being applied to its endpoint. To avoid this movement I suggest you repeat the G1 X250 F4000 command immediately after the T1 command, or alternatively put G1 R2 immediately after the T1 command which should have the same effect.



  • Thanks David, that worked.



  • When you say "Tool X offsets are now applied on the next move even if it has no Z parameter" does that mean that only the X offset has been fixed? - Or should it have said "Tool Z offset"?

    Kulitorum


  • administrators

    See my earlier reply.



  • It is not possible to activate CoreXYU in beta 7, I have made a pull request adding activation support through “M667 S3” and a fix to set unspecified axisFactors to 1.0.
    https://github.com/dc42/RepRapFirmware/pull/115

    Setting “M584 Y5 X7 U8 V6 E3:4 Z0:1:2 P4” to hide V axis did screw the CoreXYU kinematics up. After homing I tried to G1 Y10 and it started skipping steps and so I did a emergency stop quickly. Have not have time to look into it much more yet.

    Another problem I had since starting using 1.19 betas is that it sometimes does not connect to wifi after restarts or updates to config.g. I get “Wifi module is idle”. I run M552 S1 one or a few times to get reconnected.



  • Hmm.. have G92 V0 Z0 will not set axis as homed…?


  • administrators

    Hi Lars, thanks for your feedback.

    1. We've already communicated via github about issues with enabling CoreXYU kinematics.

    2. Let me know if you make any progress on the issue with hiding the V axis. Does it work if you home the printer with the V axis visible, and then hide the V axis? BTW, DWC 1.16 will disconnect when you reduce the number of visible axes, but you can reconnect it again and it works. I have already made chrishamm aware of this.

    3. Re G92 V0, I'll give this some thought. I can see why it doesn't do anything, however I think homing X, Y and U is sufficient to define the V motor position. So it may be sufficient to require only that the visible axes have been homed.



  • The G10 z offset seam to be working fine
    have done a cuple of prints and it uses the offset

    new for me is some random disconnects and js erros like this
    "
    A JavaScript error has occurred so the web interface has closed the connection to your board. It is recommended to reload the web interface now. If this happens again, please contact the author and share this error message:

    Message: Uncaught SyntaxError: Unexpected token A in JSON at position 113
    URL: http://192.168.1.130/
    Line: 3:1
    Error object: {}"

    any how thanks for the update and keed up the good work !



  • I also have had problems with WiFi not reconnecting after a modification to config.g or even when power cycling the DuetWiFi. Many times the PanelDue will report "Connected" and then a minute or two later, "Wifi module is idle". Additional attempts to get it to connect eventually work.



  • i get this
    http://192.168.1.130/rr_download?name=0:/sys/oem.json 404 (not found)
    can i verify that oem.json exist from the web gui?


  • administrators

    @MrBlom:

    i get this
    http://192.168.1.130/rr_download?name=0:/sys/oem.json 404 (not found)
    can i verify that oem.json exist from the web gui?

    I presume you are using either Wireshark or a debugging console to see that message. That file should not be present on normal installations, it is an optional component used by one of our OEMs to modify the interface presented by DWC.



  • Hello
    i look at the requests sent / resived in google chrome dev tools
    just trying to figur out whats happening when the diconnect appers

    ok then i will not try to finde the oem file 🙂

    a sugestion is to shorten the variabel names in the response coming back to the ui
    it looks like 50% or more is just variable names
    shorten them and it will send less data
    Thanks for a fast reply



  • Just wanted to share a weird thing happened to me.

    I installed this beta, and after not being able to connect it to my wifi network I did downgrade it to the latest 1.18

    Weird thing is that now the network wifi always works, not even one ajax error for a week and a half. I thought was my imagination so I been testing and testing and is rock steady stable now. The only difference between before and now is that I changed thr name of the printer to all caps, so I highly doubt that made the difference.

    So in my experience updating to 1.19 and downgrading made all my ajax connect issues go away. Weird. Could just be the all caps name? Or maybe is there's something on the 1.19 wifi upgrade that doesn't go away by downgrading to 1.18?

    Anyhow I couldn't be happier with how much stable the printer connection is now.


  • administrators

    Did you follow the instructions at https://duet3d.com/wiki/DuetWiFiFirmware_1.19beta to get connected when you installed the beta?

    Were you definitely running DuetWiFiServer 1.03ch before you changed to the beta? If not then you may have ended up with a later version of DuetWiFiServer than you started with.



  • This is what I have now


 

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