Topics created by cosmowave

@mikeabuilder it's probably better to check if it is > 0 (or eventually not = "null")
then, a single reading should be enough

@jay_s_uk Ok. Thanks.
I refered to the drives defined with M569...

@cosmowave Thanks, I've updated the documentation here: https://docs.duet3d.com/en/User_manual/Connecting_hardware/IO_Neopixel_DotStar#neopixel-leds

Multiple LED strips are supported:

Duet 3: up to 5 in a system (mainboard + expansion boards) Duet 2 WiFi/Ethernet: up to 2 LED strips, limited by RAM

It's possible that @dc42 might be able to increase the number of LED strips supported in the next release, particularly if you're only using a small number of LEDs on each strip. But it will depend how much free RAM you have on the Duet, as space is rather limited on Duet 2.

Ian

@droftarts said in z-probe ADC voltage:

I'd be interested in seeing the amplifier circuit; it would be good to have load cell support in RRF too.

As info:
I was working on a amplifier for my FSR's in the last days. If you are interesed, here's my quick and dirty scheme of the circuit.
The amplifier is built with a double op amp OPA2340 and is able to adjust the offset and gain separately.

47fd92c8-1119-4e71-b9fb-d7e2c556c387-IMG_20241011_084216.jpg

It is not yet perfect, but it works good in my "test environment". I will add at least a low pass filter somewhere in the signal line to filter out possible stepper EMF's. But i have to thinking about where and how...

EDIT: the 100 ohm resistor and the LED is not needed, it shows only if the circuit is powered...

@chrishamm Yes, the values are back! Thank you very much!
What's the reason why tools[0].retraction.extraStart has a new naming?
In RRF3.4.1 it was named tools[0].retraction.extraRestart...

@dc42 Sorry for the missing details!
Yes, it's a Duet2 and i'd like to use exp.heater5 on the expansion connector.
I will design the "driver" according to your suggestions.

I was aware that i need to invert the output. But thanks anyway.

@MintyTrebor
I'm very sorry! It was my fault...
The graph was not showing the same value as the numeric panel!
Whats the difference between requestedValue and actualValue? Is the actualValue the "real" PWM inside the min and max settings?

EDIT: Now i need a RRF3.5.3 version...
It's funny... first, one layout was not working because the missing retraction parameters in OM (RRF5.3.2). Now, with 3.5.3 the plugin itself is not working anymore..🙃

@chrishamm
Perfect. Thank you!

@cosmowave I don't see why the mechanism for detecting if a move is a travel move or a printing move in M204 couldn't also be used for applying a different feedrate. Maybe raise it as a feature request on Github?

I see the usefulness of it to, as you say, make gcode material independent. You can do this with the RRF filament profile, but it is generally focussed on temperatures and filament changing. I think that much of the Gcode granularity is probably best left to the slicer, as there are a number of other settings, eg bridging speed and extrusion factors, fan speed etc that are handled by the slicer with more granularity than the firmware or DWC could ever hope to do. It's just to entrenched in the generated Gcode. Which makes it very difficult to make Gcode fully material independent.

Ian

@dc42 @jay_s_uk
Thank you both for the help!
I will try with the 48mm 2.3A version.

@dc42 Standalone

@droftarts That has solved the problem. Thanks for your help!

@o_lampe Thanks.
These aren't brass water connectors. That would be too heavy! 😉
They are from coated titanium.

EDIT: I tried to save weight where it is possible. I used aluminium bolts to mount the parts on the effector. Next time it would be suffizient to machine the effector in a "L-shape" instead of a "U-shape". Actually it is more than stiff enough and that would be safing much weight.

@cosmowave you don't need a pullup resistor anyway when driving a SSR.

@cosmowave I was able to print only with T1 on a dual head setup by deactivating T0 in Cura before slicing

@deckingman @Phaedrux Thanks for your inputs. I will try it with temp=0

On the hardware side i've used following parts:

a Raspberry Pi Pico Waveshare 1.3 inch OLED, https://www.waveshare.com/wiki/Pico-OLED-1.3 two small diodes (1N4148)

Optional parts for the housing:

housing, PicoGehäuse.STL TPU front cover, DeckelFolie4.STL TPU cable outlet, KabeldurchfPicoAssy.STL

TachoMod.jpg
Sorry, the photo is not very sharp! And i know, the "S" on the TPU front cover is "upside down"...

The wiring remains like in my post from 13.9.22 except that i have inserted the 2 diodes in the signal lines. Also there is no need to set the "input bits" because we have a menu for changing the settings.

The TachoMod starts automatically when an input signal is detected. After start, it shows the period duration and the rpm of the incoming(top) and outgoing signals(bottom). see photo above

With the "S" button you can enter the menu (only possible when no input signals are detected), the "+" button increments values in the menu.
The following settings are implemented:

Multiply/Divide Mode: “/” or “x” ; Makes output faster or slower compared to input signal Factor (multiply or divide): 1-16 Delay time: 1-9999ms ; after which time without inputsignal the output will be switched off Pulse per revolution: 1-16 (normally 2) ; for calculating the correct rpm values

All settings will be stored automatically to onboard flash memory after leaving the menu.

And here is the source code of TachoMod_V4.0, written in microPython with ThonnyIDE.
TachoMod_V4_0.py
The code will be far away from "perfect", but it works.
And it was a really nice project for my first steps with a Raspberry Pico and the programming language Python.

I hope this description is more or less understandable and sorry for my bad english...😰

@dc42 Thanks for the info. My ssr should work with control voltages between 3-32V.

@dc42 Yes! It's working!
Thanks a lot!

@cosmowave If anything, I'd look for an optocoupled PWM board, but IMHO it's unlikely that a dead MOSFet backfires through the gate and damage the duet.