Strange Z error

[fcwilt]

@suntoxx said in Strange Z error:

@fcwilt Thanks, this looks good. From where do you get for example the "sensors.probes[0].offsets[0]"? Is there a list somewhere?

The DWC has a plug-in for browsing the object model:

If it is not started just start it and then you can browse through the object model.

Some of what I know is just from trial-and-error, other things were picked up here on the forum.

Frederick

[Phaedrux]

This post is deleted!

[sunToxx]

@fcwilt said in Strange Z error:

The DWC has a plug-in for browsing the object model:

Oh, I completely missed that part of dwc somehow, as the plug in section in machine specific was empty. But from where in there do you get that with sensors.probes[0].offsets[0] you can refer to the current value? This is probably possible with most variables?

[fcwilt]

@suntoxx said in Strange Z error:

@fcwilt said in Strange Z error:

The DWC has a plug-in for browsing the object model:

Oh, I completely missed that part of dwc somehow, as the plug in section in machine specific was empty. But from where in there do you get that with sensors.probes[0].offsets[0] you can refer to the current value? This is probably possible with most variables?

Did you browse to that part of the object model?

Frederick

[sunToxx]

@fcwilt to which part?

[fcwilt]

@suntoxx said in Strange Z error:

@fcwilt to which part?

The section you asked about.

[sunToxx]

@fcwilt but I do not see the names you can use to call for those values there. That's what I was refering to. A list of those.

[fcwilt]

@suntoxx said in Strange Z error:

@fcwilt but I do not see the names you can use to call for those values there. That's what I was refering to. A list of those.

The names you need are shown in the browser.

The order is shown by the position.

For example:

sensors.probes[0].diveHeight

When you can have multiple things, like probes, you will see a number like the 0 beneath probes. You use that number in the square brackets as shown above.

Or are you talking about something else?

Frederick

[sunToxx]

@fcwilt ah, damn, i missed that all the way up there to the right. The disadvantage of 43" screens Thanks!

Do you by any chance know how to use the Echo command to create a macro?

[fcwilt]

@suntoxx said in Strange Z error:

Do you by any chance know how to use the Echo command to create a macro?

I have no idea - I didn't even know that was possible.

Why do you need to do that?

Frederick

[infiniteloop]

@suntoxx said in Strange Z error:

Do you by any chance know how to use the Echo command to create a macro?

Maybe I can help out?

; create a macro file with all the settings we need to continue the print:
; - first, verify the existence of the appropriate print file ...

var fName = "xfridge.g"
if exists(param.F)
	set var.fName = param.F

echo >{var.fName} "; Frozen print state of """^{job.file.fileName}^""", condition: "^var.cCondition
echo >>{var.fName} ""
echo >>{var.fName} "M38 """^{job.file.fileName}^""""								; on unfreeze, look if the file in print still exists
echo >>{var.fName} "if result > 0"													; result: 0=file exists, 1=call failed, 2=file not found
echo >>{var.fName} "    set global.xFrozenState = 0"
echo >>{var.fName} "    if !exists(param.X)"
echo >>{var.fName} "        M291 S2 R""UNFREEZE:"" P""No file in the fridge :-("""
echo >>{var.fName} "    M99"														; file missing: finish execution
echo >>{var.fName} "if exists(param.X)"												; in case of a parameter "X",
echo >>{var.fName} "    M99"														;	return after the filecheck

That's just a snippet from a macro which mimics some functionality of "resurrect.g" by creating a macro which in turn can be called to recover from an interrupted print. The sample is disfunctional, it just illustrates the usage of echo.

[sunToxx]

@fcwilt said in Strange Z error:

@suntoxx said in Strange Z error:

Do you by any chance know how to use the Echo command to create a macro?

I have no idea - I didn't even know that was possible.

Why do you need to do that?

Frederick

I wanted to handle my filament settings via DWC. My idea was to call for a macro on layer 2 via custom slicer start code, so i can set the other layer temperature for nozzle and bed there. To make this work though, every filament change would need to rewrite this macro. No idea if that is a good aproach though.

@infiniteloop said in Strange Z error:

@suntoxx said in Strange Z error:

Do you by any chance know how to use the Echo command to create a macro?

Maybe I can help out?

That's just a snippet from a macro which mimics some functionality of "resurrect.g" by creating a macro which in turn can be called to recover from an interrupted print. The sample is disfunctional, it just illustrates the usage of echo.

Thanks, I will have a look at that!

[fcwilt]

@suntoxx said in Strange Z error:

I wanted to handle my filament settings via DWC. My idea was to call for a macro on layer 2 via custom slicer start code, so i can set the other layer temperature for nozzle and bed there. To make this work though, every filament change would need to rewrite this macro.

I handle my filament settings via DWC but I have not find a need to create a macro.

I set my bed and extruder temps in the filament specific config.g file. I invoke that file in my print start code.

What is it you need to do different from that approach?

Frederick

[sunToxx]

@fcwilt how do you set first layer and other layer temperatures in the filament specific config.g? That's what i thought i would need a macro for.

[fcwilt]

@suntoxx said in Strange Z error:

@fcwilt how do you set first layer and other layer temperatures in the filament specific config.g? That's what i thought i would need a macro for.

Here is one of my filament specific config.g files:

M221 S100 D0             ; set extrusion multiplier
M568 P0 S190 R100 A2     ; set tool 0 extruder temps
M140 S60 R30             ; set bed temps

Near the beginning of my print start code I have these three essential commands plus several others needed for starting a print:

T0   ; select tool 0
M703 ; run the config.g for the currently selected filament
;... other commands
;... other commands
;... other commands
M116 ; wait for temps to reach set points
;... other commands
;... other commands
;... other commands

Not sure what you mean by the mention of first layer.

Frederick

[sunToxx]

@fcwilt does this mean that you always print first layer and all other layers at the same temperatures?

[fcwilt]

@suntoxx said in Strange Z error:

@fcwilt does this mean that you always print first layer and all other layers at the same temperatures?

Yes. I have found no reason to do otherwise.

What led you to use different temperatures?

Thanks.

Frederick

[sunToxx]

@fcwilt well, it seems to be a standard feature in slicers. At least Prusaslicer and Cura got it and in Prusaslicer most presets seem to make use of it. Different layer height, extrusion width, nozzle temperature and bed temperature in order to enhance first layer adhesion appears to be quite common.

Not sure, but I was guessing that for example with PLA, because 70 bed temp for first layer is sometimes usefull, going back down to 60 might be good in order to reduce the likelhood of warping, as it causes the bottom to be less soft.

I thought PLA would rarely warp, but found that especially with very fine layers and 0.25mm nozzle, PLA starts to be quite tricky on some prints. I didnt quite come to a final conclusion yet, but doesnt a different first layer temp have quite an impact in certain situations?

So my idea was to add a command to the filament specific config.g, that overwrites an "other layer temperature" macro, depending on the M701 material in use. That macro then should be possible to be called with custom gcode in the slicer. Maybe on layer change with an if statement, so it does not activate on first layer. Something like that.

@phaedrux in your z probe offset macro, can any problem appear if i return to normal motor currents by simply setting it back to 100%? Like on a power loss or anything? Or would that be a perfectly save approach?

[fcwilt]

@suntoxx said in Strange Z error:

it seems to be a standard feature in slicers. At least Prusaslicer and Cura got it and in Prusaslicer most presets seem to make use of it. Different layer height, extrusion width, nozzle temperature and bed temperature in order to enhance first layer adhesion appears to be quite common.

True, slicers have all sorts of settings designed to deal with first layer adhesion. And the number of possible combinations of those settings is daunting.

Not sure, but I was guessing that for example with PLA, because 70 bed temp for first layer is sometimes usefull, going back down to 60 might be good in order to reduce the likelhood of warping, as it causes the bottom to be less soft.

My beds are rather massive and any temp changes I might try to make are going to be rather slow to take effect.

I thought PLA would rarely warp, but found that especially with very fine layers and 0.25mm nozzle, PLA starts to be quite tricky on some prints. I didnt quite come to a final conclusion yet, but doesnt a different first layer temp have quite an impact in certain situations?

I honestly don't know. The biggest factor I found for first layer adhesion has been speed.

So my idea was to add a command to the filament specific config.g, that overwrites an "other layer temperature" macro, depending on the M701 material in use. That macro then should be possible to be called with custom gcode in the slicer. Maybe on layer change with an if statement, so it does not activate on first layer. Something like that.

If I was going to implement a temperature change feature it would involve using the slicer feature that allows invoking custom code on each layer change. It would be easy to have the filament specific config.g file set some global variables holding different temperatures and layer counts. Then the layer change custom code would use those values to determine what temperature to be using for the current layer.

I am going to try that just to see what sort of effect changing bed temp might have.

Frederick

[sunToxx]

@fcwilt said in Strange Z error:

I honestly don't know. The biggest factor I found for first layer adhesion has been speed.

In which way? I experienced, that a keychain i did in various sizes and with different layer thickness and nozzles, started to warp very easily, when using the .25 nozzle and a certain size and thickness. The smallest version printed fine, the 20% bigger version, started to warp, despite strong layer adhesion. Not sure if it is the longer print time that caused it, or maybe the number of layers and the way they cool down being that thin. Maybe they are just super prone to moving air, when the layers are that thin (was .12mm layers).

What speed to you use? By now I always left it at the default 20mms. I only once had layer adhesion problems that were not z offset related, and solved them by increasing bed and nozzle temp beyond the temperatures recommended by the manufacturer. (was Fillamentum Vertigo Space and used 235° 70°C, then even fine outlines would stick).

If I was going to implement a temperature change feature it would involve using the slicer feature that allows invoking custom code on each layer change. It would be easy to have the filament specific config.g file set some global variables holding different temperatures and layer counts. Then the layer change custom code would use those values to determine what temperature to be using for the current layer.

I am going to try that just to see what sort of effect changing bed temp might have.

Setting variables would be probably much cleaner. I was thinking of using the echo command to create for example an "Additional-Filamentsettings.g" makro and add a sort of "if layer>1 then execute Additional-Filamentsettings.g" in the layer change custom code.

So I would just have to copy and paste that echo section into each filament config.g and simply set the desired values there and every time I use DWC or M701 to change the type of filament, the echo command would overwrite the Additional-Filamentsettings.g with the current values.