Please help us to test firmware 1.17RC3 and DWC 1.14
-
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!
-
Does the ratty right side of your print correspond to the big red peaks in the plot?
-
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. -
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.
-
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
M116Now 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.
-
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
-
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
M116You need a P0 parameter in the G10 command to tell it what tool you are setting the temperature for.
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.
-
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.
-
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.
-
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.
-
Yes, but a mm is a mile as far as that first layer is concerned
-
I'm getting lots of re -occurrences of the problems I reported earlier and also sometimes complete failure to connect unless I cycle the power to the printer. Sometimes but not always, I also get Ajax timeout errors. Sometimes after doing something like homeall, DWC seems to freeze for a few seconds. Quite often, if I just press one of the move buttons there is about a one second delay before the machine responds. Sometimes it doesn't respond at all and I have to repeat the action. I've just rolled back to DWC 1.13. If that doesn't fix it, I'll try rolling back to an earlier version of the firmware.
-
a small report, that I am currently confirming.
I finished a print last night and when i got home from work I tried to upload another gcode file to print but it wouldnt allow it until I did an M999 to reset the printer. I have another print running right now, I will test again to confirm this once this print finishes.
-
With the config_override method - unless I send m501 after booting the duet, the system uses the values in config.g correct?
This has caught me out a few times, as I presumed that this would function in the way marlin does loading the "eeprom" by default at boot.
Where do you see as being the best place to insert an m501 gcode so that it always loads config_override? Start gcode in the slicer? Put an m501 in config.g?
-
The recommended place to put the M501 command is at the end of your config.g file, just before the T1 command if you have one.
-
Thanks to all of you who provided feedback. I have now released version 1.17 of RepRapFirmware. There are no significant changes since RC3.
-
I have a great deal of trouble with the grid calibration.
I give it the M557 R140 S30 and then G29.
This is the result:
Now I know my bed is not that skewed or at that angle. The shape that it finds would mean there is a 1.6 mm difference from 1 side to the middle. Now, knowing David and how hard he works on this, I know it is not a software fault. So it must be my printer (Delta)
But using the "normal" calibration I get pretty good first layers put down.Any ideas?
-
My guess is that you have varying Z probe trigger height with XY position, caused by effector tilt or other factors. Whereas you can compensate for effector tilt when calibrating using the H parameter on the G30 command, no such compensation is possible for G29.
-
Thanks to all of you who provided feedback. I have now released version 1.17 of RepRapFirmware. There are no significant changes since RC3.
the "Push(): stack overflow!" regression introduced in 1.17 is still there.
I provided a simple macro to reproduce it, I guess the forum is not suitable for bugs/issues.
I'll fill a github issue tomorrow.Happy Xmas !
-
Thanks to all of you who provided feedback. I have now released version 1.17 of RepRapFirmware. There are no significant changes since RC3.
the "Push(): stack overflow!" regression introduced in 1.17 is still there.
I provided a simple macro to reproduce it, I guess the forum is not suitable for bugs/issues.
I'll fill a github issue tomorrow.Happy Xmas !
I'm sorry, I recall seeing the report but not a link to a macro that reproduces it. Please link to the relevant post.
