RepRapFirmware 2.0beta1 available

dc42

@timcurtis67 said in RepRapFirmware 2.0beta1 available:

So far I haven't run into any type of bugs. The longest print I ran was 2 hrs. I had one reset but it could have been power related, I have my battery backup unhooked right now.

The file upload speed appears to be slightly faster but it could just be the files I was uploading. I was seeing 700+ on the upload speeds.

Otherwise it seems to behave the same as 1.21.

Thanks. If you get another reset, please run M122 to check the cause.

Catalin_RO

I also moved to latest 2.0 beta. So far I did only some air cutting with a G2/G3 test scenario. After a thorough testing, the offending G-Code could be executed at 2100mm/min with 1.21 firmware, and also with 2.0 beta. At 2140mm/min both firmware versions had similar issues (WorkBee sounded like breaking apart and missed steps). Tomorrow I will have more machining to do and I will be using 2.0 beta if nothing looks horribly wrong.

The G0 (maximum feedrate) and G2/G3 (only one of X/Y and one of I/J) improvements reduced the GCode files by at least 10%. Overall that is a really good thing!

whosrdaddy

@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

dc42

@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

Thanks. Since I implemented the fix I have had the problem recur, but only with files in a narrower range of sizes. I will investigate it further next week. Meanwhile, a workaround is to reduce the number of files in /gcodes, for example by moving some of them into subdirectories.

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