Posts made by oc_geek

@gixxerfast said in Neopixel support on 1LC?:

Yep, that would be really great.
The new voron toolhead is coming soon with nozzle lights (and a bling lit logo.)

Would be nice to combine with the 1LC. I need only two max three leds.

Voron Design Stealthburner yet to be public

Yeah as Gixxer said this is the driver (it equips three RGBW discrete neopixel leds)

Also our Klipper "colleagues" (which always are some meters ahead....of us) already have a tool-board with that supported...
@dc42 Thanks for moving this forward and make it a Christmas gift

@gixxerfast said in PINDA leveling sensor:

@thedragonlord said in PINDA leveling sensor:

Volcano heatblock... could be an issue?

Let's see if we can ping one opinion at least @oc_geek What's your thought of the Vinda close to the hotend, OK?

From my short experience with that probe it needs a quite thermal environment for returning reliable reads (temp ~ constant) and i think it struggles above a certain temp too. In all honesty i stepped away from such a probe... and rather quickly
However i have Voron printer which has a closed / heated chamber and so on... so it might be different in your case.
Personally i do not like it and do not like the very short range of action either. I found alternatives based on microswitch (we call Klicky in Voron context) to be infinitely better...

@t3p3tony said in Connecting and reading a pulse generating encoder:

I have moved this to the firmware wishlist to further the discussion about how we might be able to support using filament monitors for no printing extrusion moves such as this.

Hi,
Is there any ETA for this feature being implemented any time soon ?
thanks

@t3p3tony
thanks guys !
would be great to see something like that supported in the fw

@pfn great work !
thanks for all what you did and are doing

@pfn yeah will have to check as you say

Option 1 is not possible as the "encoder wheel" is actually a metal Bondtech gear (as i wrote before below)

Option 2 seems to be the only practical possibility

Also the challenge will be to port the Klipper python module into RRF Marcos...

@pfn as i wrote this came from the Author of the unit itself... it's not that i need something..

The sensor is used ONLY when loading / unloading the chosen (between nine) filament to the tool to make sure it arrives where intended and does not jam the unit and so on...
I think they do that faster than a print feed rate to reduce the overall print time...(e.g. 1000 filament changes in a print would matter..)

that said i did not got any data point from the Duet team on which rates (Hz) are reachable using a trigger... or any other offered solution...

@dan1990 rightly said

in particular the part responsible for the Pulse Generating encoder is a Klipper module written in python

@cncmodeller
Yes i do get disconnects (like in the morning after night prints). See my opened posts on the topic...

mini-5-wifi-connection-unstable

duet-3-mini-5-connection-lost-and-files-missing-again

That said it is a lost battle to get any attention on that topic in here...
Earlier the HW was replaced under warranty (got 2 replacements..) lately it aint the case anymore... and you are left living with the erratic behavior

The best you get back is that your wifi network is unstable or your wifi router has flue... while i'm convinced the bug is in the FW..

@t3p3tony i saw that but it wont be possible to inquire the position nor to reset it (unless i'm reading it wrong)

@dc42 i understood they use it to determine the filament position (real travel distance) when loading a specific filament in the MMU down to the tool head
With the encoder they say it is possible to meisure with a precision of 1 mm
Direction is derived by other means and hold by other variables

All that said would it be possible to use triggers to follow it up @ e.g. 250 Hz ?

@t3p3tony as far as i could see from the Discord ERCF 1.1 discussion it reads a Bondtech gear which rotates with filament
Filament running at 20 mm / sec so that's where the 200 - 500 Hz comes from (i'm just reporting what i was told)

@pfn i kinda know why you ask

I'm doing exactly the same

Already reserved the space for it

@pfn
Thanks for the explanation.

I realize just now that this is the same "trick" i use for the filament sensor which is on my Mini5+ while i use the 1LC as tool board. Makes sence

That way you basically invoke the trigger and add 1 to the counter. Good idea. I hope it can stand the 500 Hz rate though... @T3P3Tony (do you know ?)

So couple of macros (count and reset) and we shall be in the game

I'm at the same stage of yours atm.
I have bought some of the key parts but have not yet printed it.
I hope we RRF folks are in the game too

@t3p3tony Hi Tony, thanks for coming by

I have to confess i'm totally ignorant. I'm just trying to figure out if there is a way for RRF to use the Enraged Rabbit MMU 1.1 (Voron)

The pulse sensor is a TCRT5000 (IR Infrared)

TCRT5000 infrared reflective sensor
Detects the reflected distance: 1mm ~ 25mm Applicable
The working voltage: 5V
The output format: digital signal (0 and 1)

I suppose it just sends digital 0 or 1 (without a specific protocol)

Any advice help is very much appreciated in advance

@pfn yeah that is indeed for the new CF 1.1 which uses a pulse counter on the unit. In clipper they dev a piton module so macros are gone and the porting to RRF is no more an option

I like your idea. And yeah i'm in on the global variables (that was my target too) but i miss the way to count the pulses event (at that speed too)

Could you please elaborate more on the wiring and how would you read (or detect the trigger in that logic) the pulse.
On the printhead (extruder) there is a (hall sensor) filament sensor which detects the filament reached past the gears but that is something manageable which (i thinnk) is doable
thanks

(p.s. Mini 5+ it is in my case)

I try to ask even if i fear to know the answer already..

For an Multi-Material-Unit project (in the Voron 3D printer context) we would need the ability to :

• reset the counts
• fetch the actual counts

out of a pulse generating encoder (200 to 500 Hz is the rate)

Is there any way to do so with Duet fw at present ?
If so how...

(looked at the 1HCL too but it's targeting quadrature encoders..so..no go)

thanks

@simwiz The filament sensor has to be on the same board the extruder is (don't ask how i know that)
That said you can use events triggers to circumvent that and connect it to the Mini 5+

This is how i did it:

; ==================================
; FILAMENT SENSOR TL
; ==================================

; need to define a trigger as the Filament Monitor is on main board and extruder on 1LC (not supported...)
M950 C"io3.in" J0 ; define pin0
M581 T1 P0 S1 R1 ; uses pin0 transition (only when printing from SD card) for calling Pause.g

@chrishamm sorry but the USB port of the card in a Voron 2.4 installation is under ~45 Kg of metal and plastic and it is unreachable from external... i'll pass for now..
i think i did what i judge to be above enough replacements (this is third Duet Mini 5+) with the Duet boards on my side...

Perhaps you can replicate the issues on your side and find solutions without the continuous need of users becoming debuggers...

If it helps
i was able to quickly capture today the moment the card entered in "crazy horse" mode (was fine for days and suddenly it happened again)
The capture file is short and seems to contain the communication issues in there

Wireshark capture July-29-2021

thanks

Hi,
would like to report a very strange behavior i stepped into
which i couldn't explain and i believe to be a bug

Case is this:
A macroA is calling macroB which has a condition in the end of the file with an abort command if condition is notmet.
The abort command is last line in the macroB.g file (in an if / else construct)

Even in case the condition IS met a silent abort is triggered and any further g commands in macroA are not executed (aka an actual abort has been issued)

The macroB is like this

( bla bla bla Gcode)
if <condition>
   echo "Probe is attached to the tool"
else
   echo "Error probe not attached - aborting"
   abort

Now even if the condition IS MET (proved by the echo in console) the calling MacroA stops executiing any further g commands (following the call of MacroB) like an abort was executed by MacroB (without reporting anything - i call it silent abort).

I turned my head 100 directions to figure out WTF was going on in the calling MacroA

I solved it by putting an additional line in the MacroB at the end like this

( bla bla bla Gcode)
if <condition>
   echo "Probe is attached to the tool"
else
   echo "Error probe not attached - aborting"
   abort
; finish

and now it behaves as expected an no "silent abort" is issued

Looks like "abort" line at the end of a .g file does weird things

P.S. This is with FW Rel 3.3

@dc42