RepRapFirmware 2.0beta1 available

T3P3Tony

@whosrdaddy said in RepRapFirmware 2.0beta1 available:

@dc42 , I still have the file upload problem.
When upload is finished, DWC shows error and resets, the file itself has been uploaded correctly.

you can watch the problem in action here.

https://youtu.be/nM1sf3GiA3Y

In the video you will see that I downgrade to 1.21 and then redo the same test without any problem
1

Thanks for the detailed testing and feedback - this is realty appreciated!

mhackney

I've had really good success. I've printed several dozen parts and some were 6 hour prints. No noticeable differences and no hangs or other issues. I do everything from DWC although I have a PanelDue installed. I was doing some research/testing for a future blog post and must have done 10 mesh grid compensation runs and many more calibration runs on my delta.

AS-3D Druck

Nice to see how fast the devolpment of the 2.0 Firmware is going forward.
But @dc42 i thought you don't wanna implement new Features for now?

Added experimental Z probe type 10 (Z motor stall)

I'am exited to see if it works.

timcurtis67

Possible Bug? I trying to print with my U axis (IDEX) and the pressure advance was not working correctly (D1). The pressure advance seems fine for (D0).

The head slowed down on X Y moves and the extruder was pulling the material way back too far. I ended up reverting back to 1.21 and the same print now works fine.

Also after updating to 2.0 beta the files won't upload without an error. The complete file is uploading (checked the file after upload) but it says the is an error and disconnects.

One last thing was when I paused the print the Duetwifi board reset. (see M122 results).

10:05:47 AMM122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)beta1+ running on Duet WiFi 1.0 or 1.01 + DueX5
Board ID: 08DAM-999TL-MQ4S4-6JKDA-3S06M-95HMY
Used output buffers: 5 of 40 (18 max)
=== RTOS ===
Static ram: 28484
Dynamic ram: 96800 of which 0 recycled
Exception stack ram used: 400
Never used ram: 5388
Task NETWORK ready, free stack 416
Task HEAT blocked, free stack 1260
Task MAIN running, free stack 3800
=== Platform ===
Last reset 00:47:52 ago, cause: software
Last software reset at 2018-04-13 09:17, reason: User, spinning module GCodes, available RAM 5364 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 8
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 28.2, current 28.5, max 31.9
Supply voltage: min 23.9, current 24.0, max 24.3, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/45
Driver 1: standstill, SG min/max 222/289
Driver 2: standstill, SG min/max 22/294
Driver 3: standstill, SG min/max 0/23
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-04-13 10:05:45
Slowest main loop (seconds): 0.010206; fastest: 0.000072
=== Move ===
MaxReps: 3, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 234, MaxWait: 4293804511ms, Underruns: 0, 0
Scheduled moves: 6, completed moves: 6
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8

WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.21
WiFi MAC address 60:01:94:0c:4f:6d
WiFi Vcc 3.38, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 17192
WiFi IP address 10.0.0.137
WiFi signal strength -39dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Expansion ===
DueX I2C errors 0

timcurtis67

I should mention that when I was using 2.0 Alpha I had zero issues with file uploads. Beta doesn't upload correctly for me?

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.