Posts made by o_lampe

@Tinchus @dc42 I think, his intention is to constantly measure the slightly uncontrollable flow and change the printspeed instantly. (good bye planner queue)

@JoergS5 said in Can this 5-axis FDM be configured with RRF?:

built as spherical, i. e. the three axes cross in one point.

Just out of curiosity:
This crossing point is necessarily the tip of the nozzle? Or nozzle + layerheight?

@dc42 Just wanted to chime in with my 2 cents worth opinion:
The magnetic sheets used for build plates often have alternating magnetic polarisation. Like the one I use for my capacitive probe.
I never had a problem with that, but the SZP might.

@MihaiDesigns Pre-processing such a big part of a sliced file will mess up the extrusion calculation, too.
Unless your slicer already knows about the extra axes and it's just RRF that needs to be altered.

@NineMile Last time I tried, you could use sensorless homing/stall detection on any axis.
But you are right, you'd have to reduce motor current for those moves, but at the same time it needs a minimum speed to be succesful.
I wouldn't like to see my 50$ router bits crashing in a clamp.
Maybe a regular endstop-config would be a better choice? When the routerbit itself gets electric contact to the metal clamp it doesn't wait for so_many missed steps to trigger alarm.
@gloomyandy That kind of metal2metal contact probes would trigger in any direction, but you wouldn't know where the obstacle is. No problem for an emergency-stop IMHO

@Ralms instead of relais and optocoupler you might find a simple inverter/driver chip with optocoupled input in the good'ol 74hcxxx series.

For people not having that touchprobe thing, would it help to use modified "sensorless homing" moves as crash protection?
You'd check for contact , but don't set coords to whatever your homing coodrs are

@jay_s_uk I was about to edit my reply, because maybe the TS wants to use IO pins from the MCU directly?
In that case I wouldn't draw more than 2mA from each pin.

@Ralms said in Drive standard LEDs. What is the max current rating of IO pins?:

All 3 LEDs are built-in in the button, they share a common ground

Maybe you get more trouble from the fact that they share GND?
AFAIK all MOSFet IO-ports on Duet boards switch to GND and that wouldn't work for you.

@juanggrados You might be able to still use the board with low current steppers and using an external bed-heater power supply controlled by SSD-relais.

@Phaedrux said in fatal accident on my duet 2 wifi:

Bare wires have a tendancy to migrate and deform over time

Even worse, when soldered...
Over time even solid copper wires get loose under static pressure of a screw terminal. That's why we use springloaded push-in terminals in house electrics.

@Panzotom Your project sounds interesting, but are you sure you can control the robot with only one motor?
Even when you use the chain sprocket to drive a two-wheel chassis with a third (caster-) wheel, it won't drive a straight line on rough ground.

If I'd build this, I'd use two independent drives at least, maybe controlled like a tank.
I have experimented with brushless motors from used hoverboards. They are cheap and have hackable controllers, which also work with step/dir signals like a stepper.
The main controller could be a Duet board with extension port (Duet2 WiFi would be my choice)

The hoverboard tires can be replaced with tires for rough terrain. ( If I find the links, I post them later)

A good starting point might be EFeru-github or SimpleFOC (they have implemented a step/dir interface)

@Valveman Do you really want to use a fly-cutter for wood, not a planner?
I use such a cheap tool on my 710W Makita-clone router and it works really well on wood.
(I have a planer/thickener now, which can do the same in one go (upto 250mm width)

Anyway, I think it's possible to write a macro with nested for X/ for Y loops that will meander the tool across the surface. You have to calculate the turningpoints for the path's correctly to avoid crashing into the machine. But that can be done by setting the outlines of the board and the tool diameter.

@Valveman For engraving front plates I'd use openScad. Very old school, I know.
I came from SolidWorks and Fusion, but the free license of fusion was getting harder to extend and the functionality got limitted.
Then used FreeCad, but found it too complicated. (didn't try to find tutorials, tho)

OpenScad is like a programming language and that's where I feel comfortable with. (IT background)
Plenty of libraries exist, e.g. fonts, threading and screw libraries.

Usually I export .dxf files and refine them in inkscape for my CO2-laser, but it has a CNC output module for sure.

Either way you'll have a long learning curve ahead of you, might as well wait for lightburn to come up with their CNC version.

I just watched Christoph Lehners PrintNC build videos, which are quite funny because he shows the insanity of his approach.

OTOH it inspired me to build one, too since I already have the Makita router (60€ clone)... (just kidding)

@siltob1 According to the gcode-wiki G68 doesn't work when G53 is active and/or when a macro is active.
IMHO you'll have to find a workaround for your usecase.

@tristanryerparke said in 1HCL and cumulative deviation from accurate position?:

need to run through-hole slip ring wiring

I don't trust those slip rings too much. Even when you find a working speed threshold for now, it will decrease eventually. Or you'll see sporadic failure.

@Aitor I followed the thread with great interest, because I had no config/toolchange problem with my #hash printer which has 4 independent heads with cartesian kinematics.
I used to use RRF3.2 or 3.3, it might be worth to roll back to these FW versions and verify.
I also used Duet2 and an expansion board, so no possible CAN-address -issues either.

@tristanryerparke The mist is clearing!
Thanks for repeating the tests again. Using interpolation should be fine, since it's a driver-internal thing.
It shows that the python-wrap is still buggy and from the ~90th iteration seem to reach a new level. Why?

Chasing missed pulses via CAN is beyond my knowledge; maybe have the mainboard and the 1HCL count microsteps and compare them after 100 iterations? @dc42 ?

@droftarts My impression with partcooling fans is: they are already too late, because the fan needs to spin up.
Now adding another delay by using daemon.g makes things worse eg. for bridging.
IIRC a lookahead strategy is possible with the multi gcode planner, but how?