Please help us to test firmware 1.17RC3 and DWC 1.14

burtoogle

Understood.

The sensor is offset from the nozzle by about 10mm in the NW direction. I find it hard to believe that the effector tilts sufficiently to create the amount of error I am seeing in just 10mm. I have measured the tilt before and did adjust the spacing of the arms to reduce the tilt. It doesn't tilt much now.

Is it possible to shift the map to compensate the for the offset of the height sensor from the nozzle?

lolorc

Hi,

I have a macro in which there is :

[[language]]
M120
G91
G1 Z-0.01 F6000
M121

It gives an error when trying to execute it. M98 P0:/macros/test Push(): stack overflow!

also If I create this macro with DWC and call it "Z-0.01" it appears as "Z-0.01" in the macro list, but it appears as "Z-0" on the machine control tab

hairy_kiwi

Hi David,

Thank you and Chrishamm for all your great work!

In the last weeks I've been getting Wiener90 (a Mendel90 derivative) up and running with DWF while playing catch up with the latest firmware releases since I bought my DWF and IR z-probe a few months back.

I'll probably not be able to feedback too much on 1.17RC3 before you release, but FWIW a couple of points:

1. Some of the release notes appear contradictory regarding G29:

line numbers copied from https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW

[[language]]
37 - Implemented G29 S1 (load bed height map from file)
...
45 - G29 grid bed compensation is fully implemented except for G29 S1 (load height map from file)
...
50 - G29 can now be used to do bed probing, however the results are not used yet

2. General feedback: In DWC 1.13, Extruder Control > Feedrate (mm/s)
While calibrating my 2.85mm dia extruder running an E3Dv6 hotend I subsequently discovered a) I only had a 30W heater cartridge installed(!), and b) this necessitated a feed rate less than the minimum value available (5mm/s). The only way of achieving that was to temporarily reduce the max E feedrate via the gcode console/config.g. Perhaps after I upgrade to a 40W heater cartridge a 5mm/s E feedrate will be achievable. Nevertheless, that's still a significantly faster filament feedrate for 2.85mm dia material than would normally be used at a print speed of say 50mm/s using a 0.4mm dia nozzle.

I look forward to being of more help in the new year - including writing a post about using DuetWifi with Wiener90 as soon as I get the early-day gremlins sorted.

Cheers, and Merry Christmas to everyone on the Duet3D dev team.

lolorc

I like the visual representation after G29.
is it be possible to display it from the existing heightmap.csv (without running G29 again) ?

lolorc

@lolorc:

M98 P0:/macros/test Push(): stack overflow!

Hmm it looks like it's not related to the macro.
I just tried to issue a G28, the printer does home.
and just after that i issued a G32, here's the result:

[[language]]
G32
Push(): stack overflow!
Attempt to move the head of a delta printer before homing the towers
Error: Must home a delta printer before bed probing
Error: Must home a delta printer before bed probing
Error: Must home a delta printer before bed probing
Error: Must home a delta printer before bed probing
Error: Must home a delta printer before bed probing
Error: Must home a delta printer before bed probing
Error: Must home a delta printer before bed probing
Error: Must home a delta printer before bed probing
Error: Must home a delta printer before bed probing
Error: Must home a delta printer before bed probing
Error: Must home printer before G29 bed probing
Attempt to move the head of a delta printer before homing the towers

dc42

Stack overflow usually means that the macro you are running is directly or indirectly recursive. For example, if your bed.g file contains a G28 command, and your homedelta.g file contains a G32 command.

lolorc

hmm what's wrong with my test macro ? it was working before with 1.16.
Also, the multiple stack overflow errors happened without any changes.
i powered the printer, did upload both firmware and DWC. did a G29, did an emergency stop, did a G29 again.
G32 used to work before.

and now G32 now says : Macro file homedelta.g not found.

I have not cold reset my board, but I'm pretty sure if I do it will work again…
(I'm not cold reseting because I had an issue with rc1. using DWC the printer stopped responding after a successful print, I did cold reset and it worked again, I guess I should have tried to connect to usb and try to debug the issue)

mhackney

@lolorc - yes you can do that:

Settings->Machine Properties "Download Heightmap"

actually shows the map in the visualizer. Seems like a poor choice of label for this button! Should be Show Heightmap or something similar I think. You can download the heightmap, look at the raw data and even tweak it using Settings->System Editor. I accidentally probed a bed clip so I just edited that one value, very convenient.

mhackney

@dc42 - is Chrishamm's code available anywhere? He hasn't updated his repository with the 1.14-b4 stuff yet. I'd like to create a free-standing heightmap visualizer using his code to make it easy to compare and look at archived heightmaps.

lolorc

@mhackney:

@lolorc - yes you can do that:

Settings->Machine Properties "Download Heightmap"

actually shows the map in the visualizer. Seems like a poor choice of label for this button! Should be Show Heightmap or something similar I think. You can download the heightmap, look at the raw data and even tweak it using Settings->System Editor. I accidentally probed a bed clip so I just edited that one value, very convenient.

Oh, i see, thanks

burtoogle

So I put some tape on the bed to the S of the centre line and did a scan, here's a picture of the result, I have rotated the picture but you can see the axis arrows and confirm that the huge block is to the S of the centre. It does not extend as far as the E of the bed. BTW - that gives a good indication of how much error the bed has.

Here's a photo of the print of my test rectangle looking in a N direction. Note that the bad print is all on the E side of the rectangle (which did not have any tape to raise the bed height). The S side of the rectangle falls into the region that had been taped and I would have expected that to be badly printed but it's actually fine.

If I didn't know better, I would say that the heightmap has been rotated through 90 deg counter clockwise!

mhackney

Does the ratty right side of your print correspond to the big red peaks in the plot?

lolorc

@lolorc:

hmm what's wrong with my test macro ? it was working before with 1.16.
Also, the multiple stack overflow errors happened without any changes.
i powered the printer, did upload both firmware and DWC. did a G29, did an emergency stop, did a G29 again.
G32 used to work before.

and now G32 now says : Macro file homedelta.g not found.

I have not cold reset my board, but I'm pretty sure if I do it will work again…
(I'm not cold reseting because I had an issue with rc1. using DWC the printer stopped responding after a successful print, I did cold reset and it worked again, I guess I should have tried to connect to usb and try to debug the issue)

cold reset did not fix the stack overflow issue with the simple macro.
I had to revert back to 1.16 (2016-11-08)
all 1.17 version (dev8, rc1 and rc3) have the issue.

deckingman

Yesterday I updated both the firmware to 1.17RC3 from whatever version it was on 9th November (sorry, can't remember the version number) and the web interface to 1.14 from 1.13 and since then I'm getting some odd behaviour that I've not seen before. It could be something else (although I haven't changed anything else on my PC) and just coincidental but sometimes the web interface is very slow to respond. It will take up to 90 seconds to load the page and sometimes fails to connect at the first attempt. When it does start like that, everything is very slow to respond. There is about a 1 second delay between pressing any button on the machine control panel and printer actually making the move. If I disconnect and cycle the power to the printer, then reconnect most times it all works as expected. I'll keep monitoring and if it persists, I'll roll back either the firmware or the DC to see if I can isolate it.

DjDemonD

Quick report - just loaded rc3 from rc1. The only issue I had is that it did not select a tool to heat the hot end when previously it would do so without a problem. I was using:
G10 S[first_layer_temperature]
T0
M116

Now I am using

M109 S[first_layer_temperature] T0

and its working normally.

Love the heightmap graphical output, though if I switch to top view, I can't seem to go back to side view.

mjhall29

Just updated after changing my hotend to a PT100.
First thing the PT100 reports 2000C, maybe it is no good as it is the first time i have tried it?
But worst i do not get mt system DIR listed it just says loading, so i have to edit it on a PC?
Usually this sort of thing means I have done something wrong Any ideas???

Thanks Martin

dc42

@DjDemonD:

Quick report - just loaded rc3 from rc1. The only issue I had is that it did not select a tool to heat the hot end when previously it would do so without a problem. I was using:
G10 S[first_layer_temperature]
T0
M116

You need a P0 parameter in the G10 command to tell it what tool you are setting the temperature for.

@DjDemonD:

Love the heightmap graphical output, though if I switch to top view, I can't seem to go back to side view.

You can drag the height map around to change the perspective. The Top View button is just a quick way of setting a particular perspective.

burtoogle

@mhackney:

Does the ratty right side of your print correspond to the big red peaks in the plot?

The really big red area in the plot is located to the S of the middle of the bed. That's where I put the tape before I did the G29 scan. I then removed that tape and printed a single layer of the test rectangle. If the height map was working as I expected, I would have thought that the lower portion of the print would be ratty as the height map would have shown that region of the bed was high and so the nozzle would be raised by the tape thickness.

But what happened is that the ratty region is centered on the E side of the rectangle rather than the S side and that makes me think that the height map has been rotated or transformed in some way.

I should say that with the height map disabled, the rectangle prints out fairly well, much better than the above photo.

burtoogle

A suggestion for the heightmap display: how about showing the -ve peaks in a different colour, i.e. blue so then when you view the graphic from above that it would be obvious what is high and what is low.

StephenRC

That height map display sure does exaggerate the height differences. When I first saw the map for my corexy, it looked like it was tilted at a 45 degree angle, but the bed was really only tilted a millimeter or so.