Do we need ChainPitch and GearTeeth Settings?

Technical Details
1

For the main motors we input the GearTeeth and ChainPitch into GC, which then sends this to the firmware. But in the Firmware I believe this information is only ever used as MMPerRotation = (GearTeeth * ChainPitch). Is GearTeetch or ChainPitch used anywhere else? Or could it be?

I note that for the zAxis we only have MMPerRotation.

I ask because I am neck deep in the settings and if we get rid of those two and move to just MMPerRotation we would save ourselves 8 bytes (8 because we calculate and save MMPerRotation anyways). Not much I know, but everything counts.

2

I donā€™t see it used, but 6.35 is hardcoded in the calibration routine to calculate distance between motors and distance between mounting points on sled (latter is only relevant to quadrilateral sleds).

Iā€™d leave it in and then update the cal routine to reference that value (that way it would work with a different sprocket and chain)

3

Could this account for the issue we saw converting to inches?

edit - when selecting inches.

Thank you

1 Like
4

They are also currently used in System.cpp to define kinematics.R:

if (gearTeeth != -1 and chainPitch != -1){
    float distPerRot = gearTeeth*chainPitch; 
    leftAxis.changePitch(distPerRot);
    rightAxis.changePitch(distPerRot);
    zAxis.changePitch(zDistPerRot);
    
    kinematics.R = (gearTeeth * chainPitch)/(2.0 * 3.14159);

Having said that though, distPerRot/MMPerRotation could be used instead.

5

I think that is just in GroundControl is that right?

No this is unrelated.

Yes, you are correct, but again there they are immediately turned into MMPerRotation and then divided by 2 pi.

I am confident right now they are not used independently. Does anyone think they will be in the foreseeable future? They can always be added back, I just donā€™t want to remove them if someone has some kinematics calculation they are working on that I donā€™t know about.

1 Like
6

I personally do not foresee them being used individually. Even if we incorporate chain stretch and sag in the future, only the combined MMPerRotation would be needed.

7

One of the methods that Iā€™m planning on using to test increasing the max feedrate is by swapping out the 10 tooth sprockets for some 25 tooth sprockets. It would be much easier to make the change if that setting is still available. However, it would not be impossible for me to just do the math myself and input that as the MMPerRotation if it makes writing the firmware easier.

1 Like
8

Those values could live in the GC Settings page, but wouldnā€™t need to be stored in the firmware, maybe.

9

Yes, exactly, we can just do the math before sending them to the Firmware. It doesnā€™t so much make things easier, it just saves precious RAM.

1 Like
10

Even better! Efficient programs are always better! I had thought that we were removing it from GC, but it definitely makes sense to do the math before sending it to the firmware.

11

I second that! I canā€™t see any reason we need them internally in the firmware as long as we can do the calculation in Ground Control

12

Ah, got itā€¦ yes, I donā€™t see it needed in the firmware.

1 Like
13

I wouild prefer that this be in the firmware, there are various other places
where the info is needed (although it could be calculated from other values)

I am looking to the long-term situation where we may be able to use grbl senders
to initialize the maslow rather than needing a maslow specific program.

I much prefer people input simple, obvious numbers like chain pitch and number
of teeth rather than calculated numbers like mmPerRotation.

14

I was thinking that maybe down the road if some people are experimenting with using cables and drums then maybe mmPerRotation would be more applicable than the gear teeth?

15

how is this done in 3d printing?

Servo+gearbox+encoder works the other way around then a stepper. But isnā€™t there a way to ā€¦
Waitā€¦ this is that way. one rotation is x number of encoder positionsā€¦ that then comes down to mmPerRotation right?

I should not compare it to the DPI stuff in Inkscape but I must bring it up as an instance to prevent a similar problem i guess.

It looks a bit like a catch 22.

In gcode itā€™s all about co-ordinates go to origin and then move x mm in any direction. (or inch to make things a bit more complicatedā€¦)
so GRBL sender just sends those co-ordinates to the machine just like GroundControl

So on the machine (firmware) you need as little as possible variables.
Making the mechanical design as simple as possible, in that respect.

if possibleā€¦

Iā€™m just thinking out loudā€¦ Trying to figure out the connection between GRBL and long term simplicity.
Is there a ā€˜GRBL point of viewā€™ on this?

Are there ways to make this more simple as in cancelling out complications against eachother?

16

how is this done in 3d printing?

Servo+gearbox+encoder works the other way around then a stepper. But isnā€™t there a way to ā€¦
Waitā€¦ this is that way. one rotation is x number of encoder positionsā€¦ that then comes down to mmPerRotation right?

no, it comes to encoderstepsperrotation, unless you know the effective diameter,
you donā€™t know how many mm are in an encoder step

It looks a bit like a catch 22.

In gcode itā€™s all about co-ordinates go to origin and then move x mm in any direction. (or inch to make things a bit more complicatedā€¦)
so GRBL sender just sends those co-ordinates to the machine just like GroundControl

So on the machine (firmware) you need as little as possible variables.
Making the mechanical design as simple as possible, in that respect.

if possibleā€¦

Iā€™m just thinking out loudā€¦ Trying to figure out the connection between GRBL and long term simplicity.
Is there a ā€˜GRBL point of viewā€™ on this?

Are there ways to make this more simple as in cancelling out complications against eachother?

thatā€™s what the topic on triangular calibration is about.

as you note, g-code doesnā€™t care about the mechanics, it is just saying to move
from point A to point B. grbl is a long-established firmware and there are lots
of things that know how to talk to it (including setting variables)

Ground Control does more, in that it does calibration calculations.

If we can get the calculations simple enough, we can make them be a function in
the firmware and call the function to do the calculation. That would free us
from a dependency on Ground Control

1 Like
17

@vertex

Most 3D printers to this point are open loop. Stupid devices, if I send a code to move one unit forward I assume it happened. No encoders. They mark 1 axis limit by an endstop switch and assume the distance the opposite direction with a small safety margin. A new chipset out allows the noise in stepper motors to report back over a communication channel. The motor is able to tell if it had a problem and act accordingly. This is really just getting implemented on the 3D printer side. This is a slick low tech way to cope with this.

Stepper motors with actual encoders are Expensive > $150 per motor.

While 3D printers look like Laser cutters and CNC routers they can be worlds apart. One is additive manufacturing and the others are subtractive manufacturing. They can use motors, servos or stepper motors.

While I have been aware of stepper motors for a long time, Iā€™ve just recently built a project using them and H-bridges.

In general there are some very different things going on with your ā€œtoolā€ . For a router we are switching a spindle on or off - Binary. With a laser you are usually using PMW to tell the Laser how much power to output. In a Printer Extruder you are pushing and pulling material back and forth constantly like a syringe to cause varied pressure during deposition.

On a 3D printer there is a test where you take a know quantity of material and use it all. You observe how far it goes and how fast, feed and speed, and adjust until you get the use of a know quantity over a know time and space.

All of these processes have 1 thing in common - gcode. Relative motion, speed and feed.

I will leave you with this. This is example is not a 3D printer but a use of 3D printing. An artist created his own extruder and made it work. He is using 3D printing as a medium for his art. I donā€™t know how he put together the software. It is one of my favorite 3D demos.

I have considered endstops on the Maslow but I think keeping it simple is best, I like it as it is. We measure, test adjust.

Thank you

2 Likes
18

:slight_smile: iā€™m all for simple.

I hoped there was a reverse way of using 3d printing principles in some way.
As long as a 3d printer is not loosing steps itā€™s very straightforward and accurate. But in a way it would have made sense to use servoā€™s on 3d printers instead (this is what made inkjet printers cheap)

The stepper with itā€™s own feedback loop sounds very interesting too

It would be cool to make a delta robot with the Maslow servoā€™s

Will have to watch the video when i get home again on a more usable connection speed

EDIT: That printer is kinda big. :slight_smile: