@Crash69 said in Indirect (bearing) laser filament monitor concept:
5x10x4 (mr105)
Hi everyone, I just published my interpretation for a Duet3D laser filament monitor enclosure. Use a rubber band and have moving parts.
https://www.thingiverse.com/thing:4147811
feature request
would it be possible to implement the management of multiple states and multiple temperatures for the M568 command?
the idea would be to have
and state An for exemple:
I think they are the most used with a multitool setup.
It would be nice to have similar management for the bed as well.
@zerspaner_gerd
No you are wrong, the method has changed. To get the same result as S-1 now you have to assign the trigger on the pin "nil"
@pfn
I have three macros:
you could enter in tpostmaster:
M98 P "ercf / lib / load-tool.g" T{state.currentTool}
as far as temperatures are concerned, I manage them with 6 global variables:
global ToolF; first layer temperature tool
global ToolC; temperature toolchange
global ToolT; first layer temperature tool
global ToolS; standby temperature
global bedH; first layer bed temperature
global bedB; temperature bed
these variables are set by "/ filaments / <filament-name> /config.g", where I can possibly also insert pressureadvance and more, the template I use is
0:/filaments/ABS/config.g
;-----------------------------------
var firstlayertemp=240
var layertemp=235
var standbytemp=180
var toolchangetemp=234
var firstlayerbed=103
var layerbed=95
;-----------------------------------
set global.toolF=var.firstlayertemp
set global.toolT=var.layertemp
set global.toolS=var.standbytemp
set global.toolC=var.toolchangetemp
if global.isfirstBedHeat && global.setBed
set global.bedH=var.firstlayerbed
set global.bedB=var.layerbed
set global.isfirstBedHeat=false
i don't need load.g and unload.g of the filament
the temperature of the tool and of the bed is set by a macro that I inserted in the start gicode of the slicer and at the tool change. In superslicer I put this:
;Start G-code
M83
set global.slicer=3
set global.layercount=0
{if wipe_tower}set global.slicerwipe=true{endif}{if !wipe_tower}set global.slicerwipe=false{endif};wipetower
T[current_extruder]
M703
M98 P"/sys/DEFAULTS/heatup.g"
M116
;end start
;BEFORE_LAYER_CHANGE
G92 E0.0
{if layer_num>0}set global.layercount=[layer_num]{endif}
;[layer_z]
;AFTER_LAYER_CHANGE
;SET LAYER COUNT
{if layer_num<2}{if layer_num>0}M98 P"/sys/DEFAULTS/heatup.g"{endif}{endif}
;TOOL CHANGE G-CODE
T[next_extruder]
for CURA I have to initialize the global.layercount to -1 in the start and then pass in post processing script:
set global.layercount = {global.layercount + 1}
of course you have to set ALL the temperatures of ALL the materials to 0 in superslicer to let the printer manage everything!
in this way and setting the tools in config.g with:
M584 X0 Y1 Z2:9 E3:3:3:3:3 U4 V8 P5
M563 P0 S"E1 " D0 H1 F2 ; Define tool 0 P=tool number, D=driver number, H=heather, F= fan
M563 P1 S"E2 " D1 H1 F2 ; Define tool 1
M563 P2 S"E3 " D2 H1 F2 ; Define tool 2
M563 P3 S"E4 " D3 H1 F2 ; Define tool 3
M563 P4 S"E5 " D4 H1 F2 ; Define tool 4
;M563 P99 S"SUPPORT" D5 H2 F2 ; Define tool 99
I can have the materials assigned to each tool and with a flag variable that disables the execution of the tool change macros outside of printing I can change the material from the web interface to any tool (obviously not for the one currently loaded, for that I disable the flag to physically perform the unloading and loading).
in start.g the tool actually loaded is always selected.
the slicer only deals with the management of the fans as they are strictly linked to the gcode and the material, I don't think it can be left to the firmware to manage it ...
my only current problem is that when i change filament with ATX off the printer tries to heat the tool and i have a temp fault, i could not understand where i went wrong as the heater should stay off, as soon as i have time i investigate, for now it is a manageable problem.
@arno91
Hi , I use similar solution to load filament with MMU feeder and extruder in sync:
M574 V2 S1 P"duex.e6stop" ;
M400
M18 V E0:1:2:3:4 ; disable the axes/extruder to reassign
M584 V3:8 ; reassign them
M906 V800 ; set the motor currents
M350 V16 I1 ; set the microstepping
G92 V0
echo ">reassigned motor"
M98 P"/sys/SERVO/ON.g" ;engage MMU
G1 H4 V1000 F500 ;load to extruder endstop
M98 P"/sys/SERVO/OFF.g" ;disengage MMU
M400
M18 V0:1 ; disable the axes/extruder to reassign
M584 V8 ;
M906 V1400 E1000 ; set the motor currents
M913 E80
M350 V16 E16 I1
G92 V0
I take this opportunity to ask a question @dc42
in my config.g I have:
M584 X0 Y1 Z2:9 E3:3:3:3:3 U4 V8 P5
[...]
M563 P0 S"E1 " D0 H1 F2 ; Define tool 0 P=tool number, D=driver number, H=heather, F= fan
M563 P1 S"E2 " D1 H1 F2 ; Define tool 1
M563 P2 S"E3 " D2 H1 F2 ; Define tool 2
M563 P3 S"E4 " D3 H1 F2 ; Define tool 3
M563 P4 S"E5 " D4 H1 F2 ; Define tool 4
[...]
and the macro executed in the tool change has the code I posted above, I do not reassign the stepper drives to the E axis (no "M584 Ex" other then the one in config.g). Given that the procedure works right now, there is something wrong that could give me problems perhaps following updates of the firmware?
@dc42
Ok, I can try, even if I've never put my hand to the Reprap firmware I think I can do it. But I try to make another request: is it possible to insert the retraction in the special movements managed by M201.1? also would it be possible to include in the special movements also the return to position between the two probes if, for example, 2 passes are used with the Bltouch?
HI,
I'm running a CoreXZ configuration, a custom AM8 to Swichwire mod.
Due to small collisions that the nozzle had with the piece printing during the z-hop I lowered the acceleration of the Z axis. this thing had repercussions on the acceleration of the X axis, in practice the lowest acceleration of the two is used for both axes. Is this behavior fixable?
@jos_mosa if you want a movement to be performed at the end of the previous one you have to use M400
G1 X100 F6000
M400
G1 Y100 F6000
Hi,
as asked in another post I have some issues with coreXZ conversion, one of this is that manual bed leveling not work, I have this messages:
M671 parameters do not apply to CoreXZ kinematics
and
Error: This kinematics does not support auto-calibration
my code is
M671 X23.7:232.7:232.7:23.7 Y219:219:10:10 P0.35
G30 P0 X23.7 Y219 Z-99999 ; probe near an adjusting screw
G30 P1 X232.7 Y219 Z-99999 ; probe near an adjusting screw
G30 P2 X232,7 Y10 Z-99999 ; probe near an adjusting screw
G30 P3 X23.7 Y10 Z-99999 S4 ; probe near an adjusting screw
M400
M402
G1 X{var.xCenter-sensors.probes[0].offsets[0]} Y{var.yCenter-sensors.probes[0].offsets[1]} F6000
G30
I have 4 screws under bed, what is wrong?
@gianluca I think You don't need M501 if you not have any setting stored with M500. Have you tried M98 P"SelectT0.g" and put "T0" into it? Obviouslyit it is "Una pezza a colore".......
@cosmowave I don't see M501 in config.g, @Gianluca can try to add T-1 prior of T0 and see what happen? or try to put T0 in an external macro and call it at the end of config.g. Anyways i believe this is SBC firmware glitch
if you run
M98 P"config.g"
what result do you have?
Hi,
i just finished converting my AM8BLV to COREXZ (SWITCHWIRE adapt) and it seems to work fine.
However, I have some doubts about some conversions to do with the new kinematics:
with the Cartesian in the homing I raised the Z axis by 5mm still not homed to ensure that the noozle did not hit the plane
G1 H2 Z5
now this command move the z motor individually and then the carriage moves diagonally right-down. i solved by inserting
G1 H2 X5 Z-5
is it the right solution or is it possible to use something cleaner?
I encountered another problem with the bi MBL procedure, with the Cartesian probe the 4 corners of bed with the bltouch and firmware return to me the number of turns to be carried out on the screws to level the surface, now with the new kinematics I get the message that
M671 parameters do not apply to CoreXZ kinematics
and
Error: This kinematics does not support auto-calibration
in bed.g I have
M401
M671 X23.7:232.7:232.7:23.7 Y219:219:10:10 P0.35
G30 P0 X23.7 Y219 Z-99999 ; probe near an adjusting screw
G30 P1 X232.7 Y219 Z-99999 ; probe near an adjusting screw
G30 P2 X232,7 Y10 Z-99999 ; probe near an adjusting screw
G30 P3 X23.7 Y10 Z-99999 S4 ; probe near an adjusting screw
M400
M402
G1 X{var.xCenter-sensors.probes[0].offsets[0]} Y{var.yCenter-sensors.probes[0].offsets[1]} F6000
G30
is not possible to use manual bed leveling?
in config.g I have
M584 X2 Y1 Z0 E3:3:3:3:3:3 U4 V8 W3 P5 ; corexz
M669 K2 X1:0:1:0:0:0 Y0:1:0:0:0:0 Z1:0:-1:0:0:0
where U V and W are ERCF axes, is correct or I can simply put
M669 K2 X1:0:1 Y0:1:0 Z1:0:-1
instead ?
Thanks in advance
I think the new value are the used one. You cold have different tool with different settings and hardware so the unretraction of tool 1 is correct to follow it's settings, switch from T1 to T0 do a 3mm retract so return to T1 it do a 3mm unretract, switch from T1 to T0 it do a 3mm retract and 5mm unretract, assuming tpre0.g has command M207 S5.0
@dc42 I still can't downgrade but I found out what could have caused the problem: the M563 command in config.g (but also from the console) resets the retraction of the tool, so M207 must follow M563.