Topics created by roboduet

@dc42:

Yes, I need to remove the "Stable" folders

By the way, this was useful for those who know about [c]git pull[/c] command. I'm one of those who used this command - just two words to get latest available firmware, readmes and source code together. But I agree that releases page is more appropriate place for binary files.

Firmware 1.19 will include manual delta calibration and mesh bed compensation facilities, supported by new features in DWC and PanelDue.

Yes, I know both about flex3drive and Zesty's extruder. But I thought to do everything myself. This is just small experiments with my delta printer in spare time.

About gearing - seems like highly geared dc motors from Pololu will be very slow with 12 CPR magnetic encoders. For example, 1:1000 geared dc motor will have only 32 RPM speed with no load.

I have also various high density (150-180 lines per inch) circular optical discs (encoders) from inkjet printers, but they are quite large (relative to motor itself).

That's correct at present. There is work scheduled to allow commands from other input channels to be accepted when M109/M190/M116 are waiting for temperatures to be reached.

Yet another two examples. I just created g-code with 50 millisecond segments (F1200, 1mm movements), so pauses (or step signals with shorter interval) going exactly every 50 ms, easy to find in analyzer logs:

All three motors paused at 7.420+ s position
Pause for X step, premature step for Y and Z at 7.520+ s position

Pause for X and Y, premature step for Z at 7.670+ s position, also steps are skewed at 7.770+ s position

Yes, I very well understand that.

The E0 endstop is used for the U axis if you have one in firmware 1.16. In machines without the U axis it can be used to connect a Z probe (type 4 in the M558 command). Likewise E1 is used for the V axis. Endstop inputs that are not used for anything else can be used to trigger macro files, see http://reprap.org/wiki/G-code#M581:_Configure_external_trigger.

With firmware 1.16 the U and V endstop status is shown in the M119 respond and in DWC if you create the additional axes using M584 and then enable U and V endstop using M574.

Aargh! USB. Also three decimal places. Is it feasible to make all that debugging info go to the web interface too?

You're right, though, that the question is: what changes in the measured values cannot be accounted for with all the other parameters, but can be accounted for with tilt parameters? As long as there's something, they do provide assistance, but if most of their effect is soaked up by endstop offsets and tower position adjustments, then you're stuck with a highly covariant set of parameters. Even if the numerics can be made to behave, manual adjustment is going to be annoying. The worst case is if the effect on the z=0 plane is identical but the effect on print geometry is different; then you need both for accurate printing but you can't measure their effects by probing the bed.

Thank you for explanation. In this case I should enable debugging via M111, start Wireshark and try to understand what happens with freezes that I described.

@hamel:

Are you still planning to update the bed.g generator for more points? I would love to use more than 16 points, as I have a large bed….but I really am too lazy to make a bed.g myself...lol.

You can try also my generators: https://www.duet3d.com/forum/thread.php?pid=18892#p18892

Have there been any advances on the topic? I just broke my chamber sensor but there are still tons of DS18B20's lying around from my arduino days...

Thanks for that explanation. It's different from what the wired Duet does - but the wired Duet doesn't use the lwip socket interface. I presume I could replace the socket close call by a shutdown call to avoid the reset.