New experimental firmware 1.19beta7

dc42

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.

joestefano

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

joestefano

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

Kulitorum

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

dc42

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

Kulitorum, I meant the Z offset.

dc42

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.

joestefano

Thanks David, that worked.

Kulitorum

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

dc42

See my earlier reply.

lars

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.

larsarv opened this pull request in dc42/RepRapFirmware

closed Fixed setup/config of CoreXYU #115

lars

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

dc42

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.

MrBlom

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 !

Forgvn77

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.

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?

dc42

@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.

MrBlom

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

Neotko

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.

dc42

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.

Neotko

This is what I have now