Simpler Kinematic Equation

Re: Simpler Kinematic Equation

Postby machinofacture » Wed Jun 25, 2014 12:40 am

What I was planning to do was get some place-holder values for the critical parameters, good enough to make a rough attempt at moving the head up and down and around. Then, basically just move the head until it makes contact with the platform. I will attach a switch to the head and write a python script to move a tiny bit via gcode then get the current endstop status to see if it has hit the bed. Then I should be able to get the current arm positions when the head has touched the bed, and in so doing automate the touch point generation.

Then you can iterate by getting a bunch of touch points, calculating better parameters, and then getting the touch points again.

I do not fancy moving the head around manually and sliding a paper as you suggested to get 100 points :)

I am pretty sure that the existing delta code in marlin does segmentize on the fly. Am I wrong about that?
machinofacture
 
Posts: 20
Joined: Tue Jun 17, 2014 12:02 am

Re: Simpler Kinematic Equation

Postby Nicholas Seward » Wed Jun 25, 2014 1:39 pm

That plan sounds perfect! Yes Marlin does the segmentation. (I think it does it differently. Someone told me it divided each move into a certain number of submoves but that sounds dumb. You will have to check the code to see what it actually does.)
Nicholas Seward
 
Posts: 738
Joined: Mon Nov 25, 2013 10:41 pm

Re: Simpler Kinematic Equation

Postby MrFaul » Wed Jun 25, 2014 8:01 pm

Damn Marlin is a huge mess... well haven't look at other firmwares so far, but man it is a real pain to find stuff you are searching for...
Clearly the programming skills where still in development when he started to write that thing...
or he was just lazy when he imported stuff from the firmwares Marlin is based off....

So after a while I found it:

Marlin_main.cpp
Line: 3204

Thats where the magic is happening.... at least the transformation.
There is no way to simply "add" a new movement type, so my suggestion is to rewrite the current "delta" to "GUS" in a new fork.

There is still a lot off dedicated delta stuff around (stretched over multiple files) so editing the calculation is the most efficient method at the moment.

What it actually does is to take the given cords and saves them into a "delta buffer" which is then send to the steppers instead of the cartesian values <- means those are lost didn't dig deeper but i believe you get translated values back if you ask him where he is.
MrFaul
 
Posts: 31
Joined: Fri Feb 14, 2014 8:17 am
Location: DE Wuppertal

Re: Simpler Kinematic Equation

Postby MrFaul » Wed Jun 25, 2014 8:22 pm

Nicholas Seward wrote:That plan sounds perfect! Yes Marlin does the segmentation. (I think it does it differently. Someone told me it divided each move into a certain number of submoves but that sounds dumb. You will have to check the code to see what it actually does.)


Oh about those submoves... if my brain comprehended that right, it does. It should use those submoves for correct acceleration planning but I'm only guessing haven't read that part really just noticed it on the fly.
MrFaul
 
Posts: 31
Joined: Fri Feb 14, 2014 8:17 am
Location: DE Wuppertal

Re: Simpler Kinematic Equation

Postby Niggle » Wed Jun 25, 2014 9:59 pm

I've spent the day going over my changes and fixing bugs.

Storing the calibration values to EEPROM was easy and I've hijacked M665 and M666 to allow updates on the fly.

I haven't added a raw move code yet.

Maybe I'll manage a push tonight.
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: Simpler Kinematic Equation

Postby Nicholas Seward » Wed Jun 25, 2014 11:14 pm

@Niggle: I have always been curious. How many places would I need to touch to change the kinematics to work for another arbitrary printer?
Nicholas Seward
 
Posts: 738
Joined: Mon Nov 25, 2013 10:41 pm

Re: Simpler Kinematic Equation

Postby Niggle » Thu Jun 26, 2014 7:29 pm

OK - I have created a GUS_Marlin repository. It contains 4 files that need to be merged into Marlin_v1.

At this point I haven't even tried to compile the changes.
My design philosophy was to treat GUS as a variant delta and so almost all my changes are wrapped in
#ifdef GUS
.
.
.
#endif GUS

ConfigurationStore.cpp has changes that deal with moving the calibration values to and from the EEPROM

Marlin.h has declarations for the arrays to hold the calibration values

Marlin_main.cpp has all of the significant code changes
The kinetics code lives here.
The hijacked Mcode support lives here.
M665 sets max arm length
M666 sets shoulder height
G28 handling changes

Configuration.h has the usual scattered changes.
The #define GUS is here. (Along with some unused #defines that I need to clean up
The default calibration values are here, next to the AXIS_STEPS_PER_UNIT

@Nicholas: Even though this set of changes is a variant of DELTA, support for arbitrary kinematics would follow the same pattern. I would still search the codebase for #ifdef DELTA to check that no other changes were needed.
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: Simpler Kinematic Equation

Postby machinofacture » Thu Jun 26, 2014 9:40 pm

Awesome! Thanks Niggle.

I will try this out when I get home.
machinofacture
 
Posts: 20
Joined: Tue Jun 17, 2014 12:02 am

Re: Simpler Kinematic Equation

Postby Niggle » Fri Jun 27, 2014 12:47 am

Pushed a few bug fixes so that it compiles now.

@Nicholas: I'm not convinced that you need an Mcode for a raw move. I think that all you need is to get distance to home in the log. Using G1 with Cartesian cords to find a touch point is simple enough. If G28 reported the distance travelled to each endstop, you would have all the data you needed.

I need to do some experiments.
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: Simpler Kinematic Equation

Postby Nicholas Seward » Fri Jun 27, 2014 2:36 am

@Niggle: Sounds like a plan.
Nicholas Seward
 
Posts: 738
Joined: Mon Nov 25, 2013 10:41 pm

Previous

Return to GUS Simpson

Who is online

Users browsing this forum: No registered users and 1 guest

cron