New firmware release 1.17a

lolorc

Thanks,

Do you have any idea what the changes in DWC are ?
Also, can you provide the sources of the DWC binaries you distribute please ? (DuetWebControl-1.14-b4.bin and DuetWebControl-1.14-RC1.bin)

edit: macro names (ex: Z-0.01) are fixed.

dc42

For DWC sources and change lists, you should look in chrishamm's github repository. I provide copies of the binaries in my repostory as a convenience to users who are downloading the firmware.

lolorc

2 prints in the raw where RRP did not drive heater 1. (it then complained with Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault)
(happened after RRP/DWC updates)

did an emergency stop, re-used the same gcode and it worked as expected

gcode file starts with

[[language]]
M190 S80
M104 S205
M109 S205
G28 ; home all axes
M82
G1 X0 Y0 Z5 F8000
G29 S1
;LAYER_COUNT:50
;LAYER:0
M107
G1 Z23
G0 F4500 X13.565 Y4.757 Z3.3

not the first time I encounter this issue, can't tell if it always happened after a software upgrade.

lolorc

@dc42:

For DWC sources and change lists, you should look in chrishamm's github repository.

I did before writing my message.

https://github.com/chrishamm/DuetWebControl
only one branch, master which is 2 month old.

edit, see:

lolorc

an issue with a gcode file generated by slic3r in vase mode: DWC is displaying "Layer: 3736 of 505, Filament Usage: 3644.0mm of 3879.5mm (235.5mm remaining)" with "current layer time = 0s" which is not true.

gcode is here : https://cloud.githubusercontent.com/assets/10393822/21608175/3f054c7c-d1bb-11e6-9a93-dd060e76dfeb.png this is not a png but an uncompressed gcode file you can wget. (3.8MB)

(apart from the visible Z seam, the vase was printed perfectly)

deckingman

I get the same thing with slic3r in spiral vase mode but it's hardly surprising given that the layer change is continuous. So there are an infinite number of layers or only one layer depending on how you look at it. Under those circumstances, I can't see DWC could display anything useful so I ignore it.

lolorc

makes sense. I guess RRP/DWC could probably try to be clever about what it displays. but considering your explanation that's minor enough to ignore I agree

CRPerryJr

Thanks For the update! I updated to 1.17a and DWC 1.14-RC1. Everything tests ok regarding my printer, but the Webcam issue related to appending the "&" parameter to update the cached image is still causing no image to be displayed in DWC\Print Status. "ERR_EMPTY_RESPONSE".

http://localip/webcapture.jpg?command=snap&channel=0 Works in any browser and displays a static image.

http://localip/webcapture.jpg?command=snap&channel=0& Fails in any browser with "Failed to load resource: net::ERR_EMPTY_RESPONSE"

http://localip/webcapture.jpg?command=snap&channel=0&dummy=VARIOUS NUMBERS causes "Failed to load resource: net::ERR_EMPTY_RESPONSE" in DWC. Everything after "=0" is what DWC adds to the URL provided above to create a new URL and refresh the image.

If we could change the "&" parameter to just about anything else, it seems to work. But my webcam doesn't like the additional "&".
I have an ELP IP 1881 IP Camera if that helps at all. (I think it also goes by TOP201)

Russ Gries

@dc42:

Homing speeds:

The speed factor (M220 command, or speed control in DWC and PanelDue) no longer affects the speed of homing moves or other special moves (i.e. G1 commands with S1 or S2 parameter)

Yeah! Thanks David!!!!

will need to install this one

~Russ

LeonMF

@lolorc:

2 prints in the raw where RRP did not drive heater 1. (it then complained with Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault)
(happened after RRP/DWC updates)

did an emergency stop, re-used the same gcode and it worked as expected

not the first time I encounter this issue, can't tell if it always happened after a software upgrade.

I saw something similar. I did an upgrade from 1.17 to 1.17a without doing a power cycle. I had the system pre-heated and it looks like the heater shut off when I started my print!

All subsequent prints after that first one have been fine. Maybe there's some initial condition thing? It's not a huge deal but if I hadn't seen this comment I probably would have freaked out a bit!

Sniffle

Have you thought about a Z-probe repeatability test that can be ran as a probe verification tool? say G29 S3 D10(requires being homed) S3 because it's the next function in line after G29 S2, and D10 for the number of times to probe said point.

Moves halfway to the max position defined in the config, probes D times, records the trigger heights and returns the mean and std deviation after completing the action

chrishamm

@CRPerryJr:

Thanks For the update! I updated to 1.17a and DWC 1.14-RC1. Everything tests ok regarding my printer, but the Webcam issue related to appending the "&" parameter to update the cached image is still causing no image to be displayed in DWC\Print Status. "ERR_EMPTY_RESPONSE".

http://localip/webcapture.jpg?command=snap&channel=0 Works in any browser and displays a static image.

http://localip/webcapture.jpg?command=snap&channel=0& Fails in any browser with "Failed to load resource: net::ERR_EMPTY_RESPONSE"

http://localip/webcapture.jpg?command=snap&channel=0&dummy=VARIOUS NUMBERS causes "Failed to load resource: net::ERR_EMPTY_RESPONSE" in DWC. Everything after "=0" is what DWC adds to the URL provided above to create a new URL and refresh the image.

If we could change the "&" parameter to just about anything else, it seems to work. But my webcam doesn't like the additional "&".
I have an ELP IP 1881 IP Camera if that helps at all. (I think it also goes by TOP201)

The problem with webcam images is that the target URI has to be different every time a new photo is requested. I saw the other day that JQuery does it a bit different and that they use &= <random>instead of &dummy=<random>. Are you able to open http://localip/webcapture.jpg?command=snap&channel=0&=346345234 or does it give you an empty image as well?

For MJPEG sources I'm planning to allowing a static image URL by setting the update interval to 0. This will be implemented in DWC 1.14a.</random></random>

InSanity

I notice some talk about heaters not being turned on sometimes. I had this happen yesterday, started a print and when the machine went to lay it's cleaning swipe on the bed it had the nice grinding noise of the extruder trying to push cold PLA. I did an emergency reset followed by a power cycle printed the same file and everything worked perfectly. This is with version 1.17a, no recent firmware updates were involved. I thought it was worth a mention, I'll keep track of this happening again.

Ohhh and the heater was set to 210 on the web console, so I know it should have been heating up, no faults indicated. I didn't notice if the tool was active or not before hitting the power switch. The fact that the same exact file worked the next time makes me wonder. I also don't get why the extruder was trying on cold filament, normally it would just toss up errors, the PT100 was showing 26.7C ish.

Thanks,

Jeff

demonio669

David, I Installed FW 1.17a and I think I found a bug.

I modified a gcode file to add a M226 to it to pause the printer to allow me to change the filament color. but the printer stays in "pausing" state

I also try to add M25 instead of M226 but with the same results.

I add a sleep.g macro containing M98 P/sys/pause.g to call pause code but also it dont work

I'm doing something wrong or it is a bug ?

I have a duet wifi

StephenRC

Duet 085, firmware 1.17a , web 1.14-rc1, 24vdc power, bed is on AC via ssr. A 24vdc fan @ 12vdc is cooling the driver section of the board. Today I downloaded and uploaded the firmware again, just in case there was a problem with the initial upgrade.

A print is running, hit pause, that works fine. Then I hit cancel, after cancel.g has run, the 'outside all triangles' error storm starts filling the screen. Yesterday, found that after using the web page's emergency stop, it never reconnects afterwards. Today, I found that a home all does stop the error once the z axis home has started. My DuetWifi hasn't done this. The file being printed has no affect. The Duet085 didn't do this on earlier firmware. At one time yesterday the web stopped responding and the paneldue stopped talking with the printer, I haven't been able to reproduce that.

First error in the log:
12:40:27 PM M0 H1
Print cancelled
Triangle interpolation: point outside all triangles!
Triangle interpolation: point outside all triangles!
Triangle interpolation: point outside all triangles!

Then for every second after that, one or more:
Triangle interpolation: point outside all triangles!
–---------------------
The errors continue until a home all has started the z home part or a power cycle.

-- This is right after a home all:
12:43:29 PMM122
=== Diagnostics ===
Used output buffers: 1 of 32 (12 max)
=== Platform ===
Memory usage:
Program static ram used: 45804
Dynamic ram used: 41412
Recycled dynamic ram: 2896
Current stack ram used: 2840
Maximum stack ram used: 6788
Never used ram: 1404
Last reset 00:06:08 ago, cause: software
Last software reset code: 0x0003, available RAM 1736 bytes (slot 4)
Spinning module during software reset: GCodes
Error status: 0
Max PWM loop count 0
Free file entries: 10
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 33.6, current 41.2, max 47.8
Current date and time: 2017-01-07 12:43:28
Slowest main loop (seconds): 0.061630; fastest: 0.000108
=== Move ===
MaxReps: 4, StepErrors: 0, MaxWait: 4ms, Underruns: 0, 0
Bed probe heights: -0.173 0.031 -0.215 -0.006 -0.086 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.4
Heater 1 is on, I-accum = 0.5
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is ready with "M122"
telnet is idle
file is idle
serial is idle
aux is idle
daemon is idle
=== Network ===
Free connections: 15 of 16
Free transactions: 23 of 24
=== Webserver ===
HTTP sessions: 1 of 8
FTP connections: 0, state 0
Telnet connections: 0, state 0

cancel.g:
M104 S0 ; turn off extruder
M140 S0 ; turn off bed
M106 S0 ; turn off part fan
G1 X10 F3000 ; move x to left
G1 Y260 F3000 ; move y to front
G91 ; relative moves
G1 Z10 ; raise z by 10
G90 ; absolute moves
M84 ; disable motors

Originally had a G28 X instead of the G1 X10 F3000 line. The change had no affect.

Also ran a M122 during the error storm:

12:52:54 PM Triangle interpolation: point outside all triangles!
Triangle interpolation: point outside all triangles!
Triangle interpolation: point outside all triangles!

=== Diagnostics ===
Used output buffers: 3 of 32 (18 max)
=== Platform ===
Memory usage:
Program static ram used: 45804
Dynamic ram used: 41412
Recycled dynamic ram: 2896
Current stack ram used: 2840
Maximum stack ram used: 6788
Never used ram: 1404
Last reset 00:15:34 ago, cause: software
Last software reset code: 0x0003, available RAM 1736 bytes (slot 4)
Spinning module during software reset: GCodes
Error status: 0
Max PWM loop count 0
Free file entries: 10
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 32.3, current 41.5, max 48.5
Current date and time: 2017-01-07 12:52:54
Slowest main loop (seconds): 0.061462; fastest: 0.000183
=== Move ===
MaxReps: 4, StepErrors: 0, MaxWait: 4ms, Underruns: 0, 0
Bed probe heights: -0.289 -0.070 -0.311 -0.100 -0.703 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.5
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is ready with "M122"
telnet is idle
file is idle
serial is idle
aux is idle
daemon is idle
=== Network ===
Free connections: 15 of 16
Free transactions: 22 of 24
=== Webserver ===
HTTP sessions: 1 of 8
FTP connections: 0, state 0
Telnet connections: 0, state 0

Triangle interpolation: point outside all triangles!

guywinslow

I have the same issue as demonio669 Today 18:14. I also tried putting the M226 M25 in my print file and the printer went into a pause states and never ran the Pause macro file. Also i could not get anything to operate till i power cycled. This included sending the M24 command after disconnecting the browser and reconnecting the browser to the printer

demonio669

@guywinslow:

I have the same issue as demonio669 Today 18:14. I also tried putting the M226 M25 in my print file and the printer went into a pause states and never ran the Pause macro file. Also i could not get anything to operate till i power cycled. This included sending the M24 command after disconnecting the browser and reconnecting the browser to the printer

Yes I also have to press the emergency stop button to control the printer again

dc42

The M226 issue is fixed in 1.17b, which I am about to release. My thanks to chrishamm for the fix.

StephenRC

Had some time. I noticed on my DuetWifi, cancel.g only has G1 Y300 and it works fine and that bed is 400x300. So, on the Duet085, I edited my cancel.g to find the culprit and it's the G1 Y260 F3000. Decreased the y to G1 Y250 F3000, Triangle interpolation: point outside all triangles! error storm occurs. If I lower it to G1 Y240 F3000, the error storm doesn't happen. Go back to G1 Y250 F3000, no problem. But changing it back to G1 Y260 F3000, error returns until I put it back to G1 Y240 F3000. Bed is defined to be 300x270. I even tried deleting and making a new cancel.g, no change. If the file has everything commented but the G1 Y260 F3000 line, it still does the error. The bed does go right where the G1 tells it to go.

dc42

What happens if you send G1 Y260 manually?

That message means that the firmware thinks you are trying to move the head to a point a long way outside your 5 bed probe points. It most often occurs on homing moves, because the G1 S1 homing moves necessarily have an endpoint that may be well outside the bed.

You might want to try putting a G90 command before that G1 command, just in case it has somehow got into relative coordinates mode.

New firmware release 1.17a

cancel.g: M104 S0 ; turn off extruder M140 S0 ; turn off bed M106 S0 ; turn off part fan G1 X10 F3000 ; move x to left G1 Y260 F3000 ; move y to front G91 ; relative moves G1 Z10 ; raise z by 10 G90 ; absolute moves M84 ; disable motors

Also ran a M122 during the error storm:

cancel.g:
M104 S0 ; turn off extruder
M140 S0 ; turn off bed
M106 S0 ; turn off part fan
G1 X10 F3000 ; move x to left
G1 Y260 F3000 ; move y to front
G91 ; relative moves
G1 Z10 ; raise z by 10
G90 ; absolute moves
M84 ; disable motors