New beta firmware 2.02beta1

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.

gdybz

@dc42 I am getting the same [Duet2CombinedFirmware.elf] Error 1 that others have posted about. I had this code running yesterday but when I tried to use it today I'm getting the error even after cleaning, restarting, and running index rebuild. I did not change any code or even exit Eclipse overnight.

brunofporto

@dc42 I would like to suggest to create a topic for each new feature and link them at the OP of these "new beta" posts. So we can focus and the subjects does not get lost.

For example my experience with DAA not showing much improvement

By the way. Besides the DAA not having much effect I had no issues or new bugs with this beta.

zerspaner_gerd

@dc42 said in New beta firmware 2.02beta1:

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

Yes, I have already read that!
I just mentioned that unfortunately it does not work in "Load Filament" Macro!

It works in other application cases.

wilriker

@zerspaner_gerd said in New beta firmware 2.02beta1:

I just mentioned that unfortunately it does not work in "Load Filament" Macro!

Do you mean that in the load.g macro for the filament (configured via context-menu for this filament in DWC) you are loading you want to add M703 to immediately also load the same filament's config.g?

zerspaner_gerd

@wilriker Here is a picture of my attempt:

0_1535137570727_load.g.JPG
But yes, I think we mean the same!

wilriker

@zerspaner_gerd Coincidently my loading macro looks exactly like your third line.
Anyway, the problem here certainly is that at this point in time the filament is not completely loaded in regards to firmware so it would not know which config.g to load with M703.

@dc42 and @chrishamm should this be like that? Is there a case where loading a filament (in software) could fail/abort? Otherwise the info about which filament is loaded could be saved as the very first step and this would resolve this race. I could look into changing this most likely on Monday.

dc42

Chrishamm wrote and maintains the filament management code, so I'll leave this for him to answer.

chrishamm

At present it is not intended to use M703 in the load.g macro because DWC already sends it after the filament has been loaded and because the filament name is NOT assigned until the load.g macro has finished AFAIR. A better place for M703 would be your tpost*.g macro because you usually want to apply different settings when you select a tool that is loaded with a different material.

At present DWC does the following when you load/change a filament:

A tool is selected using a T-code (if the selected tool is different)
If a filament is already assigned to the tool, it is unloaded via M702 which runs the unload.g macro of the old filament
M701 is invoked with the corresponding filament name, which runs the corresponding load.g. Do only the loading here (e.g. set temperatures, ask the user to insert filament and eventually load it)
M703 is invoked which runs config.g of the corresponding filament (if present). There you can set extrusion factors, pressure advance, temperatures and possibily the speed factor to use