Posts made by pkos

There's a lot of variables going here that will make answering your question in a simple way difficult like how will you run the wires? In a chain? In a sleeve? Ziptied? What lengths? Loads of variables that will impact the type of wire to pick.

For example, if you go for chains, stay away from silicone sleeved wires. They will bind up on you and break with time.

I tried loads and recently I ended up either with PTFE or FEP sleeved wires - my brand of choice is Heluflon (easy to get in the EU, not sure about other places).
I use AWG 24 for almost everything except heaters - there I calculate the needed amperage and match gauge for the use.

You could also go with PTFE wires from Aliexpress or Amazon - they should work too. I used loads of those before switching to Heluflon and never had any issues.

They are more stiff - which can be both good and bad - again depending on your specific use case.

@Herve_Smith I think the design is great. It also helps us (duet peeps) get more representation in the Voron world and especially cool designs for our hardware.

One would hope we are all mature enough to appreciate the effort people go through to get something out there free of charge (no less).

There is interest

Good luck!

@wbrokow1 it might be easier for you to ask such questions in the Voron discord in the duet_rrf channel (where you already got some help in the past). People there are great and very helpful.

Also, check Voron's github for sample configs (including the UserMods) repo. You'll find a lot is already provided there and you just have to adapt the configs to your particular printer and needs.

@Lamooth Is it just on the Mac?
I remember having this problem for a long time - including duet resets midprint because of this. But this was in and before 3.2. Now it still happens every now and then, but never resets the Duet. At worst, I can't load the GUI at all, at best - I get a gray overlay over the GUI which prevents me from clicking stuff on the GUI, but at least I can see what's going on (this is much more often and worse when using BambuStudio-SoftFever edition).

The errors, freezes and resets only happened on Mac (regardless of browser) - never on Windows.

The one thing that could help was disabling Eset's Firewall I had installed.

@nikscha It works I've been using it for ages now, although I don't have a very elaborate layout. I mostly have HA watch hotend temp and once it's been at 45C for 2 minutes after a print - it switches the printer off.

My code is as follows:

  - platform: rest
    name: Voron_24 Status
    resource: http://<ip_here>/rr_status?type=3
    value_template: "{{ value_json.status }}"
    json_attributes:
      - temps
      - fractionPrinted
    force_update: true

  - platform: template
    sensors:
      voron_24_head_temp_current:
        value_template: "{{ states.sensor.voron_24_status.attributes.temps.current[1] }}"
        friendly_name: Hotend Temp
      voron_24_bed_temp_current:
        value_template: "{{ states.sensor.voron_24_status.attributes.temps.current[0] }}"
        friendly_name: Hotbed Temp
      voron_24_print_percentage:
        value_template: "{{ states.sensor.voron_24_status.attributes.fractionPrinted }}%"
        friendly_name: Print progress 

And this is how I put display it in Lovelace.

The important bits here (if you know this, forgive me, if not - maybe it will help) - is to keep the naming consistent. HA will convert the name from the first sensor into an entity_id.
So in my case, here it reads Voron_24 Status. HA will take it, convert it internally to voron_24_status and this is what you use below in the actual sensors.

And since I am waaaaaay too lazy ( ) I am going to wait for MQTT to come along before solving issues like not zeroing out of entries when the printer is off

See if that will work and if you get stuck, ping me and I'll be happy to help.

While waiting, you can easily use this:
https://github.com/iz3man/duet3d/blob/main/duet3d.yaml

Just add the lines to your configuration.yaml, modify for your printer and restart HA.

Shameless bump to @dc42

Is there any chance anything could be done here? Or should I abandon all hope?

I wonder if this is something we could get @dc42 to comment on? Is this something that can be adjusted?

Here's my attempt today (Took me a while longer to get it done).
I have not had a successful tune since the change of the heater. I tried both with the door open and hat off and on - it's always pretty much the same in terms of temp levels and differences.

Command was:

M303 T0 S265

Copying the result of the tune and the chart. You can clearly see the moment the fan kicked in.

Warning: Turning on the print cooling fan did not increase hot end cooling. Check that the correct fan has been configured.
Auto tuning heater 1 completed after 3 idle and 10 tuning cycles in 1026 seconds. This heater needs the following M307 command:
 M307 H1 R1.722 K0.381:0.000 D12.14 E1.35 S1.00 B0 V24.0
Edit the M307 H1 command in config.g to match this. Omit the V parameter if the heater is not powered from VIN.

I literally had the same problem yesterday, which was weird to me.
I'll take screenshots later today, but to explain what I did yesterday...

Duet 3 mini 5+ on 3.4.0 release build.
Heater was a 40W E3D packed into a Mosquito (blasphemy, I know ) inside a Voron V0.1 miniAfterburner toohead.

The 40W heater would work and PID tune properly, but was struggling.
I exchanged it to a 50W heater and from then on, I can't pid tune with the same error message above.

On the chart, the difference in heating up time once the part cooling fan kicked in was clearly visible, although the temperature drop itself was more or less the same as before the fan kicked in.

@exerqtor

https://forum.duet3d.com/topic/26170/neopixel-support-on-1lc?_=1648139969023 might give hope

@alex-cr That would be a big shame, since the system works perfectly on the 2.4 as I am sure you see yourself on yours.

I won't give up this easily though, as to me - this is still incorrect behavior based on what is in the documentation for the M143 gcode.

Considering I am setting 115C to trigger an A2 (so temporary shut off) and not A1 (permanent shut off) - This to me is incorrect behavior or the documentation does not specify that A# is ignored during PID and always defaults to A1 (and not even the default A0).

Is there any chance I could trouble you @dc42 to help us here (especially on the A1 vs A2 behavior)?

An update.

Dropping to RRF 3.2 allowed me to pid tune, but only because it ignored the 115C limit and would actually go as high as 125C to reach the 85C on the bed. All done with the same settings.

After that, I went back to 3.4 and could no longer do a pid tune - once 115C is hit, any heating stops even if both heaters go below the target temperature.

I tried commenting out line 9 in my config (just in case, so the M143 H0 S115) - same behavior. Heating is disabled once 115C is reached.

Hi,

I've recently built a new Voron (Trident this time) and wanted to run a setup I already have working on my 2.4 - two thermistors - one on the silicone AC mat from Keenovo (built in), another one placed inside of the 8mm alu bed (small hole drilled in the side and thermistor placed inside to measure edge temps).

This is my config:

; Hotbed (Dual Thermistor)
M308 S0 P"temp1" Y"thermistor" T100000 B3950 A"Bed Heater"       	; Thermistor on the mat
M308 S2 P"temp0" Y"thermistor" T100000 B3950 A"Bed Plate"			; Thermistor inside the bed
M950 H0 C"out0" T2                                  	; Heater
M307 H0 B0 R0.166 C1554.8 D66.08 S0.60 V24.0		; Heater 0 model for 3.x
M140 H0                                            	; Map heated bed to heater 0
M143 H0 P1 T0 A2 S115 C0							; Regulate (A2) bed heater (H0) to have pad sensor (T0) below 115°C. Use Heater monitor 1 for it
M143 H0 P2 T0 A1 S120 C0                            ; Shut off (A1) bed heater (H0) if pad sensor (T0) exceeds 120°C. Use Heater monitor 2 for it
M143 H0 S115                                       	; Set temperature limit for heater 0 to 115C
M570 H0 T3											; Start screaming if temp falls 3C below set temp. 

I'm running this on RRF 3.4 on a Duet 3 mini 5+ (as opposed to 2.4 which has a 6HC).

The command I was using to try to PID tune the bed was:

M303 H0 S85 P0.6

The behavior I am seeing is that once the mat thermistor reaches it's top value (here 115C)- it seems as if the heater is permanently turned off and the tuning algorithm never reengages it - even if the bed temp is waaaay below my set 85C. I made a test, where all I changed was the M143 line for the thermistor in the mat and dropped it down from 115C to 100C - same behavior. Once the mat reaches 100C, any future heating is stopped and the bed cools down (last bit of this can be seen in the screenshot below - ignore the hotend temps and the slight bump - this was around 60C after I restarted the board and did my bed to nozzle distance measurements).

I tried dropping down to 3.3 and here it also behaved the same. Once the temp was reached, even though the heater was marked as in tuning - heating was disengaged and would never reengage.

I know I had this working once, since my 2.4 with 6HC was PID tuned (but that was a long time ago, possibly before 3.3 - it's not operational at this time so I can't confirm).

Has anyone else seen this behavior?

@dc42 That can't be it. In the case of two of my printers - ribbons going to the screens are nowhere near any steppers or any other wiring for that matter.

If I remember correctly, the way communication with neopixels works is that you always have to send the complete string for the whole strip/chain/etc.

Each of the neopixels grabs only the amount of data it needs for itself, then sends on the remainder of the signal onwards.

So there's no way to just send data to a single neopixel somewhere down the line.

One way to do it is to use variables and store what the last selection for that neopixel was.

In my case (also on a Voron with the SB beta), I just created a set of macros based off klipper suggestion config and trigger them when needed. I only want nozzle leds to be on during printing, they should remain off otherwise, so the macros are simple.

For example, QGL is:

M150 S1 R128 U25 B100 W0 P255 F1
M150 R0 U0 B0 W0

And so on.

This could be modified so that only the toolhead led gets changed, without touching the other two (just remove the F1 and second line and you're done).

@izeman I know. I am saying I had exactly the same thing and messed up a couple PEI sheets because of it The change from 2 to 4 fixed it for me.

@izeman Yes, I asked for your specific line configuring the screen in config.g

Reading from the output - change encoder pulses per click from 2 to 4. This should help you, although it will take more rotations of the wheel to make it work properly - not sure if this is something for @dc42 to take a look at - but I had the exact same issue as you did on two different screens and two different duet 3 mini 5+'s (one wifi, one ethernet).

@izeman In order for the screen to work, you have to first configure it with M918 gcode.
I'd like to see how you have the parameters set for it

@izeman Could you paste how you configure the screen in config.g?