Firmware 1.19+3 (1.19.1 release candidate)

lolorc

still having major issues with file uploads, they never complete have to M999 to duet (WiFi signal strength -59dBm)
also having the gcode issues I reported earlier
edit: after ~10 tries, I managed to upload a 4MB gcode file… during the first tries a rpi was connected to the usb port of the duet (no software connection tho), for the successful try I disconnected it. Time will tell if there's a relation. If it happens again I'll either downgrade to 1.18 or replace the web ui by octoprint.

MoS-tekknix

@dc42:

@dc42:

@MoS-tekknix:

Also currently printing on my Machine with 1.19+3 without any kind of problems. Indeed it seems to fix the BedSurface-Problems cause i use over 200 Measure-Points. Now it looks much more real

Also before with 1.19+1 i've noticed that Filament-Measurement isn't working well (800mm printed of 1700mm but finished) which seems to show now the real values.

Cheers
MoS-tekknix

Thanks for the feedback. Which figure do you think is correct, the 800mm or the 1700mm? Does that print use just one filament, or more than one? Are you using relative or absolute extruder coordinates in your slicer?

I've just done a print and it finished with 1274.7mm of 1280.7mm, so it's working for me.

One more question: are you using volumetric extrusion?

Yes, indeed.

MoS-tekknix

@dc42:

@MoS-tekknix:

Also currently printing on my Machine with 1.19+3 without any kind of problems. Indeed it seems to fix the BedSurface-Problems cause i use over 200 Measure-Points. Now it looks much more real

Also before with 1.19+1 i've noticed that Filament-Measurement isn't working well (800mm printed of 1700mm but finished) which seems to show now the real values.

Cheers
MoS-tekknix

Thanks for the feedback. Which figure do you think is correct, the 800mm or the 1700mm? Does that print use just one filament, or more than one? Are you using relative or absolute extruder coordinates in your slicer?

I've just done a print and it finished with 1274.7mm of 1280.7mm, so it's working for me.

800mm was the correct one. It seems to wokr now all the time +- a few mm.

DeltaCon

Has been a few days since I checked this I will try this evening concerning the heightmap correction.

synergy41

Hello everyone,
I noticed that the bar in the print status tab is not fair, I want to tell by that on my copy of screens you can see which indicates 100% while I am in the 28th Layers on 48.
This is normal or not.
Thank you for your answers.

MoS-tekknix

Observed the same but was my fault. What your END-GCode looks like?

I've set relative Modes before and raise Z to my maximum (200mm) and it always shows up 1000 Layers to print.

Now i've set it to G91 (Relative Positioning) lift Z 5mm and set it back to G90 (Absolute Positioning)

That solves the problem. I assume that Reprap seems to analyze also the END-Script too and calculates the maximum heigh of all Moves. And that was my maximum Z-Heigh.

Cheers
MoS-tekknix

synergy41

My g end code is like this

"G28 ; Home all axes
M140 S0 ; Set Bed Temperature
M84 ; Stop idle hold
G1 E-3 ; Remove 3.00mm of material
M400 ; Wait for current moves to finish
M104 S0 ; Set Extruder Temperature
M106 S0 P0 ; Stop Fans Print"

sigxcpu

+1 was fine, +3 repeats the same response since last console command as a UI notification. Is there an update to the web interface, too?

dc42

@sigxcpu:

+1 was fine, +3 repeats the same response since last console command as a UI notification. Is there an update to the web interface, too?

There is no update to the web interface. Please can you explain more clearly what you think has changed.

sigxcpu

During printing the last console message is repeated. In this case I was checking the motors currents (I've typed M906 once).

dc42

Is that a behaviour that you can reproduce? Does it also happen if you install the 1.19+4 firmware?

sigxcpu

I have installed +4, but didn't have the chance to test it, as I have nothing to print yet

tomasf

I experienced something similar to that, where every command in the console showed the output of an older M122 command, but I haven't seen it happen yet in +4.

sigxcpu

Yeap, can confirm that. It seems +4 is not repeating.

sigxcpu

Actually it is repeating again.

[[language]]
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.3

It looks like the issue is with the client side, because server doesn't repeat.

T 2017/10/13 16:05:33.938039 192.168.27.116:34083 -> 192.168.27.7:80 [AP]
GET /rr_gcode?gcode=M221%20D0%20S95 HTTP/1.1.
Host: 192.168.27.7.
Connection: keep-alive.
Accept: application/json, text/javascript, */*; q=0.01.
X-Requested-With: XMLHttpRequest.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36.
Referer: http://192.168.27.7/.
Accept-Encoding: gzip, deflate.
Accept-Language: en-GB.
.

T 2017/10/13 16:05:33.941879 192.168.27.7:80 -> 192.168.27.116:34083 [AP]
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Access-Control-Allow-Origin: *
Content-Type: application/json
Content-Length: 12
Connection: close

{"buff":243}

Or server is repeating in "rr_reply"?

T 2017/10/13 16:05:34.403518 192.168.27.116:34085 -> 192.168.27.7:80 [AP]
GET /rr_reply HTTP/1.1.
Host: 192.168.27.7.
Connection: keep-alive.
Accept: text/html, */*; q=0.01.
X-Requested-With: XMLHttpRequest.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36.
Referer: http://192.168.27.7/.
Accept-Encoding: gzip, deflate.
Accept-Language: en-GB.
.

T 2017/10/13 16:05:34.407117 192.168.27.7:80 -> 192.168.27.116:34085 [AP]
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Access-Control-Allow-Origin: *
Content-Type: text/plain
Content-Length: 62
Connection: close

File Elevator/pulley.FCStd_PLA.gcode selected for printing

dc42

I believe this is an issue with the interaction between DWC and the firmware. It's more chrishamm's area than mine. It's probably triggered by connecting two network clients and stopping one of them without pressing Disconnect first.

whosrdaddy

@dc42:

I believe this is an issue with the interaction between DWC and the firmware. It's more chrishamm's area than mine. It's probably triggered by connecting two network clients and stopping one of them without pressing Disconnect first.

I can confirm this behavior, as I often upload a print from my computer and then control the printer via my phone (they are not in the same room).
When I connect with my phone and control the printer, and I go back to my PC , sometimes the session is disconnected (AJAX error) and if I reconnect, I get echo on each command.

jlegere

@dc42:

I've just released an update to firmware 1.19. the binaries an be found at https://www.dropbox.com/sh/wq0u70kpapqc3is/AAC6I8TS5Lbwuziq_r3M15Qea?dl=0. The changes since the 1.19+1 test version are:

Thank you for this link, the one on github says it would not work with my electronics ( a duet ethernet, I did not grab the wifi firmware on accident)

dc42

Version 1.19+1 has been superseded by 1.19.2 which is an official release on github.