RepRapFirmware 2.0beta1 available

Mysta · 12 Apr 2018, 14:38

My printer isn't up and running yet so I will probably start out with 1.21 but how is it running as far as speed with rtos?

dc42 · 4 Dec 2018, 15:21

@mysta said in RepRapFirmware 2.0beta1 available:

My printer isn't up and running yet so I will probably start out with 1.21 but how is it running as far as speed with rtos?

As a new user you should start with 1.21.

I have not detected any speed difference yet between 1.21 and 2.0beta1. Eventually I expect file upload to be faster, when I have done more work on 2.0.

Mysta · 12 Apr 2018, 15:24

@dc42 Awesome, glad to see forward progress! I agree with the least common denominator leave. It's one of the reasons Android has so many issues.

timcurtis67 · 12 Apr 2018, 16:33

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.

dc42 · 12 Apr 2018, 16:38

@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 · 12 Apr 2018, 19:01

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 · 4 Dec 2018, 19:34

@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 · 12 Apr 2018, 21:06

@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 · 4 Dec 2018, 21:11

@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 · 12 Apr 2018, 23:24

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 · 13 Apr 2018, 13:33

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 · 13 Apr 2018, 14:27

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 · 13 Apr 2018, 14:29

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 · 13 Apr 2018, 18:43

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 · 13 Apr 2018, 19:00

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

dc42 · 13 Apr 2018, 19:02

@mhackney, thanks for your feedback.

dc42 · 13 Apr 2018, 19:18

@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 · 13 Apr 2018, 19:27

@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 · 13 Apr 2018, 19:35

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 · 13 Apr 2018, 19:54

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