Please help us to test firmware 1.17RC3 and DWC 1.14

mhackney · 23 Dec 2016, 17:56

Yes, but a mm is a mile as far as that first layer is concerned

deckingman · 23 Dec 2016, 18:10

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.

Sniffle · 24 Dec 2016, 02:51

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.

DjDemonD · 24 Dec 2016, 08:45

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?

dc42 · 24 Dec 2016, 09:06

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.

dc42 · 24 Dec 2016, 12:01

Thanks to all of you who provided feedback. I have now released version 1.17 of RepRapFirmware. There are no significant changes since RC3.

Zesty_Lykle · 24 Dec 2016, 14:47

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?

dc42 · 24 Dec 2016, 16:49

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.

lolorc · 24 Dec 2016, 17:48

@dc42:

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 !

dc42 · 24 Dec 2016, 19:04

@lolorc:

@dc42:

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.

lolorc · 25 Dec 2016, 21:42

Hi,

Merry XMAS !
the macro I provided was enclosed by M120 & M121. I read RRP does add them, no need to write them in the macro.
So it's all my fault (it wasn't complaining about that with 1.16 but hey it's now ok)

only thing left is: a macro named Z-0.01 in the macro editor (dwc) appears as Z-0 in the machine control tab. (ultra minor bug)

dc42 · 26 Dec 2016, 06:44

Thanks, I'll check it out.

Zesty_Lykle · 26 Dec 2016, 07:44

@dc42:

My guess is that you have varying Z probe trigger height with XY position, caused by effector tilt or other factors.

OK, that is probably the case, but how to check what is causing it. The normal calibration does give consistent results and gives me a good first layer. So it does not feel as if the thing is out of whack, but I agree it is the most likely answer. Any suggestions as to how I can figure out where the issue(s) reside?

lolorc · 26 Dec 2016, 12:33

@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.

Hi,
I'm also interested in having access to the source of DWC 1.14 , I'd like to test some changes as well.
for now I'm using https://github.com/igrr/mkspiffs (./mkspiffs -b 8192 -p 256 -s 3125248 ) to extract the files. but the css/js stuff has been yui-compressed so it's not relly straightfoward to work with…

Zesty_Lykle · 26 Dec 2016, 14:06

After still having strange grid calibration results, I switched arms around. On the theory that if the geometry of the arms is not correct I should see it in the calibrated shape. No change, what so ever. No change if I switch one arm, or all the arms. So I am guessing that the length of my arms is pretty identical.
So I put everything back the way it was and then rotated the effector. No change, same pattern.
It dips deeply between the left and back column and towards the right column. In the middle it is highest.
So that would point to the right column, yes? But in what way? I'll have to think about it.

I think I will start a separate thread about this. No need to clutter up the 1.17 thread

dc42 · 26 Dec 2016, 17:45

@lolorc:

the macro I provided was enclosed by M120 & M121. I read RRP does add them, no need to write them in the macro.
So it's all my fault (it wasn't complaining about that with 1.16 but hey it's now ok)

I found the problem. If M120 succeeds then execution of the current file stops. So it never gets to do the M121 and after running the macro a few times, the stack for that input channel reaches its maximum depth of 5. Will be fixed in next release.

@lolorc:

only thing left is: a macro named Z-0.01 in the macro editor (dwc) appears as Z-0 in the machine control tab. (ultra minor bug)

Yes, I see that too. I'll alert chrishamm to it.

mhackney · 26 Dec 2016, 20:34

Lykle, what probing technology are you using? If the HE280 accelerometer, send me an email.

sdigs · 27 Dec 2016, 05:23

Anyone having an issue with files not showing up in uploaded list after upgrading to current edge firmware and DWC. I have uploaded a couple of jobs with printing them and i can not find them in the list. This is the first time I have seen this. Running the 1.17RC3 and the 1.14-b4 DWC. Thought I would ask if anyone else is seeing this.

deckingman · 27 Dec 2016, 09:27

Since rolling back from DWC 1.14 to DWC 1.13 the connection problems and slow response issues that I reported on earlier seem to have gone away.

Firebug24k · 28 Dec 2016, 00:48

Found a bug with the DWC - when I enter in my webcam URL for the "Webcam Surveillance" preview, only every other "refresh" displays an image. For example, if I say update every 10 seconds, for 10 seconds a picture is displayed, then for ten seconds a broken image is displayed, then 10 seconds of a new correct image, then 10 seconds of a broken image…. etc. By broken image I mean an invalid JPEG, the browser won't display it.