New beta firmware 2.02beta1

[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:

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:

1. A tool is selected using a T-code (if the selected tool is different)
2. If a filament is already assigned to the tool, it is unloaded via M702 which runs the unload.g macro of the old filament
3. 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)
4. 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

[brunofporto]

@chrishamm said in New beta firmware 2.02beta1:

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

Would be interesting to call the config.g for filaments with another name to avoid consfusion. Something like fconfig.g

[spw]

@dc42 great work on adding S parameter to control laser PWM
I have a suggestion to make it more compatible with other laser engravers and Laserweb software:
When S parameter is not provided it should keep the previous PWM value instead of turning off the laser, the G0 should turn off the laser
Example output from Laserweb:

G0 X86.61 Y21.34
G1 X86.61 Y21.34 S255.00 F1300
G1 X86.61 Y21.33
G1 X86.62 Y21.33
G1 X86.62 Y21.33
G1 X86.62 Y21.33
G1 X86.62 Y21.33

G0 X91.07 Y16.73
G1 X91.07 Y16.73 S255.00 F1300
G1 X91.07 Y16.73
G1 X91.07 Y16.73
G1 X91.06 Y16.73
G1 X91.06 Y16.73
G1 X91.06 Y16.72
G1 X91.06 Y16.72

[dc42]

@spw, it's a shame they chose to make it work that way. It would have been much safer to default to zero power. Anyway, I'll change it. I'll also need to make sure that the laser is turned off at pause and on again at resume. Tedious...

[samlogan87]

Hi everyone,

I upgraded to this version a week back as I was having issues with the official release before this. One thing I have noticed with this is that the extruder temperature is not always set when loading the GCode. I am using Cura 3.4.1 and printing directly to the printer via the plugin. Looking at the start of the g code it is setting the temperature, but when you start a print, the bed heats up and the extruder is set to 0 degrees.

Here is the start of the gcode file:

;FLAVOR:RepRap
;TIME:6266
;Filament used: 11.8932m
;Layer height: 0.2
;Generated with Cura_SteamEngine 3.4.1
T0
M190 S50
M104 S200
M109 S200
M82 ;absolute extrusion mode
; Startup Gcode
G91 ; Relative Positioning
G1 Z5 ; Move Z down 1mm
G90 ; Absolute Positioning
G28 XY ; Home XY
M561 ; Clear any bed transform
G32 ; Start 3-point probe sequence
G28 Z ; Home Z
M375 P"heightmap.csv" ; Load heightmap
G1 Z20.0 F6000 ; Move Z to 20
G1 X10 Y10 ; Move Head to front left
M582 T1 ; check levels of inputs that give rise to trigger #1
G92 E0 ; Zero Extruder
G1 F200 E30 ; Prime the extruder
G92 E0 ; Zero Extruder
M83 ;relative extrusion mode

Can anyone shed any light on this? Is it the plugin or the firmware?

Kind Regards,
Sam