Firmware 1.19+3 (1.19.1 release candidate)

Willy510

Uploaded the firmware without any issues and printed 3 separate prints on a Ultibots D300VS delta printer.
I did not run across any issues, Everything turned on and off when it was supposed to.

Mike

M37 P works really well, estimate was correct to within a minute.

However, the firmware stopped automatically selecting Tool 0 if no tool is active. Meaning it just starts moving the head without activating the extruder if I start a print with no tool active.

dc42

What do you have at the start of your gcode file? If there is a M109 command to set the hot end temperature, that should select the tool

DocTrucker

I'll give this a go in the ormerod 2 before I strip it down. The Repeitier Host estimation was out by an hour for a four hour build, hence my interest in Simulation!

Will all the 1.19.x releases work on the Duet 0.6?

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.