Topics created by Psylenceo

@psylenceo comparing floating point numbers for equality is never a good idea in programming, except in limited cases, because floating point maths is not exact. Use something like this instead:

if abs(move.axes[2].babystep - 0.050) < 0.001)

@dc42 said in Adding current sensor and readout to DWC:

@ChrisP said in Adding current sensor and readout to DWC:

This is a pretty interesting topic - I was only thinking of trying something similar the other day! Is there any way to get this data plotted on the temperature chart, as an additional y-axis perhaps? That'd be sweet!

Yes, in RRF3 any sensor that you create using M308 can be displayed in the temperature chart. Press the Extra link just above the tool display in DWC to get to where you can enable them. But I don't think you can change the Y axis units from degC yet.

Ah, great! I don't know why I didn't think of that - until the latest releases, this is what I've been doing anyway to show the extra bed sensors I have!
I guess a super low priority feature request is to have some means of adding additional y axes and assigning sensors to axes. As a temporary hack, if a scaling factor could be applied to a sensor value then while the label would still show degC, the data wouldn't be hidden at the bottom of the graph.
Neat, nevertheless.

Define macro "StartStuff.g" or similar. Content:

M291 P"Run startup bed leveling and such?" S3 G28 G32 ...whatever...

This will result in a dialog on the web console:

99d9a6c4-b46f-48ff-b57a-b4a028bae2bc-image.png

Pressing OK will result in the rest of the macro (G28 and so forth) running; pressing cancel will end the macro immediately.

Test this; when ready to have it start every time, place

M98 P'StartStuff.g"

as the last line of config.g

p.s. No conditional gcode per se; this works right now, in all 2.recent and 3.recent versions of firmware, with or without a Pi.

@Psylenceo said in Duet 3 stall detection and hardware customization and testing:

I don't consider sensorless homing as a gimmick.

I understand and respect your opinion. In fact, I find sensorless homing 'elegant' in a parsimonious engineering sense.

At the same time, given fixed development resources on the firmware, I'd put it somewhere below fundamental things like movement, or properly handling M999 (which V3 does not at this time), or similar.

Anyway, I do understand, and appreciate, the different perspective.

I'm going to guess that another place where our opinions differ is skipped step detection. I believe (opinion only, free and worth every penny) that a properly engineered 3D printer should never be anywhere near skipping a step. I further believe that if one skipped step does occur because of something out of kilter, like a jammed pulley, or whatever, that a lot of them are going to occur.

To me, it is not worthwhile to spend enormous time and energy making an "open loop" system into a hybridized solution. Not when true servos and controllers designed to use them already exist.

Again, if sensing a stepper in open loop were the only option, my opinion might be different.

Having said all of that... were I motivated to skip-detect, I believe I'd put the position sensing, and counting/matching/detection all local to the motor. And feedback only "OK" or "Not OK" to the main controller. Mostly because I'd find that elegant as well... and partially because that feedback could be connected to a general IO pin and dealt with as a "Stop" via configuration, no changes to the firmware itself.

Anyway, that's all just thinking out loud. Whatever you decide to do, keep us posted!