Topics created by hlwerschner

@hlwerschner
Hold down your CTRL key and scroll your mouse wheel to
change the zoom in your browser before you open the macro for editing.

@hlwerschner said in Using macro calls in config.g:

So my question: Is there some limitation in rel 3.50 to disallow macro calls in early execution of config.g ? Please note, that I use several macro calls later (around lines 100ff including a large comment-lines block) and these have been OK and are OK in 3.50 also.

Its a bit weird but I am worried about macro aborting (!?) without any messages on the console. Just end-of-execution and no messages on the console. Such runs were reproducible!

Calling macros I don't know, but I found an odd behavior with local variables in config.g in 3.4.6 (as I described here: https://forum.duet3d.com/topic/34505/possible-bug-with-local-variables-use-in-config-g ), so maybe it's a similar situation and at this point I'd say: initialize variables only at the end of config.g...
EDIT: no, that was due to an error by me: I forgot to use var.var_name
So at this point I'd say: no problem as long as they are declared correctly. 😅

BTW: I'm with you with the uglyness but safe(tiness) of if !exists and I'm a bit more extreme

var val = <var value> ; val if !exists(global.value) global value = {var.val} else set global.value = {var.val}

First I have the values declaration block in local variables only, then the global creation/changing for global values, so that I don't have to put the same value twice for every global variable (and scroll to find it when I want to modify it, and remember to modify it twice and not making typos...); the if !exists block is just crtl+c - ctrl+v and, once made (and made sure it's correct), it doesn't have to be touched ever again.

@hlwerschner said in Using macro calls in config.g:

switched later to the MB6HC which is great and promises to allow 3-Z-axes expansion more easibly and now I sit on that board and wait for some features that I would like to use 🙂

Thatis relatively easy: there are macros here on this forum for 3-Z autolevel. 😃

@hlwerschner I'd try running the same macro in standalone mode (you will need to insert an sd card with a sys directory on it into the board) and see what happens with that. Other than that post your full (combined) config.g file so @dc42 and or @chrishamm can try running it.

@hlwerschner I confirm this is a problem. The Z axis machine position reported in the object model is out of date during a move that includes Z. It's also not updated to the final position until a short time after the move is completed. I will investigate it.

Edit: created https://github.com/Duet3D/RepRapFirmware/issues/921 and https://github.com/Duet3D/RepRapFirmware/issues/922.

dc42 created this issue in Duet3D/RepRapFirmware closed Machine Z axis position report incorrect #921 dc42 created this issue in Duet3D/RepRapFirmware closed Axis machine position is not reported live when using an expansion board #922

@hlwerschner said in Homed state and physical endstops triggering:

But I guess that a direct G30 after board reset/power-on will not be allowed as the Z axis is not yet homed at this point in time?

G30 doesn't care if the z axis is homed yet or not. It will be doing it's own homing anyway.

If you want to force an axis to being homed you can can use G92 Z## and manually set the position.

@hlwerschner 1. If you only have a single tool, you can keep it selected so you don't need to worry about it (add T0 to your config.g). Since Duets can be used to control a variety of different tools (or multiple nozzles), it makes no sense to activate all the tool heaters at once.
2. M104 is a fallback M-code to control nozzle temperatures. It selects the tool and sets the temperature, M568 or G10 (as used by DWC) do not do this for the reason above.
3. Yes, it does. It's the heater state and if it is set to 0, it will remain off as long as it doesn't get colder than that.
4. AFAIR M1 can be used for that in v3.4 if there is no sleep.g to override the default behaviour.

I'm not sure about the max length, but replacing the cable with something else is possible. With good quality conductors and shielding the length should be pretty decent. How far are you wanting to go?

You may find some useful information here: https://github.com/Duet3D/DuetSoftwareFramework/wiki/SBC-Setup-Guide

Thanks @chrishamm. I now have a RPI400 working as the SBC with a Duet3 6HC, using an unchanged DuetPi image. It will be controlling a RatRig KillerBee CNC. I'm using a SunFounder 10.1" touchscreen, and the RPI400 is powered through the touchscreen, using only the screen's 12V PSU. I have version 1.01a of the Duet3 6HC, so its 5V is not used to supply the RPI400. So far I have tested a limit switch, and a stepper motor, using DWC, and all looks good.

@dc42 That will be a great addition! Thanks for all your work.

The location of an axis is found with this
move.axes[n].machinePosition

Returns null if the position is unknown (machine not homed).

@owend Oh yeah, I have overread this! Thank you...I had expected this to be a "function" like length() or var.length ...
mea culpa for to scanning the docs more intensively.

@chrishamm yes, I did know about the H0, it was just while testing and trying to isolate the cause. I even tested with M564 Sx as I sometimes have a negative Z coord as starting position and wanted to react properly - as G1 then would not do anything at all. Adding comments to the docs is really welcome...what is with sensors (endstops) when G0/G1 are involved?
Nevertheless I a ma a great fan of the DUET + RepRap (currently at RRF 3.4) and appreciate the fantastic community!

Another vote for 'new'
You might get lucky but in general I would call the heater toast (ha) after removal.

@hlwerschner Having spent almost 2 years and having done an awful lot of work in trying to develop a mixing hot end, I have learned much about heat breaks - especially all metal ones. At one time, I was using 6 off genuine Slice Engineering Mosquito heat breaks of which the Dragon is a clone.

These are undoubtedly the most efficient style of heat break. BUT, if the filament is static and heated but not moving forward, then heat will creep up through the filament itself even though very little heat creeps up through the metal part of the heat break. It's especially a problem with PLA because of the low glass transition temperature. So even though the temperature of the heat break might only be 40 deg C, the temperature of the (static) filament inside the heat break can exceed 60-70 deg C which is greater than the glass transition temperature for PLA.

So the moral of the story is to never, ever, heat the hot end for an extended period of time without the filament moving forward. If you do, heat will creep up into the heat break zone through the filament itself, where is will soften. As son as you try to extrude, this softened filament will simply swell and block the tube.

BTW, with a mixing hot end one or more filaments will always be static so for this reason, all metal heat breaks can not be used - they have to be PTFE lined.

@hlwerschner the fan mosfets have a much lower peak current rating that the heater mosfets, so they are more easily damaged e.g. if the output is shorted or the fan is connected the wrong way round. Whereas 2A is nothing for the heater mosfets.

@hlwerschner said in Duet WiFi fried while installing Bltouch:

@droftarts Hi, could I feed an external 5V power via the ext 5V connector to the board and circumvent the failed components?

You could try that, but I suggest you limit the current available from that PSU until you have checked for overheating components.

You may find it helpful to reduce motor currents when you are experimenting.

Hi,

You've been busy.

Are you using a Hall effect device for your end stop sensor? Interesting.

As to my sensors keep in mind they they are IR beam break devices. They are attached to the frame. On the moving part (be it X,Y,Z) there is a printed part that moves into place and breaks the beam.

Since these is nothing about the sensor that prohibits further movement the moving part can continue past the point where the sensor is first activated, assuming nothing else gets in the way.

Since the point of these sensors is to determine that the moving part has reached a certain position there is no real requirement that the sensor activate at the extreme end of travel or at the min or max axis position.

My sensors activate some 10 mm away from the min end of each axis. It is a simple matter to determine what the actual position is. So rather than adjust sensor position to yield a specific axis position I set the axis position using G92 to the actual position.

The result is the same using either approach, the firmware now knows where the moving part is.

As to accuracy I have taken no measurements. It is good enough to allow pausing and resuming a print. If that is not of concern it doesn't really matter if the X or Y position is off a mm or two at the start of a print.

As to the Z position I use a BLTouch probe to set the Z=0 datum independent of the Z end stop sensor. The Z end stop sensor gets the bed where it needs to be for homing purposes. The probe determines where it actually is for printing purposes.

Frederick