New experimental firmware 1.19beta7
-
Joe, I'll see if I can reproduce that.
Kulitorum, I meant the Z offset.
-
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
-
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/115Setting “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.
closed Fixed setup/config of CoreXYU #115
-
Hmm.. have G92 V0 Z0 will not set axis as homed…?
-
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 offsetnew 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? -
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 appersok 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.
-
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
-
Hade to go back to
Firmware Version: 1.19beta6 (2017-06-10)
WiFi Server Version: 1.19-beta1
Web Interface Version: 1.16
the discconects was to mush even whit low pool settings -
Please explain what you mean by "low pool settings".
-
Sorry for the bad English.
There is some settings for the times to retry,reconnet, pull not poolIt shuld say "slower update intervall"
