Posts made by o_lampe

@r123
what @oliof said.
Also keep in mind, that a message sent by M117 pops up only once per session, while echo "message text" is sent everytime the macro runs

@joel
My way of assigning a fixed address to any WiFi device is, set DHCP (*) mode in the device and let the router find an unused address.
When WiFi is connected, open the routers setup page and tell it to use this address permanently for this device.

*) set DHCP:

Use M587 to add a WiFi host network to the remembered list of networks.
To set a static IP address, use the 'I' parameter in your M587 command. If you leave this out, the Duet IP address will be set by the router, using DHCP.
Use M552 S1 to turn on networking, and connect. You can specify the host network to connect to using the 'P' parameter, so long as the host network has already been stored using M587.

@jordan_miller41 said in Displaying Water Temp. Virtual Heater Help:

Running Duet 3 MB with Daughterboard. Sensors are plugged into Daughterboard slots "temp_0" and "temp_1".

I guess their names is P"1.temp_0" and P"1.temp_1" respectively. Some daughterboards have other numbering, like '20'.
When you want to see them in DWC, click tools + extras and select the temps you want to see.

@owend
Thanks Owen, the T0 P0 tip was indeed helpful. It also allowed me to switch 'heater2' from off to standby status, without going through the macros.

I tried to check the globals status in the object model, but couldn't find them. Aren't they listed somewhere?
Calling them all with 'echo global......' is not the best way IMHO.

@r123
I agree, but that is also possible in the endcode of the cnc-program. Better ask your local guy, who makes the program, if he can implement the speed reset there.

@charli55
Does the z-probe work in the center of the bed? Maybe you have to increase the 'dive height' of the z-probe?

@chrishamm
I simulated a dual extrusion file with the new toolchange macros and was surprised, not to see any 'echos' from the macros.
Does the simulation actually run through those at all?
If not, what if we had some G4 and other time consuming commands in there?
The simulation result would be way off then. Not to mention M116 heatup times during tool changes. I admit, they are difficult to simulate.

If I want to make an offer for a customer and precalculate 'machine time' , such simulation is my ruin....

OK, I found the nerve to test the new toolchange macros and now they produce some reasonable numbers, but also one error.
Always and only the first global variable in config.g throws an error of 'already exists'.

Here are the working T0-macros

;tfree0.g
if heat.heaters[0].current >= global.tool0_ooze_temp
	set global.standby_duration = state.upTime		; this tool will ooze, so let the count begin
	echo "Countdown for T0 has started"

;tpre0.g
if global.tool0_primed = false
	set global.tool0_primed = true

;tpost0.g
M116 P0
if global.tool0_primed = true && heat.heaters[1].current >= global.tool0_ooze_temp     ; watch out! heat.heater numbers are not the same as toolnumbers (bed heater is heater[0])
	var extra_retraction = global.tool0_ooze_factor * (state.upTime - global.standby_duration)		
	if var.extra_retraction > global.tool0_maxcomp
		;G1 E{global.tool0_maxcomp}F{tools[0].retraction.unretractSpeed}
		echo "Tool 0 got max compensation"
	else
		;G1 E{var.extra_retraction}F{tools[0].retraction.unretractSpeed}
		echo "Tool 0 got Ooze compensation of:"
		echo var.extra_retraction
	set global.standby_duration = 0

There's also an issue with setting T0 as active tool in config.g. I tried to put the globals before and after T0 but running M98 P"config.g" ended up in an neverending loop.
I have to boot up and send T0 from DWC to activate it.

@alangibson

Did you ever 'measure' the length yourself? Just trying to think about everything...

@yngndrw said in CNC-Specific Board:

We're talking about a CNC machine rather than a 3D printer so being able to remotely turn it on or reset an emergency stop condition is a no-no.

I agree about that safety issue, but there 'should' always be a safety keylock or emergency button on the machine to prevent remote control while someone is 'in the machine'.

Re: Why my machine failed
I replaced the M12 threaded rods with ballscrews and was too keen to find out new max-speeds and accelerations.

@shirnschall
Above all that, there's Bowden tube length and last extrusion speed. Probably that's what you meant with 'pressure'?
I guess, from a math-noob point of view (like me), it would be easier to transscript for others, when we keep the goal in focus: reduce print time, by reducing reheat time and skip the wipe-tower. (*)

*) I can't use SlicerPE's wipe tower, because the nozzles have different sizes.

@marcel-schiffer
Hi, maybe consider using linear scaling formula. See here for a different but similar usecase.

@phaedrux said in Shrinking on Y axis:

@alangibson said in Shrinking on Y axis:

My (ancient) firmware version is 1.17e (2017-02-10)

Ah ok, that explains it a bit.

But it doesn't explain why the off-scale prints kept unnoticed for so long?
@alangibson what did you set as 'rod-length' ? The actual rod length or did you add the diameter of the Mag-balls too?

@shirnschall
Good point!
Maybe the easiest way is to limit max-compensation. We can assume, the hotend fan is on, so we don't have to fear heatcreep over extended standby-time. What would then be the max ooze volume? Size of the meltchamber inside the nozzle?
Or just catch up all the ooze from a paused tool and weight it? Density of the common filaments is known....

addon for tpost#.g

if extra-retraction > global.tool#_maxcompensation
	G1 E(global.tool#_maxcompensation)F(tools[#].retraction.unretractSpeed)
	echo "Tool # got max compensation"
else
	G1 E(extra-retraction)F(tools[#].retraction.unretractSpeed)
	echo "Tool # got Ooze compensation of:"
	echo extra-retraction
set global.standby_duration = 0

Needs definition of tool#_maxcompensation, too.

Hi gents,
I've cobbled together a template for my dual extrusion printer. It has different nozzle sizes and the standby time varies depending on the amount of 'infill' and 'perimeter'. Especially the 0.8mm nozzle for infill oozes a lot (volcano hotend)
It's not tested yet, I ask you to make a sanity and syntax check, before I go into the deep
(don't hold back)

ooze_compensation.txt

; Ooze-compensation based on heater standby time evaluated by 'state.upTime'
; works for dual extrusion and assumes that the standby temps are close or equal to print temps

; config.g specifies global variables
global tool0_primed = false		; tool is 'off'
global tool1_primed = false

global tool0_ooze_temp = 180	; only if current temp is higher than ooze_temp, we will see oozing
global tool1_ooze_temp = 180	

global standby_duration = 0		; only works when there is exactly one tool in standby (mixing tools or >2 tools need different times)

global tool0_ooze_factor = nn.nn		; varies depending on nozzle diameter (maybe add variation later, based on {heat.heaters[#].active - tool#_ooze_temp})
global tool1_ooze_factor = mm.mm

; tfree#.g sets the starting time for standby duration (can we assume it was used before and is on print temp?)
if heat.heaters[#].current is >= global.tool#_ooze_temp
	set global.standby_duration = state.upTime		; this tool will ooze, so let the count begin

; tpre# checks for primed_status
if global.tool#_primed = false
	set global.tool#_primed = true
	; maybe add some priming extrusion here
	
; tpost#.g checks if it was selected before (primed?) then calculates the extra ooze-compensation 
M116 P#		; wait for temp rising to print temp
if global.tool#_primed = true
	; maybe some extra smart calculation based on M307 cooldown time can take place here?
	; simple calculation when standby_temp = print_temp (for shortest tool changes)
	var extra-retraction = (tool#_ooze_factor * (state.upTime - standby_duration))		
	G1 E(extra-retraction)F(tools[#].retraction.unretractSpeed)
	echo "Tool # got Ooze compensation of:"
	echo extra-retraction
	set global.standby_duration = 0	
	

//edit
I've already noted some syntax errors (set global misses everywhere) Will post a new one soon
//edit2
done

@duetlover
You should print something 'not square' to avoid having the seam on one edge of the cube. (I guess, that's where the 0.1mm difference comes from)
I think of an hexagonal shape.

@yngndrw
Some questions:
Q1: Why do you use 24V input for DuetCNC? Are there any 24V devices on the Duet left? (there are no fans, no heaters...)
The external drivers should better be fed by their own supply, with only common GND.
The 'star' point of GND should sit on the power supply of the Duet.
Q2: What about endstops?
Q3: What about closed loop steppers? Do they communicate with Duet FW? Or is it just like every stepper has it's own closed loop?
( I killed my CNC-frame, because one Y-stepper stalled, while the other pulled on_and_on).
A 'real' closed loop CNC FW would have stopped the second Y-stepper...)

@rext3d
Can you confirm the pinholes are also misaligned on the underside? Or is it a bent housing?
Nevertheless, I think it won't influence the functionality. Maybe it's a bit fiddly to insert the external driver board, but it will be a secure fit

@DocTrucker
I call such locking mechanism 'semaphores'. It could be as simple as a boolean variable like 'extruder(0).available'. If your trigger macro needs exclusive access to extruder(0) it would set the variable to false and the print queue would stop (unless it contains commands not related to the locked resources) until the macro is finished and 'available' is true again.
M116 is a good example for an existing 'blocker'. Maybe it can be used for other things than temperatures?
(eg. M116 E0.endstop)
I'm not familiar with all the object variables, I made up the variable name above. But that way, it could be implemented,

@tenaja said in Bug: Gcode within trigger is interleaved with later build gcode?:

if you press the button several times during a macro execution, it stores up the number of button presses, and runs them upon completion.

I asked @dc42 lately, if the triggers needed to be 'debounced' but he said, that the first trigger would lock the input until the macro is finished. Hard to believe, they count up while the macro is running? (another bug?)

@kuon
The problem with the nozzle is, that it collects an isolating crust of filament over time.
You would need separate pins around the nozzle to probe for X/Y. One pin would be a little longer than the others, but still shorter than the nozzle. For the Z-height you'd need a hole in the plate, were the nozzle can dive in. The longest pin than makes contact for Z=0.
Regarding the coding, it's all up to you to write a macro that does all the probing and overwrite the G10 tool positions. If you feel confident enough, call it bed.g. With the latest 3.3.b2 firmware conditionals and variables are all there.
Read about 'triggers' to figure out how the probe pins can control the macro. (M950 and M581)
The probing speed will be slow, because you don't want bent pins. Maybe a close ring around the nozzle is more stable? (and always perfectly aligned in X/Y direction)

//edit
Maybe the ring could be a precise version of the 'berd-air' part cooler?! (the classic part coolers would probably get in the way for your aligning tool)

@dad003
The problem with reworking is, you might need some new printed parts, but if this is your only printer, you're in trouble.
Same with complete redesign.
If you feel comfortable with designing and printing everything you need for your project before you take apart the printer, then go for it. I'd opt for CoreXY.

I spent the whole day to calibrate the dual extruder setup with tool changes and Slicer settings.
Tuning the Z- and X-axis was easy, but the Y/V axis puzzles me. I had a very good calibration-grid, then printed a dual color testcube which showed signs of overextrusion, but was 'spot on' otherwise. The next print should've been an appetizer to show off, but there was an offset in Y/V again?

I'm too tired now, will see how it behaves tomorow.

@owend
Good catch Owen!
I read lately, that some guy wrote a gcode syntax highlighter for the forum. I didn't knew what that meant, so forgot mostly about it. Would be interesting to try that one in this context.

//edit found him