Welcome to the SeeMeCNC Community

RollieRowland wrote:
The steps per millimeter isn't specific to each tower, sadly. It isn't possible to do so with the firmware. If it were specific to the tower, to use my current method to find the actual value, it would require the diagonal rod length to also be specific to each tower. Even so, it is possible to at least partially correct the error that is created from having this value significantly off.

/** \brief Steps per rotation of stepper motor */
#define STEPS_PER_ROTATION 200

/** \brief Micro stepping rate of X, Y and Y tower stepper drivers */
#define MICRO_STEPS 16

// Calculations
#define AXIS_STEPS_PER_MM ((float)(MICRO_STEPS * STEPS_PER_ROTATION) / PULLEY_CIRCUMFERENCE)
#define XAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM
#define YAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM
#define ZAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM
#else

teoman wrote:

RollieRowland wrote:
The steps per millimeter isn't specific to each tower, sadly. It isn't possible to do so with the firmware. If it were specific to the tower, to use my current method to find the actual value, it would require the diagonal rod length to also be specific to each tower. Even so, it is possible to at least partially correct the error that is created from having this value significantly off.

Actually, it is easy to change the steps per mm for each tower. Maybe not in the eeprom without slightly modifyin the eeprom part of the software. Anyhow, this is what you have in Configuration.h

Code: Select all

/** \brief Steps per rotation of stepper motor */
#define STEPS_PER_ROTATION 200

/** \brief Micro stepping rate of X, Y and Y tower stepper drivers */
#define MICRO_STEPS 16

// Calculations
#define AXIS_STEPS_PER_MM ((float)(MICRO_STEPS * STEPS_PER_ROTATION) / PULLEY_CIRCUMFERENCE)
#define XAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM
#define YAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM
#define ZAXIS_STEPS_PER_MM AXIS_STEPS_PER_MM
#else

teoman wrote: A quick question before i spend money.

Will a dial gauge give better results over fsr's or something that can be used as a minimum Z limit switch on the software.

Also, is 0.001 precision overkill and 0.01 sufficient in your opinion.

I found a nice digital dialgauge that is 0.001 precision that also has a usb port that transmits data serially. But the price is a little bit steep if it adds no advantage. I would be capable of integrating it to RollieRowlands software.

In addition, with 10mm shaft or 25mm shaft it would be possible to do several different levels of probings. One zeroed at the bed, and then one zeroed say 1cm above the bed and 2cm above the bed. I am not sure if that would have any significant advante.

Here is the dialgauge that i found. Although the port on it looks like a usb cable, you need to buy a different cable to be able to use it (30~ dollar item).

I have contacted the seller and obtained the serial protocol for it. So integrating it to RollieRowlands software will not be a problem for me.

RollieRowland wrote: Yeah, wrong choice of words on my part. I meant in the EEPROM. I will look into this but because this would require a re-flash, it couldn't - without a lot of extra work - be done automatically.

teoman wrote:

RollieRowland wrote: Yeah, wrong choice of words on my part. I meant in the EEPROM. I will look into this but because this would require a re-flash, it couldn't - without a lot of extra work - be done automatically.

I think i edited my post after you posted/read it.

The EEPROM.h file should be modified, so that you flash it once, and then your program can access the steps/mm of each axis individually.

jason128 wrote:I'm going to bite the bullet and have another go at getting the Z probe working- my last attempt was not successful at all- hence I went back to playing with the HTML file version, which is good, but I'm still not wining at being able to get a flat bed.
Is there a link/ post of how to set this up? I have had a good look and didn’t find anything.

so here is my understanding of what the steps are:

1-Add a z limit switch stop- in my case a limit switch with a long lever tab hot glued to the effector- lazy, ugly, but works.
2- connect it to the Z stop min pins
3- change"has Z probe" in configuration file to TRUE - Don’t need to do anything else in the firmware as the Z stop min is the pin the software is expecting it on?
4 upload firmware with changes above to rostock max
5 test Z probe changes state when depressed. read HIGH when in the air LOW when hitting glass
6 change settings in software to probe instead of FSR run autocalbration software…. (which version now?)

What happens for me, it the probe moves down to about 150mm above the glass and starts its sequence. moves around like it should- carefully measuring air though. it then progressively works itself up in height untill it starts hitting the end stops, where it all gets rather ugly from that point on.

There's something missing above- a big thank you if you can tell me what it is?

bvandiepenbos wrote: The Traxxas joints are a spherical joint, with the "ZERO LASH STRAPS" pulling the arm pairs against each other (against the spherical shape)... there is no joint slop.

RollieRowland wrote:Yes, the tower lean is not able to be corrected in Repetier. Is this a modifiable value in Smoothieware?

The steps per millimeter isn't specific to each tower, sadly. It isn't possible to do so with the firmware. If it were specific to the tower, to use my current method to find the actual value, it would require the diagonal rod length to also be specific to each tower. Even so, it is possible to at least partially correct the error that is created from having this value significantly off.

RollieRowland wrote:

jason128 wrote:I'm going to bite the bullet and have another go at getting the Z probe working- my last attempt was not successful at all- hence I went back to playing with the HTML file version, which is good, but I'm still not wining at being able to get a flat bed.
Is there a link/ post of how to set this up? I have had a good look and didn’t find anything.

so here is my understanding of what the steps are:

1-Add a z limit switch stop- in my case a limit switch with a long lever tab hot glued to the effector- lazy, ugly, but works.
2- connect it to the Z stop min pins
3- change"has Z probe" in configuration file to TRUE - Don’t need to do anything else in the firmware as the Z stop min is the pin the software is expecting it on?
4 upload firmware with changes above to rostock max
5 test Z probe changes state when depressed. read HIGH when in the air LOW when hitting glass
6 change settings in software to probe instead of FSR run autocalbration software…. (which version now?)

What happens for me, it the probe moves down to about 150mm above the glass and starts its sequence. moves around like it should- carefully measuring air though. it then progressively works itself up in height untill it starts hitting the end stops, where it all gets rather ugly from that point on.

There's something missing above- a big thank you if you can tell me what it is?

For firmware modifications, did you assign the pin that you are using? If you are using Z-minimum on the Rambo, then the pin value is 10. I also turned wait before test to false.

From what it sounds like, the state of your switch is inverted - correct me if I'm wrong but if I recall correctly the H state should be the activated state. This would cause your issue; the probe will start at the designated height and set that as your Z-Max length. On the next iteration it will repeat and rise again... and again - most likely until something bad happens...

626Pilot wrote:

RollieRowland wrote:Yes, the tower lean is not able to be corrected in Repetier. Is this a modifiable value in Smoothieware?

No. I have some preliminary support, but I couldn't figure out how to correct the carriage heights in a single mathematical step - it looked like it might require converging on a solution until a sufficiently accurate answer was found (Newton's method) but I wasn't sure, and that kind of uncertainty bothers me in code that has to run 100s of times a second without taking longer than allowed. There might be a cleaner, single-step way to do it. I'm not much of a mathematician, so finding solutions to things like this is a very slow process for me.

The steps per millimeter isn't specific to each tower, sadly. It isn't possible to do so with the firmware. If it were specific to the tower, to use my current method to find the actual value, it would require the diagonal rod length to also be specific to each tower. Even so, it is possible to at least partially correct the error that is created from having this value significantly off.

Smoothie does allow setting steps/mm for individual steppers. That will make it easier to test this heuristic, at least on my end. Adjusting steps/mm doesn't perfectly capture tower lean, but it may functionally capture some component of tower lean. That might mean that we can get (for example) two more units of accuracy, at the cost of one unit of accuracy, thus providing a net improvement that wasn't available to us before.

jason128 wrote: Thanks for that- I did try the switch both ways, and got the same result - I suspect I haven't assigned the pin 10 correctly- I'll have another go tonight and see how it works

UPDATE- yep i have success! its happily running the calibration process right now.... as long as the hot glue holds out

UPDATE UPDATE... not so much success afterall. calibration seems to progressively wander off to one side, until it crashes into the glass. Ive tried twice now, and it seems to get the 'wobbles' and get progressively worse.

After the last time it had my
diagonal rod at 273.981
horizontal radius at 137.808
X tower endstop at 8465!!!!
Y tower at 2647
Z tower at 5066

alpha A at 225
Alpha b at 358
Alpha C at 75

this was doing an advanced calibration in version 3.0.0???

Off to have a beer instead.......

RollieRowland wrote:I have been pondering on the steps per mm correction - specific to each tower. One issue that I can foresee with having SPM specific to each tower would be an inconsistent offset in the z dimension across the cross-section of the build volume (progressively worse as the carriages get higher). I doubt that this tower error is truly able to be corrected without the ability to set the angle of each tower in the firmware. Based on the angle, the firmware could then adjust the delta radii/horizontal radius with changes in carriage height. Any other solution is not actually going to help, it will just move the error to a different parameter - in this case, one that is not able to be corrected.

One other issue that may show up even if the lean inward and outward of the tower(Y) can be adjusted, would be the angle of the towers perpendicular to the lean inward and outward(Z), and the rotation of the tower in respect to the center of the tower vs the printer - not alpha rotation(X). If these can be adjusted for, then the printer would know all three possible angles of rotation - X(heading), Y(pitch), and Z(bank). This would remove any possible error, yet, it is rather pointless when the machine could be precise in the first place.

With this being said, I am probably going to keep my calibration technique as a way of partial correction with error minimization.

RollieRowland wrote: Adjusting parameters for tower lean may not be the best solution, it is not - I shouldn't say impossible - improbable to be able to correctly find this value.

I agree, correcting the steps per millimeter could mostly correct the error caused by the tower lean. Also, yes, this would offset the scaling in the z dimension but having only one parameter to adjust for, would be preferable - the scaling of the prints can just be adjusted to compensate, assuming that the change in scaling in the z would be linear.

626Pilot wrote: In theory, if any gains can be found from modifying the steps/mm, my code will find at least some of those gains. It won't know whether it's correcting for tower lean, belt tightness, variations in how the stepper rotors were machined (if that's even a thing that matters), etc. All it will know is that one particular solution produced less Z error than the rest. All the solutions have to compete with each other in an environment where they're hobbled by a random number generator, so "only the strong survive."

My assumption is that the steps/mm really does have legitimate variations between towers, and that we're fixing that directly - rather than massaging something that's already correct, in order to try to influence something else that it has an effect on. If that assumption is correct, this will improve positional accuracy - and therefore scaling - on all three dimensions.

626Pilot wrote:I believe that adjusting steps/mm can probably help for minor variations between steppers, as well as in-out tower lean. As far as the kinematics are concerned, they're functionally similar. If the tower leans in, we need to send fewer steps. If it leans out, we need to send more steps.

Left-right tower lean is another matter. It will respond differently depending on whether the effector is to the right or left of the carriage. Correcting for this solely through steps/mm could cause accuracy that's slightly better on one side, and slightly worse on the other.

The most ideal solution would be to correct for steps/mm, AND tower lean, as completely separate variables. This is the question: "Given effector position XYZ and towers with endpoints ______, how far do the carriages have to be from the tower origins, in order to be exactly 269mm (or whatever) from the effector's ball joints?" Modifying the firmware to do this isn't too much trouble. The trick is knowing how to do it in a single step, hundreds or thousands of times a second.

HumanLiberty wrote:10k Thanks Rollie!

Cancel it though - I re-installed Repetier again and is seems to have resolved. Thanks again!

teoman wrote: For the tower lean you would ideally need x y position.


For this, what one could do is cut a straight piece of aluminium foil and then stick it to the bed. With the nozzle and the Al closing a circuit to detect position.


The nozzle should touch down on the Al and then when it passess off the Al will be detected and the point recorded.

Several linear passes, and you check in your software if those points are linear.

PikachuPorkChops wrote: Hello,

I've been trying to calibrate my bed with the manual HTML script over the last few days now and I can't seem to get good results from it. I'm using electronic calipers to measure and after 4-5 iterations I get the 6 points to +/- 0.01mm. The problem occurs when I switch out the calipers for the hotend and actually try printing. At about 5cm from the centre of the bed I get height deviations of up to 0.6mm. I don't understand what's causing this. Am I not supposed to change the zheight once I finish calibrating? Should I zero the calipers for every iteration?

Another thing I noticed was that when running your gcode, the probe ends up about 2mm lower when going to the bed centre as opposed to when I bring it down manually through MatterControl.

This is the mount I'm using for the calipers: http://repables.com/r/614 though I don't think it's the source of the problem.

Unless the answer to my problems is painfully obvious, it might be good to update the tutorial.

626Pilot wrote:I spent today writing some code into my calibration routine to try out changing steps/mm. I found that the forward/reverse kinematics in Smoothie don't consider steps/mm at all - they only care about millimeters, and let the Stepper class translate between millimeters and steps. This is a sensible solution.

Instead, I added per-tower scaling, effectively making each tower "longer" or "shorter." Functionally, the effect is the same as modifying steps/mm.

The annealer rarely touched the tower scaling. It would adjust all the other variables by a tiny amount every pass, but the scale multiplier almost never departed from 1.0. When it did, the resulting solution never had a winning score (lowest Z deviation).

These initial results suggest that there's no great advantage to messing with steps/mm, or tower scaling, or whatever you want to call it. I'm going to let some of my users mess with this, and see if it does anything for them.