Posts made by awitc

@dc42

I didn't have the macro for changing nozzle size at hand, so I copied my other one and replaced this line, so that it only demonstrates the saving. Should look like this, but it is for volume measurement parameters:

echo "Previous val: ", global.coef
echo "Reference volume: ", global.reference_volume
echo "Actual volume: ", global.actual_volume

echo >"/sys/coef.g" "set global.coef = "^{global.coef * global.reference_volume/global.actual_volume}^""

G4 P1
M98 P"coef.g"
echo "Updated val: ", global.coef

Here the result is calculated and stored in the coef.g file and then loaded so the printer has the updated value, too.

@infiniteloop @dc42

This sounds like it! I will remove this macro from the daemon and figure out a different way of doing this.

Is there a good way of saving parameters while the Duet3 is running? This is how I have done it so far:

; macro for updating the value

echo >"/sys/coef.g" "set global.coef = {global.coef}"

G4 P1
M98 P"coef.g"
echo "Updated val: ", global.coef

This is how the logic looks like (not direct code, because I don't have access to the printer right now), I have a variable in config.g, then the file coef.g contains an overwrite,
which is using a new value. In config, the macro is run at every start-up to load the new value from SD card. The global.coef can be overwritten during printer operation by other macros etc.

Looking at this code, I am feeling quite silly that I completely missed having a G4 P1 executing at EVERY loop iteration. I have focused on the code I added (the feeder checks) and that is when I noticed delays. The SD card saving macro I added couple of weeks ago, but didn't test it thoroughly (my oversight). Thanks a lot!

TLDR: avoid M98 in daemon.g, especially when it introduces another G4 delay.

edit:

@infiniteloop said in Problem with daemon.g timing:

As a self-assigned expert for infinite loops

took me a while

@fcwilt The idea of the while true loop was taken from this forum itself I think, to have it check faster than every 10 seconds. According to @dc42:

@dc42 said in daemon.g usage cases:

@OwenD said in daemon.g usage cases:

Does G4 pass control back to the main process when used in a loop?

Yes.

From this I understand that I effectively get a daemon.g running every G4 Px milliseconds at least (not taking into account the time it takes for the daemon to execute).

The choice between M226 and M25 was made because of this description:

Initiates a pause in the same way as if the pause button is pressed, except that execution of all prior GCode commands in the same input stream is completed first.

On the other hand M25:
M25 attempts to execute as quickly as possible

Even though the GCode dictionary mentions M25 to be the command to stop a print from DWC or some other source, the M226 in my case is like an extension of Gcode. I had to come up with a conditional check during printing.

The flow is as follows:

Print started -> Start Gcode toggles -> Custom macro starts extruder (controlled by a different board than the Duet3), Gcode paused by M226 in start gcode -> print paused till daemon.g checks for appropriate pressure (M24) -> continuous checks for any pressure jumps.

I imagined this as an extension of the Gcode, running along, not a definite break in the flow - like the M25.

The cases where I use my M226/M24 weren't causing problems yet, my print pauses at start, communicates with external controller for the extruder, resolves when pressure builds up fine. During the creation of this topic, these if statements were not checked, the delays have to stem from something else.

@fcwilt The M226 is maybe not the best, but it is needed for when I am stopping the print due to problems with a custom extruder (temps, pressure errors) or pausing it from gcode to wait for initial pressure to raise. In this post I was focused on the while true and G4 Px duo, where I want an infinite loop that checks several things ever x milliseconds. That is also why the loop doesn't ever exit. Also I remember to have read somewhere that without it the daemon.g executes slower, like every several seconds or so.

Hi,

My daemon.g looks like this:

var pump_started = false

var fans_started = false
var fans_time_elapsed = 0 ; [s]
var fans_time_disable = 30

var feeder_time_elapsed = 0 ; [s]
var feeder_time_disable = 8

var dt = 500 ; loop delay time [ms]



while true

	; monitor current pressure
	if {global.nozzle_pressure > global.nozzle_pressure_threshold}
		M98 P"/macros/disable_extruder.g" ; stop extruder
		M226 ; stop print
		M118 S"Error: Nozzle pressure is too high!"; error message
	
	if {global.pump_pressure > (global.target_pressure + global.pressure_difference_threshold)}
		; if state.status == "processing"
		M98 P"/macros/disable_extruder.g" ; stop extruder
		M226 ; stop print
		M118 S"Error: Pump pressure not within correct limits!"; error message
		
	elif {abs(global.target_pressure - global.pump_pressure) < global.pressure_difference_threshold}	; if pressure is at the expected levels, resume print
		if state.status == "paused"
			M24 ; resume print job
	
	
	; monitor temperature
	if sensors.analog[9].lastReading  > global.pump_trigger_temp && var.pump_started == false
		set var.pump_started = true
		set var.fans_started = true
		set var.fans_timer_reset = true
		
		M42 P1 S1		; enable pump		
		M106 P3 S255	; enable fans
		
	if sensors.analog[9].lastReading  < global.pump_trigger_temp && var.pump_started == true
		set var.pump_started = false
		set var.fans_started = false
		
		M42 P1 S0 		; disable pump immediately
		
	if var.fans_started == true
		set var.fans_time_elapsed = var.fans_time_elapsed + {var.dt} / 1000 ; [s]

		if var.fans_time_elapsed >= var.fans_time_disable
			set var.fans_time_elapsed = 0
			M106 P3 S0 		; disable fans
			set var.fans_started = false
	
	; monitor pellet feeder
	if global.feeder_started == true
		set var.feeder_time_elapsed = var.feeder_time_elapsed + {var.dt} / 1000 ; [s]

	  	if var.feeder_time_elapsed >= var.feeder_time_disable
			set var.feeder_time_elapsed = 0
			set global.feeder_started = false
			M42 P5 S0		; disable feeder		
			M118 S"Pellet feeder disabled"
	
	
	G4 P{var.dt} ; loop delay, 500ms, P = [ms], S = [s]

	; if nozzle_size changed, save the new value and update volume
	M98 P"/macros/update_nozzle_size.g"
	set global.reference_volume = global.volume_coefficient * global.nozzle_size
	

At first it was working fine, but I have added more and more stuff to it. The last change was the addition of the feeder code. It should trigger every 8 seconds or so, but as of now it is more like 30 seconds. Is there anything very wrong in my code?

The macros I use in the code are also like 1-3 lines of code, containing M42 and echo commands.

@jay_s_uk Yeah, I intend to use this as an opportunity to upgrade the firmware. Thanks

Hi,

Due to some fan wiring touching the build plate in an unfortunate accident one of the transistors got fried. I have spare Duet3 6XD boards and run the SBC setup. Since all the data is on the Raspberry Pi, can I just rewire everything to a new board? Is there something I overlook?

Thanks,
AW

EDIT: took me way too long, no idea what was missing, just started working as it should, thanks

@jay_s_uk @chrishamm Yes, I have added the command, using 115200 as baudrate, but from what I see, I had the parameter S set to be default. I will try with the raw mode, that might have been the problem. Thanks!

@jay_s_uk for now I have a STM32F411RE, will switch up to STM32F491RE in the following days. So it has Arm Cortex-M4. The STM is used to run a custom PID controller, which manipulates the speed of the extruder stepper motor, based on pressure.

EDIT: not extruder motor, but a drive which provides material to be extruded. I want to have the pressure in the extruder at a certain level.

Hi,

I have an STM32F4 board running a custom pressure controller, with a melt pressure transducer connected to it. I can achieve basic functionalities with toggling IO pins on the Duet3, but my goal would be to establish a two-way communication with a custom protocol for future features. I am trying to setup an USART connection between IO0 and the STM32 pins, but seems like the Duet3 does not receive anything. I am sending this with the hopes of seeing something pop up in the DWC:

"M118 P3 S\"Hello from STM32!\"\n\r"

I lack the general understanding of how to wire things up - is the Raspberry Pi SBC setup 'overriding' the standalone functions of the Duet3 board? Maybe I should connect the STM32 to RPi, and then have a Python script that sends the commands to DWC?

I would greatly appreciate any info on how this should be done, ideally I would love to add many modules this way, so the communication method needs to be reliable.

TLDR: I need to send pressure readings to Duet3 from STM32, to have a macro which stops a print when the pressure is too low.

Thanks,
AW

@droftarts Great! Exactly what I was looking for, must have overlooked the note. Thanks!

Hi!

I have configured an extruder with two motors, with a given step ratio. I am wondering if it is possible to override that setting in specific moments, ie. during a retraction,
to obtain a different ratio than the one in the config.

For instance, a normal command (here the E value is used for both motors, according to config ratio):

G1 X151.683 Y193.377 E0.60904

At certain moments, I want to change the value, so that one of the motors does not move:

G1 X151.683 Y193.377 E0.60904:0

I am looking forward to any solution ideas!

Best regards,
AW

Hi!

I am trying to set up a sensor, which will indicate the level of pellet material in the extruder, in the case when no material is detected, it will trigger a trigger, and perform the action of loading pellets, by setting a valve ON for a certain amount of time. My question is, does pause gcode (G4 command) return the attention to the printed file, while executed in a trigger.g? Ideally, I would want something like this:

set_valve_on();

// freeze this thread for 30 seconds
G4 S30

set_valve_off()

Best regards,
AW

The addition of "^" helped to bring the voltages to 0.7V and 3.3V respectively. I thought the pullup on the input is enabled by default. Thanks a lot!

I found also that testing the trigger with a M117 message makes the message show up only the first time the trigger is evoked. At least in my case.

Hi!

I am trying to set up a capacitive sensor not as a probe, but as a switch, which triggers some macro, whenever its "pressed". I am working with a Duet3 6XD, sensor information and config lines can be found below. My idea was to connect it as I have my endstops:
brown -> 24V
blue -> io_in_iso_neg
black -> io_in_iso_pos

However, this connection causes the sensor to not respond. Therefore, I did this:
brown -> 24V
blue -> io_GND
black -> io_in

With this connection, the sensor operates correctly, lighting up an LED whenever something is close to it, but the Duet3 does not recognize any change to the GPIO state:

21.11.2023, 16:05:50 	M409 K"sensors.gpIn[1]"
{
    "key": "sensors.gpIn[1]",
    "flags": "",
    "result": {
        "value": 0
    }
}

When I measure the voltage of the black wire, it is 8V or 9V depending on the state of the sensor. I figure, that changes between 0 and 3,3V would be needed, but do not know what to change to make it work.

; proximity sensor for pellet loading system
M950 J2 C"io8.in"
M581 P2 T2

Hi!

I am experiencing a weird problem, where at startup, the readings from thermocouples randomly (ie. it is not specifically one of them) show the value of 2000°C. It can be most of them, it can be two, generally it changes each time. After some time, the readings go back to normal, but during 3D printer operation singular readings will also jump to 2000°C, creating random spikes in the plot. During all of this, the wiring of the Duet3 6XD, Duet3 3HC, and 4 Duet3 thermocouple boards does not change, it is enclosed in an electrical box. The reading faults do not occur specifically on the thermocouples connected to one of the driver boards either.

Best regards,
AW

@dc42 thanks for the quick answer! I assumed I have to match the M350 to the DIP switches.

Hi!

I am seeing the following error:

It does not happen everytime I start/restart my printer. The printer is working properly, according to the given steps. It seems as if the error is only present in the console.
I use external stepper motor drivers - EM882S, which definitely support 32 microsteps. Driver 4 is the extruder, and I have a different motor, hence the different microstep value.

Config:

M350 X32 Y32 Z32 E8 I0		; microstepping with/without interpolation

It is more of an esthetical issue than anything else, but I would love to solve it nevertheless.

Best regards,
AW

@dc42

I am using the latest version of the firmware, 3.4.6.

Here I have created a post regarding the pausing: link.

Edit:

I have gone through the information regarding daemon.g on the docs page once more. Is it possible that a G4 S30 is making the code to be 'a loop that takes a long time to complete'? I assumed that no matter the parameter of G4, it will return the control to the main process.

I will try to redo my daemon.g to contain a loop with shorter pauses, instead one G4 command.