Clamping manual moves does not appear to work

[zenmetsu]

I have a delta printer with a 160mm diameter print bed and 190mm build height.

I have configured the build area as 160x160x190 with offsets of -80 -80 and 0. I have home position set to 0 0 190.

The problem that I have is that hitting the home button will home the printer as expected, but if the option to clamp manual moves is enabled, then the printer will only move X and Y after homing. I get an error stating that I am outside of my build volume if I attempt to move towards the bed from the home position.

Setting the Z offset to -190 will allow me to move down, but then loading gcode causes the parts to float up off the bed in the 3D view.

Additionally, moving X or Y more than 80mm does not appear to trigger Pronterface to stop the effector from moving... this is especially troubling since the X/Y manual controls are in powers of 10, and moving 100 from origin will cause parts of the printer to collide violently with the support towers as the device is told to operate outside of its effective and safe printing volume.

TL;DR, it appears that clamping manual moves only appears to have an effect on the Z axis when using a circular build platform. I have not tested on a cartesian printer yet.

[jspark311]

I have not tested on a cartesian printer yet.

I have a cartesian printer, and just tested. It would appear that my firmware is preventing printhead movement, but this doesn't seem to stop pronterface from incrementing it's own internal idea of where the head is.

I have a Solidoodle3. My build plate is 200.0. x 200.0 x 200.0 in the pronterface settings, with the Home position at (0, 0, 0). Something looks amiss in both the limit-clamp code, and the internal representation.

I don't speak python, but I'll dig for whatever you need, and run tests if you like.

Log Follows: echo:endstops hit: X:205.69 echo:endstops hit: X:205.70 echo:endstops hit: X:205.72 echo:endstops hit: X:205.73 echo:endstops hit: X:205.74 echo:endstops hit: X:205.75 echo:endstops hit: X:205.00 <---- Re-homed before this line. echo:endstops hit: X:205.01 echo:endstops hit: X:205.02 echo:endstops hit: X:205.03 echo:endstops hit: X:205.05 echo:endstops hit: X:205.06 echo:endstops hit: X:205.07 echo:endstops hit: X:205.08

[zenmetsu]

OK, I have looked at the code.

The moveXY function is not suited for delta bots, only cartesian. The constraints on X and Y motion only check to see if X or Y exceed the boundaries of the "square" surface defined by elements 0 and 1, width and length, in the build dimensions list. We really need to check to see if circular build volume is selected, and if so, check the distance from origin to make certain that the maximum radius is not violated.

Since width and length are defined separately, the user can input an ellipse with non-zero eccentricity. This is probably never going to be the case since deltas have 3 arms and only one is along a major or minor axis of the ellipse. As such, clicking "circular build platform" should re-label the fields so width is renamed 'diameter' and length is greyed-out. Also, the X and Y offsets should automatically be set to 'diameter/-2' and be greyed-out so the user cannot modify. Internally, Diameter should set the width and length values so there is no need to use a separate build dimensions list.

In addition, according to how the functions are written, I should be setting z-offset to zero (as I am doing) and setting z-home to my height value. Even when doing this, I still get the clamp-error when I attempt to move in Z-minus direction after homing. Additionally, X or Y jogs will violate WIDTH or HEIGHT values without generating an error. Without actually knowing where pronterface THINKS the print head is, this problem becomes very difficult to diagnose. It is lamentable that pronterface lacks a live X/Y/Z position in the status bar that shows the user where the print head SHOULD be.

[jspark311]

@kliment : What is the commit process for this repo? Should we be forking to fix bugs?

[iXce]

@jspark311: indeed :)

[zenmetsu]

sadly I'm on a Mac primarily and don't have a decent build environment to test my fixes. Guess I'll be going back to my linux box for this project. :)