Hi!

I am currently looking for a solution for a custom water cooler for one of the tools.

For now, I am running a continuous macro in the daemon.g, which controls the temperature based on some GCode meta commands. It works as desired, however I can't actively change the temperature ranges in a nicely manner. I would love to implement something looking like a heater, ie. fields where the input temperature is entered, and a target temperature is shown, but instead of the heater control algorithm, my custom code runs.

Best regards,
AW

Thank you for your replies @jay_s_uk and @dc42. Both suggestions seem to be valid solutions. I will firstly look more into the daemon.g file, as it is more customizable and fitting for my purpose.

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.

Today I tested with a 5m long HDMI cable, and every issue went away, thanks.

Picture resembling used cable:

@droftarts I used the red/white, blue/white, brown/white, and green/white. I didn't ground the shield.

Thanks for the replies, I have ordered a new SD card, it has 200/90 MB/s speeds:

Will give an update after I get the card.

@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.

@OwenD

Yes, my goal was to have a function checking a sensor state with 1 second intervals, and to disable fans with a 30 second delay. However, I found the G4 blocking, ie. in one of my prints a typical layer takes about 5 seconds to finish, but some of them are ~35 seconds. This behaviour disappears completely when I do not use the daemon.g, and I determined it to be for sure linked to the G4 S30 command.

This is why I am left confused as to what is the exact behaviour of G4 in daemon.g.