RepRapFirmware 2.0beta1 available

Shen

I'm having a problem with stall detection as Z probe. Every time when I run two G30 commands in a row, the probe always fail to trigger on the second G30. However, I can run my homez.g script that uses stall detection as endstop as many times as I want, and it would always trigger.

dc42

Can you confirm that it is failing to trigger at all, rather than triggering too early?

dc42

@mhackney, thanks for your feedback.

dc42

@timcurtis67, thanks for your report. The loss of connection after uploading a file when there are many files on the SD card is a known issue, but the other two issues puzzle me. If you load 2.0beta1 again, please try sending M572 without parameters and check that the pressure advance values reported are as you set them in config.g. The reset is puzzling because the software reset data suggests a deliberate reset as if M999 had been sent or the Emergency Stop button pressed.

Shen

@dc42
Here is the video showing 4 G30 executions. The first one is successful, the second one fails. After the second one I ran M84 Z to release Z motors so I can balance the bed. The third G30 runs fine, the fourth one fails again. It's always the second G30 that fails.
https://www.youtube.com/watch?v=n8dddFaQKXk

Shen

Also I forgot to mention. This only happens when I set M558 A3 to probe three times, and it ALWAYS fail to trigger on the second G30. When I only probe once(M558 A1), it's successful every time.

Shen

Ok, I found that if I lower the bed after the first G30 then the second G30 would work. Maybe the second G30 did not reach high enough speed? but then why would the second probe in the first G30 succeed? Strange...

timcurtis67

@dc42 said in RepRapFirmware 2.0beta1 available:

@timcurtis67, thanks for your report. The loss of connection after uploading a file when there are many files on the SD card is a known issue, but the other two issues puzzle me. If you load 2.0beta1 again, please try sending M572 withoit parameters and check that the pressure advance values reported are as you set them in config.g. The reset is puzzling because the software reset data suggests a deliberate reset as if M999 had been sent or the Emergency Stop button pressed.

Thanks dc42,
I will reload 2.0 beta again tomorrow and send the M572 and report back. I am running the exact same program on 1.21 without any issues. Its been running for about 4 hours now.

My setting that I use 90% of the time (in that case as well with the error) is M572 D1 H.3 for the U extruder and M572 D0 H.3 for the X extruder.

hurzhurz

Hi,
I have just tried 20beta1 and probably had a problem with retraction / absolute extrusion.

The skirt was printed fine, but then a retraction happened for travelling to the wall of the first object.
But it looked like no un-retraction happened after the travell. It printed a lot of air until something was visible again.
The same happened when it travelled to the starting point of the second object.

So I went back to 1.21 and tried to print the same file again. Worked fine...

https://www.dropbox.com/s/hrvfeysf6rhws0t/CFDMP_AdapterV3_2.gcode?dl=0

dc42

@hurzhurz said in RepRapFirmware 2.0beta1 available:

Hi,
I have just tried 20beta1 and probably had a problem with retraction / absolute extrusion.

The skirt was printed fine, but then a retraction happened for travelling to the wall of the first object.
But it looked like no un-retraction happened after the travell. It printed a lot of air until something was visible again.
The same happened when it travelled to the starting point of the second object.

So I went back to 1.21 and tried to print the same file again. Worked fine...

https://www.dropbox.com/s/hrvfeysf6rhws0t/CFDMP_AdapterV3_2.gcode?dl=0

That's odd, because i haven changed the motion code at all. The changes in 2.0beta1 that are most likely to have broken something are:

Replaced the library version of strtod by our own. So parsing some formats/values of floating point numbers may have been broken.
Replaced the library versions of printf etc. by our own. So the display of values to DWC and PanelDue or the saving of values to config-override.g might have been broken.
Changed the behaviour when G30 is used after using G29 to generate a height map or load an existing height map.
Changed the behaviour of G0.
Reduced the size of each output buffer (to the size that was already used on the older Duets), but increased the number of them. It is this change that indirectly cause network disconnects after uploading GCode files in some cases.

hurzhurz

@dc42 I think the problem is G0:

I have now manually executed this part of the file line by line:

G1 X132.926 Y110.585 E17.18712
G1 F1500 E10.68712
G0 F3600 X134.258 Y112.882
G0 X135.21 Y113.742
G0 X134.764 Y119.78
G0 X134.862 Y119.798
;TYPE:WALL-INNER
G1 F1500 E17.18712

Looks like each G0 line causes a retract, with about the same amount like the G1 before did...

DjDemonD

Just installed this on my cylinder delta, with no drama, had to rename to DuetWifiFirmare.bin to get it to install.

Printing now, no issues, can't see any difference in print quality from 1.21, but then I suppose the gains are in what is to come?

timcurtis67

@dc42 said in RepRapFirmware 2.0beta1 available:

@hurzhurz said in RepRapFirmware 2.0beta1 available:

Hi,
I have just tried 20beta1 and probably had a problem with retraction / absolute extrusion.

The skirt was printed fine, but then a retraction happened for travelling to the wall of the first object.
But it looked like no un-retraction happened after the travell. It printed a lot of air until something was visible again.
The same happened when it travelled to the starting point of the second object.

So I went back to 1.21 and tried to print the same file again. Worked fine...

https://www.dropbox.com/s/hrvfeysf6rhws0t/CFDMP_AdapterV3_2.gcode?dl=0

That's odd, because i haven changed the motion code at all. The changes in 2.0beta1 that are most likely to have broken something are:

Replaced the library version of strtod by our own. So parsing some formats/values of floating point numbers may have been broken.

Replaced the library versions of printf etc. by our own. So the display of values to DWC and PanelDue or the saving of values to config-override.g might have been broken.

Changed the behaviour when G30 is used after using G29 to generate a height map or load an existing height map.

Changed the behaviour of G0.

Reduced the size of each output buffer (to the size that was already used on the older Duets), but increased the number of them. It is this change that indirectly cause network disconnects after uploading GCode files in some cases.

@dc42 I will reload 2.0 Beta tonight and get you the M572 info. I did go through my gcode file to make sure there weren't any "G0" with an E move in them. I didn't find any but I do have several G0 moves around G0 moves. I sliced with Cura 3.2.1.
Maybe the new G0 changes are causing the issues with pressure advance as to how it looks ahead in the gcode file for motion planning? These problems only happen when I apply pressure advance to D1 (M572 D1 S.3). When using M572 D0 S.3 on my other extruder on Drive X it worked just like 1.21. I had run 4-5 parts without any issues. The problem popped up when I switched to the other head with the .8mm nozzle.

Anyway, I finished up the projects last night so today I will get back on testing 2.0 beta and report back.

Is there a way to only have the G0 calls operate the new way while in CNC Mill mode? And work as it always did before while in 3D printer mode?

timcurtis67

@dc42 I finally got 2.0 beta back in for some testing. I ran an M572 and got back .000,.300 result which is what I should get. I was running Pressure advance with this setting (M572 D1 S.3).
As you can see in the picture, there are places where the head stops and the extruder places large blotches of plastic. I guess pressure advance is working but it looks more like a G0 issue with planned moves? When I revert back to 1.21 and run the same program it works perfect. Strange part is it didn't act this way when running my other print head and using (M572 D0 S.3). I will confirm that again tonight but I did run several parts on 2.0 Alpha without any issues. I didn't see any problems till I tried running a print with my other print head using M572 D1 S.3.

https://photos.app.goo.gl/843qx9v78aPUum2n2

Here is the gcode I was running. The problems start right away.

https://drive.google.com/file/d/1g_UTX6Wti0N_5v-pEEj26_S0FvPf3e0g/view?usp=sharing

Please advise,

dc42

Tim, I can confirm that in 2.0beta1 when a G0 command follows a G1 command with extrusion, the G0 command repeats the extrusion. I have fixed it and I will release a new beta tonight or tomorrow.

timcurtis67

@dc42 said in RepRapFirmware 2.0beta1 available:

Tim, I can confirm that in 2.0beta1 when a G0 command follows a G1 command with extrusion, the G0 command repeats the extrusion. I have fixed it and I will release a new beta tonight or tomorrow.

Great! I will watch for the update and try it out asap. Not sure where you get the time to keep up with these updates but I thank you sincerely.

dc42

Firmware 2.0beta2 is now released at https://github.com/dc42/RepRapFirmware/tree/v2-dev/EdgeRelease.

timcurtis67

I'll try it out tonight. Thanks again.

hurzhurz

I did a quick test with my file where I noticed the G0 problem.
I had stopped the print after a few layers, but it looked good so far, thanks!

whosrdaddy

@dc42: any progress on the file upload problem in the latest beta?