New beta firmware 2.02beta1

brunofporto

@phaedrux Here!
Left DAA (40Hz) Right No DAA

burtoogle

@gtj0 said in New beta firmware 2.02beta1:

@dc42 said in New beta firmware 2.02beta1:

A Flex3drive might require pressure advance to compensate for the torsional elasticity of the Bowden cable. I've never used one, so I don't know whether this is the case or not.

I don't use pressure advance on my flex3drive and the corners are way sharper than any bowden I've used. I think the high gear ratio takes care of that.

Apologies for the off-topic question but what speed, accel, jerk are you using with the flex3drive? I am using 25, 400 and 10 with no pressure advance and normally get good results.

zerspaner_gerd

Too bad that M703 does not already work with filament loading.

Thus, no change to the filament load macro would be necessary!

dc42

@zerspaner_gerd said in New beta firmware 2.02beta1:

Too bad that M703 does not already work with filament loading.

Doesn't it, in firmware 2.02beta1?

zerspaner_gerd

@dc42 said in New beta firmware 2.02beta1:

@zerspaner_gerd said in New beta firmware 2.02beta1:

Too bad that M703 does not already work with filament loading.

Doesn't it, in firmware 2.02beta1?

When filament loading it does not work (no temperature is set, no error messages)
My guess is that the filament name is updated only after the load, so M703 has no macro name.

When unloading it works!

dc42

Have you read https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M703_Configure_filament to see how M703 is intended to be used?

gtj0

@burtoogle said in New beta firmware 2.02beta1:

@gtj0 said in New beta firmware 2.02beta1:

@dc42 said in New beta firmware 2.02beta1:

A Flex3drive might require pressure advance to compensate for the torsional elasticity of the Bowden cable. I've never used one, so I don't know whether this is the case or not.

I don't use pressure advance on my flex3drive and the corners are way sharper than any bowden I've used. I think the high gear ratio takes care of that.

Apologies for the off-topic question but what speed, accel, jerk are you using with the flex3drive? I am using 25, 400 and 10 with no pressure advance and normally get good results.

XY Speed: 80 mm/s
XY Accel: 1000 mm/s^2
XY Jerk: 800 mm/min

E Accel: 125 mm/^s
E Jerk: 120 mm/min

No pressure advance

I haven't even attempted to do any advanced tuning let alone tried to tune out the ringing yet but the corners are pretty sharp.

burtoogle

@gtj0 said in New beta firmware 2.02beta1:

XY Speed: 80 mm/s
XY Accel: 1000 mm/s^2
XY Jerk: 800 mm/min
E Accel: 125 mm/^s
E Jerk: 120 mm/min

Thanks for the numbers. Interesting, very different from what I am using. For the extruder, I am using higher acceleration and much smaller jerk (currently 1000 and 10 , respectively) and get good results. Until recently I have been using 400 for the accel and have upped it to 1000 now as it still behaves OK. 3000 was too much as it wasn't retracting at all using that. I shall try increasing the jerk now.

burtoogle

I upped the extruder jerk to 100 and it's printing fine along with extruder acceleration of 1000.

Back to testing M593. The results I am seeing are still very much like the picture I posted earlier in the thread in that some ringing that was occurring after a relatively shallow hole was pretty much getting removed but ringing that occurred downstream of a longer edge wasn't being reduced (or maybe just a little, hard to tell).

Another oddity is that when I print that little 20mm widget that has X and Y and dots on the other sides. I get more ringing downstream of the X / Y / dots in the upper half of the print than the lower half and the upper half of the model has rounded corners and the lower half has sharp corners! When not using M593, the amount of ringing downstream of the X / Y / dots is similar for both the top and the bottom of the print. Don't understand that at all.

GizmotronX5000

Were there any changes in the compiling process? I brought these files into Eclipse, but when I go to compile I get about 30 errors coming from "WiFiInterface.h". Most are of the form "symbol/type xxxxx cannot be resolved." I also get this error: make: *** [Duet2CombinedFirmware.elf] Error 1.

I have make.exe and MessageFormats.h in a folder included in the path, and I can confirm that they are listed in the includes folder of the project. Is that still the correct process?

dc42

@burtoogle said in New beta firmware 2.02beta1:

I upped the extruder jerk to 100 and it's printing fine along with extruder acceleration of 1000.

Back to testing M593. The results I am seeing are still very much like the picture I posted earlier in the thread in that some ringing that was occurring after a relatively shallow hole was pretty much getting removed but ringing that occurred downstream of a longer edge wasn't being reduced (or maybe just a little, hard to tell).

Another oddity is that when I print that little 20mm widget that has X and Y and dots on the other sides. I get more ringing downstream of the X / Y / dots in the upper half of the print than the lower half and the upper half of the model has rounded corners and the lower half has sharp corners! When not using M593, the amount of ringing downstream of the X / Y / dots is similar for both the top and the bottom of the print. Don't understand that at all.

Thanks for trying this out. It sounds like I still have a little more work to do on this feature.

wilriker

@gizmotronx5000 You might have to update to the latest MessageFormats.h from DuetWifiSocketServer dev branch. I had the same issues until I did that. No issues since then anymore.

GizmotronX5000

I thought it might have something to do with that, but I just grabbed the most recent version and tried again. No luck. It looks like I probably had the most recent version already, since it was last updated in March 2018. I added it to my includes. However, I see if I open WiFiInterface.h there is a warning saying "Unresolved inclusion MessageFormats.h". I must not be including it properly or maybe there is some sort of conflict?

wilriker

@gizmotronx5000 Did you include it as a workspace path or as an absolute filesystem path in eclipse? I did the latter and explicitly have DuetWifiSocketServer not in my workspace at all.

GizmotronX5000

It's an absolute file system path not included in my workspace. I don't have the duetwifisocketserver project, just the messageformats.h, which worked before.

wilriker

@gizmotronx5000 I'm sorry, but now I run out of ideas.

dc42

@gizmotronx5000 said in New beta firmware 2.02beta1:

I get about 30 errors coming from "WiFiInterface.h". Most are of the form "symbol/type xxxxx cannot be resolved." I also get this error: make: *** [Duet2CombinedFirmware.elf] Error 1.

it would help if you post the exact error messages.

GizmotronX5000

@dc42 Good point! I managed to get rid of the make.exe errors somehow. I nuked the project and just restarted it from the build instructions. It now compiles, but I still get the following errors, which are apparently not critical to the build.

GizmotronX5000

@gizmotronx5000

I cleaned all of the projects and restarted Eclipse (again). Everything compiles without errors now. Magic!

dc42

Eclipse sometimes reports Semantic Errors spuriously, or generates them correctly but doesn't remove them when you correct the problem - especially if the correction involves an include file that is outside the project. These are generated by Eclipse, not by the compiler. Often they go away if you run index rebuild on the project and bring the file for which the errors were reported to the foreground. Other times you may need to delete them, then clean and build the project to make sure there are no compiler errors or warnings.