New test firmware 1.19+4 and DuetWiFiServer 1.19+1
-
I updated to this version and tried the heightmap I used to make before at M557 R140 S20, But I am getting "Error: bad grid definition: Too many grid points; suggest increase spacing to 28.0mm" as a result. This is within the 121 max probe points for Duet 0.6 isn't it? Because of the "Heightmap to the moon" issue (http://forums.reprap.org/read.php?416,758939) I turned to M557 R120 S20 and that works. So it seems that this error gets thrown at every grid above 9x9 instead of 11x11, am I right?
Despite the above the bed gets probed correctly and shows no sign of improper values like before.
Edit: Added the map. This grid of 11x11 throws the error mentioned above.
[[language]] RepRapFirmware height map file v2 generated at 2017-07-28 23:16, mean error -0.031, deviation 0.063 xmin,xmax,ymin,ymax,radius,xspacing,yspacing,xnum,ynum -100.00,100.10,-100.00,100.10,120.00,20.00,20.00,11,11 0, 0, 0.102, 0.043, -0.026, -0.048, -0.111, -0.114, -0.115, 0, 0 0, 0.066, 0.060, 0.059, 0.039, -0.009, -0.061, -0.115, -0.129, -0.113, 0 -0.060, -0.023, 0.004, 0.029, -0.001, -0.011, -0.034, -0.051, -0.052, -0.060, -0.042 -0.059, 0.001, 0.047, 0.059, 0.020, 0.000, -0.024, -0.064, -0.059, -0.084, -0.037 -0.139, -0.056, 0.011, 0.012, -0.012, -0.023, -0.037, -0.040, -0.049, -0.049, 0.038 -0.117, -0.038, 0.012, 0.030, 0.038, 0.018, -0.051, -0.024, -0.026, -0.023, 0.041 -0.155, -0.065, -0.012, 0.013, 0.001, -0.015, -0.026, -0.036, -0.014, -0.014, 0.037 -0.184, -0.070, -0.013, 0.012, 0.025, 0.015, -0.037, -0.048, -0.076, -0.063, -0.011 -0.174, -0.077, 0.001, 0.045, 0.039, -0.004, -0.049, -0.080, -0.089, -0.127, -0.116 0, -0.046, 0.029, 0.051, 0.049, -0.009, -0.078, -0.110, -0.148, -0.170, 0 0, 0, 0.086, 0.080, 0.050, 0.051, -0.075, -0.145, -0.189, 0, 0 -
I test and need more M400.
On the other hand the progress bar in STATE PRINTING, does not agree with the rest of the layers to be printed. It is already at 100% while there are still more than 20 layers to print -
Loaded the new firmware, and the wifi server.
First print it disconnected 15min and refuses to reconnect so similar to the previous for myself.Update, its reconnected after about 10 tries of pressing connect while still printing and waiting a few mins.
-
DeltaCon, your M557 R140 S20 setting implies a 280x280 grid with 20mm spacing, which is a 15x15 grid so 225 points, too high for the older Duets.
Synergy41, thanks for the feedback.
Jarery, it would be helpful if you can also connect to your printer via USB and Pronterface, then when a WiFi disconnection occurs you can see what reconnection attempts were made and post the trace here.
-
DeltaCon, your M557 R140 S20 setting implies a 280x280 grid with 20mm spacing, which is a 15x15 grid so 225 points, too high for the older Duets.
Hmm, seems I was using a 25mm spacing before, not a 20mm like I thought… thanks for the maths lesson
-
I test and need more M400.
On the other hand the progress bar in STATE PRINTING, does not agree with the rest of the layers to be printed. It is already at 100% while there are still more than 20 layers to printHi,
Do you mean that with version 1.19+4 the heater turns off correctly even without the M400 command; or do you mean that you still need to include the M400 command to make the heater turn off?
-
No more worries with the heater.
This is just the scroll bar of the print that is ahead compared to the actual layers. -
Hello
This update is magical on my scara no more vibrations!
BIG THANK YOU -
No more worries with the heater.
This is just the scroll bar of the print that is ahead compared to the actual layers.I haven't changed the way the progress bar works. The progress bar doesn't use the layer count, it uses the fraction of the gcode file that has been processed.
EDIT: however, I have found an inaccuracy in the way it is calculated, which causes the progress bar to be an over-estimate for small prints. I will fix this.
-
No more worries with the heater.
This is just the scroll bar of the print that is ahead compared to the actual layers.I haven't changed the way the progress bar works. The progress bar doesn't use the layer count, it uses the fraction of the gcode file that has been processed.
EDIT: however, I have found an inaccuracy in the way it is calculated, which causes the progress bar to be an over-estimate for small prints. I will fix this.
Okay,
It does not matter.
Thank you for all the work you do for the community. -
Jarery, it would be helpful if you can also connect to your printer via USB and Pronterface, then when a WiFi disconnection occurs you can see what reconnection attempts were made and post the trace here.
Using newest 1.19.2 , i continue to have a terrible time to connect and stay connected. Typically i need to kill the powerbar power and turn back on to reconnect.
I don't think I've had a print complete and stayed connected since the beta 1.19 upgrade.Im now wishing i purchased the ethernet versions. Or is there a way I can use the web browser interface with a serial port connection from a laptop and I'll forget the wifi part?
Im on a mac using MacPronterface and after it disconnects I run a M122 command and get the following :
SENDING:M122
=== Diagnostics ===
Used output buffers: 1 of 32 (9 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.19.2 running on Duet WiFi 1.0
Board ID: 08DDM-9FAM2-LW4SD-6JTF0-3SJ6J-TLZHY
Static ram used: 21176
Dynamic ram used: 96096
Recycled dynamic ram: 1512
Stack ram used: 4048 current, 5116 maximum
Never used ram: 7172
Last reset 00:05:09 ago, cause: software
Last software reset reason: User, spinning module GCodes, available RAM 2948 bytes (slot 0)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
[ERROR] Error status: 0Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 39.3, current 42.5, max 42.9
Supply voltage: min 12.1, current 12.4, max 12.6, under voltage events: 0, over voltage events: 0
Driver 0: stalled standstill
Driver 1: stalled standstill
Driver 2: stalled standstill
Driver 3: stalled standstill
Driver 4: standstill
Date/time: 2017-09-03 14:59:08
Slowest main loop (seconds): 0.005500; fastest: 0.000034
=== Move ===
MaxReps: 3, StepErrors: 0, FreeDm: 240, MinFreeDm 234, MaxWait: 5394ms, Underruns: 0, 0
Scheduled moves: 5, completed moves: 5
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 ready with "M122" 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.19.2
WiFi MAC address 5c:cf:7f:a4:a1:64
WiFi Vcc 3.13, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 39064
WiFi IP address 192.168.2.54
WiFi signal strength -42dBm
Reconnections 0
HTTP sessions: 1 of 8
Socket states: 0 0 0 0 0 0 0 0
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) -
Im now wishing i purchased the ethernet versions. Or is there a way I can use the web browser interface with a serial port connection from a laptop and I'll forget the wifi part?
I'm also having a hard time with my duet wifi at the moment.
I'm writting a small python caching proxy to replace the wifi/webserver stack from the duet while still using the web ui
At the moment I'm able to correctly proxy everything to the duet through wifi, I'm able to connect, upload and print through it.
I also have a thread polling the duet with M408 every seconds through usb/serial to provide rr_status data instead of getting them through wifi.
I'll probably try to proxy every http rr_* commands as usb/serial gcodes (not sure about the upload/download yet) -
Please can both of you connect via both USB and WiFi, and when the WiFi connection is lost, see what reconnection messages are written to USB and post them here? This is assuming that you are both running firmware 1.19.2.
Some users have found that the WiFi connection is more stable if they set the access point to a fixed channel (usually 6) instead of leaving it on auto select.
If the disconnections occur only during printing or other movements, and you have high microstepping selected, try putting the microstepping back to x16 with interpolation.
A few users have converted a Duet WiFi to a Duet Ethernet. Hot air rework equipment is needed to remove the WiFi module, but after that it's straightforward to install the Ethernet module in its place.
-
Thanks for the reply
Both the suggestions I have been using since the beginning of my issues:
- I've set my modem to a fixed channel from earlier suggestions
- i've always been using 16x with interpolation (0.9 steppers)
I've had macpronterface hooked up while i print and its disconnected. Running M122 on it after i lose web browser connection, the output ri posted above.
Perhaps I don't understand your instructions of " see what reconnection messages are written to USB" as i see no messages mirrored to the usb when it disconnects and as mentioned the M122 output is as i posted above where it states reconnections 0. Is there a different command you want me to run via usb after it disconnects?My Settings:General are as per default, ajax retries 5 (I've boosted to 10 with no effect),
-
Are you definitely running version 1.19.2 of DuetWiFiServer as well as version 1.19.2 of DuetWiFiFirmware? Look in the Settings General tab to check.
-
Firmware Name: RepRapFirmware for Duet WiFi
Firmware Electronics: Duet WiFi 1.0
Firmware Version: 1.19.2 (2017-09-01)
WiFi Server Version: 1.19.2
Web Interface Version: 1.19 -
If the WiFi module has disconnected from your router then it should write a message to USB saying so and giving progress information about the reconnection attempt. This was new in 1.19.2.
-
Is the "File Information" section of the web page getting information from the firmware or purely on the web server side of things? How is it identifying layers if on the firmware? Mine is currently reporting 0.35mm layer thickness, which is only the first layer. I have however stripped a lot of code out of the gcode file to stop it using heat, and might have accidentally stripped what it is using to identify layers!
Edit: Nuts. Just seen the rc5 release… Will upgrade after testing the time estimation.
-
Late report on the build time estimation! This is a test build with no heat. Works fine for me.
Actual build time: 2hr20m36s
Time to run the simulation: 0hr5m30s
Predicted build time: 2hr2125.6 times quicker than build time on a Duet 0.6. I'll run a similar test on the DuetWifi at home soon. Guess I could just run the simulation and use this machine's config file temporarily.
Edit: Running the above again in 1.19+5 (2017-08-30) Will report on that thread.
-
Please use the 1.19.2 release from https://github.com/dc42/RepRapFirmware/releases, not the older +5 release.
The file information is provided by the firmware.
The Duet WiFi has a faster processor than the 0.6 so it should run the simulation faster.
