RepRapFirmware 2.0beta1 available

hurzhurz · 14 Apr 2018, 15:19

@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 · 15 Apr 2018, 22:40

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 · 16 Apr 2018, 10:54

@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 · 18 Apr 2018, 11:04

@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 · 18 Apr 2018, 16:12

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 · 18 Apr 2018, 16:25

@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 · 19 Apr 2018, 16:58

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

timcurtis67 · 19 Apr 2018, 17:11

I'll try it out tonight. Thanks again.

hurzhurz · 19 Apr 2018, 17:56

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 · 19 Apr 2018, 18:16

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

dc42 · 19 Apr 2018, 18:46

@whosrdaddy, see the release notes.

whosrdaddy · 19 Apr 2018, 20:59

Ah must buy some glasses, did read the notes and somehow looked over it
Will test this tomorrow and report back.

whosrdaddy · 20 Apr 2018, 15:16

@dc42: The file upload problem still stands in beta2, behavior is exact the same as shown in the video I posted earlier.

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.0(RTOS)beta2 (2018-04-19b1)
WiFi Server Version: 1.21
Web Interface Version: 1.21.1-b3

dc42 · 20 Apr 2018, 16:12

With 2.0alpha I always had a disconnection unless the file was tiny. With 2.0beta1 I had a disconnection only with uploading certain file sizes. With 2.0 beta2 I don't see any disconnection. What upload file sizes cause disconnections for you? Do you have more than one device running DWC?

whosrdaddy · 20 Apr 2018, 16:18

@dc42 : only one dwc connection, tried a 2MB file and a 12MB file and both failed.
did some more testing and had success with a 1MB file.
Just to be clear, the file is correctly uploaded but DWC disconnects at the end.

timcurtis67 · 21 Apr 2018, 16:27

My Beta 2 disconnects when uploading larger files. Other than that it works perfect so far.

carlosspr · 22 Apr 2018, 14:11

I tried the Beta 2 today for two prints. Everything went fine. Then I wanted to go back to 1.21 and using DWC I hade to upload the Duet2CombinedFirmware.bit three times. The first two times I dod not receive the message to update the firmware. Once in 1.21 I changed some settings in config.g and on sage the DWC message detected a new firmware and asked again to update to 1.21. This can well be related to a "disconnect" after uploading a file although I did not notice on the DWC.

timcurtis67 · 23 Apr 2018, 10:52

@dc42 I can confirm that when uploading small files <1 meg it works fine. When uploading any larger files I get a disconnect.

I only ever run one device with DWC (Windows 7 Pro PC) and I only have 4 gcode files on my SD card.

Once I reconnect with DWC the prints run perfect.

dc42 · 23 Apr 2018, 19:46

Those of you who are still experiencing disconnects immediately after uploading a file with beta 2: are you using WiFi or Ethernet Duets?

whosrdaddy · 23 Apr 2018, 19:55

@dc42 : Wifi

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later + DueX5
Firmware Version: 2.0(RTOS)beta2 (2018-04-19b1)
WiFi Server Version: 1.21
Web Interface Version: 1.21.1-b3