New experimental firmware 1.19beta8
-
Good work will try it when im back from the vacation
-
Installed no issues, installation guide (going from 1.18) was very good and everything worked as expected. No wifi connectivity problems.
Just to mention that duet web control version number only updates if you reload it in your browser.
Just one question why were previous DWC updates 4Mb and this one only 400Kb?
-
The DWC bin file for the 1,18 and earlier releases is a binary file ready for flashing directly into the wifi module. The 1.19 release stores the DWC files on the SD card, so they are all compressed into a single zip file, which is unpacked by DWC when you do the upgrade. It's the same zip that is used for the Duet 085 and Duet Ethernet.
-
Ahh I see so a 4mb file with only 400kb of data in it. Gotcha.
-
Did some testing with beta 8.
When the wifi fail to connect, I get the following message:Wifi reported error: Unexpected WiFi state ‘idle’ whilte trying to connect to Wifi module is idleI get some weird behaviour when using the web interface Machine Control with second tool.
Test Setup:
Disable all tool change scripts.
Run home all (Script will inactivate both tools with T-1)
Switch to T0 and move it to -33 as I don’t want T1 to crash into itSwitch to T1
X -1T1 moves to min position (-5) and stops to respond to X interface commands.
I can however move T1 using the g-code console: G1 X10 will move t1 to X10 absolute.
Once I have issued G1 X10 in the g-code console I can use the interface Machine Control again to move X.
If I switch T0 and back to T1 the first x command in the Machine Control will move T1 to min position (-5) and stops to respond to X interface commands.The following on the g-code console works. It should be about the same as what is not working in the Machine Control.
G28 T0 G1 X-33 T1 G1 X500 G1 X490I looked at the code but was unable to locate the problem. Don’t know where to look for this issue to be honest and a lot have changed since beta 6.
Firmware Name: RepRapFirmware for Duet WiFi
Firmware Electronics: Duet WiFi 1.0 + DueX5
Firmware Version: 1.19beta8 (2017-06-30)
WiFi Server Version: 1.19beta8
Web Interface Version: 1.16 -
Wanting to test the "fixed" pressure advance feature, I upgraded my Duet Wifi from 1.18.1 to 1.19beta8.
Now if I want to run mesh grid compensation, I get this error (this worked in 1.18):
"Error: No valid grid defined for G29 bed probing"
I have an i3 clone with NPN inductive probe, here are the relevant parts from my config.g :
; Movement section
M208 X200 Y298 Z200 ; set axis maxima (adjust to suit your machine)
M208 X-3 Y-20 Z0 S1 ; set axis minimum (adjust to make X=0 and Y=0 the edge of the bed)
; Z probe section
M558 P4 X0 Y0 Z1 H3 I1 F300 T6000 ; NPN invert used for homing Z axis, dive height 3mm, probe speed 300mm/min, travel speed 6000mm/min
G31 X4.25 Y0 Z0.87 P500 ; Set the probe height and threshold (put your own values here)
M557 X1:180 Y1:290 S30 : Set probe gridI also had initial problems getting the duet connecting to my AP. After I initiated a new SSID and simple password (original pwd had a @ character in it) it began to work.
-
That looks like it should work. I wonder if the issue is the X probe start area is outside of where the probe can reach (+4.25 offset on X vs -3 axis minimum).
Maybe try 5:185 for the X probe range in M557.
-
You can run M557 with no parameters to check whether the grid was accepted. Or send that same M557 command manually from the GCode Console, and see if there is an error message.
-
Manually sending M557 works but now I have to set X5:185 or else I get warnings during probing:
[[language]] 4:24:08 PMWarning: skipping grid point (1.0, 271.0) because Z probe cannot reach it 50 points probed, mean error 0.099, deviation 0.110 Height map saved to file heightmap.csv 4:23:56 PMWarning: skipping grid point (1.0, 211.0) because Z probe cannot reach it Warning: skipping grid point (1.0, 241.0) because Z probe cannot reach it 4:23:42 PMWarning: skipping grid point (1.0, 151.0) because Z probe cannot reach it Warning: skipping grid point (1.0, 181.0) because Z probe cannot reach it 4:23:28 PMWarning: skipping grid point (1.0, 91.0) because Z probe cannot reach it Warning: skipping grid point (1.0, 121.0) because Z probe cannot reach it 4:23:15 PMWarning: skipping grid point (1.0, 31.0) because Z probe cannot reach it Warning: skipping grid point (1.0, 61.0) because Z probe cannot reach it 4:23:01 PMG29 Warning: skipping grid point (1.0, 1.0) because Z probe cannot reach itThis makes no sense to me, are the M557 coordinates extruder coordinates or probe coordinates?
If I reset the duet and send M557 to the console I get message "Grid is not defined".
I tried moving the M557 line as the last line in my config.g but it does not work.
Mind you that this worked flawlessly in 1.18.1 -
actually I have a typo in my config.g, my probe sits 4.25 cm to the right of my nozzle.
So the correct G31 command is G31 X42.5 Y0 Z0.87 P500so taking this into account, I should be able to probe absolute coordinates X0:137.5 and Y0:290, so this means the probe will be at positions X42.5:X200 Y0:290, right?
-
It works the other way round. The grid specifies where you want to probe. The lowest X value that the probe can reach will be the minimim X set in your M208 S1 command plus 42.5mm.
I added the warning messages in the most recent beta, because too many users have been asking why it doesn't probe all the points they asked for.
-
Thanks that makes sense.
It would be nice to mention this in the GCode M557 wiki/Mesh bed compensation wiki as this leads to confusion
-
I updated from 1.18.1 to 1.19beta8 last night…. running mesh bed compensation completes correctly but does not load the visual after just gives and error about not being able to find the heightmap file.... but I can click view on the file just fine and it opens after.
Also I have to jump on the bandwagon of people who are constantly disconnected from the DWC. It happens randomly when I click things and if I am away for a few minutes.
Everything is also very slow and laggy now.... clicking anything there is a lag a pretty large one.... I can probably count 10 to 15 seconds before a jog button click or config file open responds. My printer is currently 5 feet from a high end Asus wireless router
-
Testing IDEX on beta8 and when I change tool, the "new" tool moves to the position of the old tool after running my post.g code.
This means that the heads collide and the new tool looses position.
I could post all my config, but I don't want to clutter the post. Let me know what parts you are interested in.
//M122 while printing single head:
=== Diagnostics ===
Used output buffers: 3 of 32 (15 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.19beta8 running on Duet WiFi 1.0 + DueX5
Board ID: 08DAM-999TL-MQ4S8-6JKF0-3SN6N-1NBHW
Static ram used: 20900
Dynamic ram used: 96620
Recycled dynamic ram: 1264
Stack ram used: 1304 current, 9016 maximum
Never used ram: 3272
Last reset 00:22:04 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 3196 bytes (slot 2)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 36.9, current 37.2, max 37.5
Supply voltage: min 19.4, current 20.0, max 20.3, under voltage events: 0, over voltage events: 0
Expansion motor(s) stall indication: no
Driver 0: stalled
Driver 1: ok
Driver 2: stalled open-load-B
Driver 3: stalled standstill
Driver 4: standstill
Driver 5: ok
Driver 6: standstill
Driver 7: standstill
Driver 8: standstill
Driver 9: standstill
Date/time: 2017-07-03 21:40:47
Slowest main loop (seconds): 0.005737; fastest: 0.000000
=== Move ===
MaxReps: 4, StepErrors: 0, MaxWait: 1ms, Underruns: 0, 0
Scheduled moves: 18501, completed moves: 18472
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
Probe change coordinates:
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.2
=== GCodes ===
Segments left: 1
Stack records: 3 allocated, 0 in use
Movement lock held by file
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "G1 X127.370 Y125.110 E3.3039" 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
Code queue is empty.
Network state is running
WiFi module is connected to access point
WiFi firmware version 1.19beta8
WiFi MAC address a0:20:a6:16:e7:72
WiFi Vcc 3.08, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 40024
WiFi IP address 192.168.1.180
WiFi signal strength -63db
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) -
@Kulitorum, don't you have your tfree#.g files set up to park the old tool?
-
; Put G/M Codes in here to run when Tool 0 is freed
M83 ; relative extruder movement
G91 ; relative axis movement
G1 E-3 Z3 F3600 ; retract 2mm and lift head
G90 ; absolute axis movement
G1 S2 X-27 F42000 ; park the X carriage at -27mm
G1 E3 F3600 ; unretract 3mm
M82 ; absolute extruder movement -
Post#.g:
M116 P0 ; wait for tool 0 heaters to reach operating temperature
M83 ; relative extruder movement
G1 E2 F3600 ; extrude 2mm
M82 ; absolute extruder movement
G91 ; relative axis movement
G1 Z-3 F500 ; up 3mm
G90 ; absolute axis movement
;G1 R1 F42000 ; Goto where we left off -
Ok, so if the head is moving to the position of the old tool, which position is that? The position before it ran tfree0.g, or something else?
-
It moves to the park position of the old head.
PS: Can you change the 60 sec between posts? - Seeing this for the third time today….. Also the 30 sec between searches is annoying - if you did not find what you were looking for, you can't re-search for 30 secs.
-
I can guess what might be happening. For now I suggest you try starting the tpost file with a G1 S2 command to move the new year to its park position. There should be no actual movement because it should already be parked, but that command should update the desired X coordinate.
In the latest beta you should be able to use G1 R2 at the end of tpost to move the head to the position of the old tool before the tool change.
