Topics created by bondus

I'll probably sort it out. Just venting a bit 🙂

@vijays I also see this post:
https://forum.duet3d.com/topic/31649/duet-3-board-gpio-input-heater-control/3

I assume they are related?

The 64 is somewhere between the 128 and 32. It looks like the driver does something useful with the finer stepping.

I would guess that for static resolution it is pointless to go over 16, but when constantly moving the drivers can do something useful with the extra step information.

It would be interesting to test this out on a delta, or a regular scara. It might only be visible with the low gearing I have though.

The engineers at TMC are magicians.

Best IMO is to remove the pins from the connector shell at one end (easy with the Molex KK connectors); then hand-twist the 4 wires around each other without imparting a twist to the individual wires; then re-insert them in the shell. If you twist the cable with the shells in place, then the individual wires have to twist, and then they will tend to un-twist the cable.

For stepper motor cables, I prefer to twist the two wire in each phase around each other; then loosely twist the two pairs around each other. This minimises magnetically induced EMI.

@o_lampe
I have also found another gear box with only 0.3 degree of backlash but maybe it’is still too much(?).

For sure a servo motor directly coupled to the arm joint would be a better choice but it will make the system more complex.

@bondus said in Warning: Heater 1 appears to be over-powered:

The thing heats up really fast,

This is also why it can reach that insane max temperature. 😉

The risk is if the power mosfet will fail and become a short. The CPU will not be table to turn it off unless it can shutdown the power supply.

That's good. I'm aware of Eclipse and actually use it for some things in all kinds of strange versions. It's a fine tool for development, but not for builds or integration.

I've also seen so many compilers and tools get buried in licenses and obsoletion of platforms that it always lights up alarms to see some massive IDE been mentioned when something is supposed to get built.

@bondus my first tests with ESP32-CAM were unsuccessful, I will need more research. If you have hints how I can improve the encoder, please tell me!

My current approach is:

make the printout as big as possible, the resolution is better then. 30 cm diameter means maximum resolution at 600 dpi: 22231 dots, one dot means 1/60 degree. The dots could be subsampled by the camera. I thought about using a neuronal network solution. buy ArduCam OV2640 and OV5647, where the objective can be removed to go with macro focus. For OV5647 I will need a Raspberry Pi Zero W each. There is a breakout version of OV2640.
If resolution is too low, I will wait for the new sensor OV48B ! (a joke, main problem will not be the resolution, but the focus)

@bondus said in Custom probe points for mesh bed leveling:

One point is also totally off

You can actually edit the heightmap.csv to alter any completely bogus points to be more reasonable.

@dc42 said in How are the axis coordinates supposed to be set when homing?:

@bondus said in How are the axis coordinates supposed to be set when homing?:

I don't need to tower to be able spin 360 degrees, it would tangle the cables. If you do want the tower to rotate multiple laps the cartesian->motor transform function would have to keep track of what lap you are on and select the appropriate stepper position.

RRF already does that for you, if your kinematics returns true from the call to IsContinuousRotationAxis for that axis.

Neat. It's implemented very simple, nice.

I can see that the Scara model makes heavy use of that. You can build some very strange Scaras.

The electronics isn't really made for it, however I admit to doing it quite often myself when using the 4-way cable. If you are using the ribbon cable, do not do it with an SD card inserted in the PanelDue.

I dismantled that printer a long time ago. And honestly it is a poor way to build a printer. It was pretty wobbly side-to-side, some proper engineering might make it better.

I could dig around for some old code if you want. Mathematically it was not that hard to figure out, old high school math.

@domingo, is this still a problem? Are you running firmware 2.05.1 now?