GUS_Marlin status

GUS_Marlin status

Postby Niggle » Thu Jul 03, 2014 4:45 am

I have a variant of Marlin that includes GUS kinematics that I am testing.

At present, it uses Nicholas' coordinate system - cartesian [0,0,0] in the center of the bed.

machinofacture is running a variant, which places cartesian [0,0,0] at the foot of the x arm and also enables a z-probe.

I want to, at some point, push my changes into the Marlin master code branch. Before I do that, are there any feature that you would like to see implemented?
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: GUS_Marlin status

Postby machinofacture » Thu Jul 03, 2014 10:11 pm

Here are some things I would like in it:

automatic grid probing with G29 and output of probe points all at once for easy input into python scripts.

forward kinematics calculation to convert A,B,C lengths into X,Y,Z position.

Software endstops based on max A,B,C lengths as well as min Z (Forward kinematics critical for this to work).
machinofacture
 
Posts: 20
Joined: Tue Jun 17, 2014 12:02 am

Re: GUS_Marlin status

Postby Niggle » Fri Jul 04, 2014 12:13 am

I'd rather add a custom M code to gather calibration points and leave G29 intact to map the actual surface to the imaginary surface calculated by the calibration code.

'Forward kinematics' is trivial to compute. The issue is when and where to output the values.

I haven't looked at the software endstop code. However, some way of limiting movement would be a good thing. Maximum extension on two arms with short extension on the third will let the third arm flop about and that should be preventable. However, it will be simpler and less of a compute burden to block the Cartesian coordinates. [ Given [0,0,0] in the center of the bed, x*x + y*y must be less than the constant PRINTABLE_RADIUS_SQUARED. Two multiply ops, one add and a comparison. No forward kinematics and no painful sqrt(). ]
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: GUS_Marlin status

Postby machinofacture » Sat Jul 05, 2014 6:28 am

You think calculating two squares at all times is less of a burden than just keeping track of the arm extension? The firmware already does this. The only time you need forward kinematics is whenever you actually hit the end stop, so that you can know where you are in cartesian space. Only calculated once, when you are recovering from an endstop hit.
machinofacture
 
Posts: 20
Joined: Tue Jun 17, 2014 12:02 am

Re: GUS_Marlin status

Postby Niggle » Sat Jul 05, 2014 1:23 pm

You lost me, or I lost you.

My concept is to ignore any move command that would take the hot end outside the printable envelope. Simply tracking maximum arm extension doesn't do this. Since my goal is to be able to block ANY move, EVERY move needs to be checked which requires that the code be as cheap as possible.

What do you expect the software endstop code to check and when do you expect the check to be made?
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: GUS_Marlin status

Postby machinofacture » Mon Jul 07, 2014 8:34 am

Hm yes you are right.

I was thinking of the hardware endstops.

Could we just use a software endstop only on Z, and hardware endstops elsewhere? That's pretty much what I was saying. I don't see any down side to this.
machinofacture
 
Posts: 20
Joined: Tue Jun 17, 2014 12:02 am

Re: GUS_Marlin status

Postby Niggle » Mon Jul 07, 2014 3:21 pm

I don't think we need software endstops for z.
I think that we need hardware endstops and I've misplace the FSR I got to experiment with. Going up, we are limited by the endstops on the arms. Going down we are limited by the bed (and I want to implement X,Y software endstops to ensure that we stay over the bed).
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: GUS_Marlin status

Postby machinofacture » Mon Jul 07, 2014 11:43 pm

Alright that makes sense then :)

If the bed is the right sort of triangular shape with curved sides then the hardware endstops should prevent the head from leaving the bed.

I would be happy if you implement forward kinematics so the bot knows where it is when it hits the hardware endstops.
machinofacture
 
Posts: 20
Joined: Tue Jun 17, 2014 12:02 am

Re: GUS_Marlin status

Postby Niggle » Tue Jul 08, 2014 11:33 pm

I disagree. It is possible to push the hotend off the bed without hitting any endstops. I mentioned this before as my reason for supporting software endstops.

I continue to be puzzled by your desire for forward kinematics. It can be done, but how would you use the information? I can conceive of various convoluted schemes to auto calibrate and to compensate for bed levelling issues, but I can also conceive of simpler schemes once we have a functional and accurate z-probe.

In keeping with Nicholas' design goals, I believe that a z-probe and the appropriate firmware would let the machine be fully self calibrating. At which point, the spherical geometry and coordinate system would be completely hidden from the user.
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: GUS_Marlin status

Postby machinofacture » Wed Jul 09, 2014 12:15 am

ok whatever maybe I am just being dumb here.

Here is why I want it:

When the bot hits the hardware endstops, this could happen in the middle of a move. That means the current X,Y,Z location at the point of hitting the endstop is not known, since when you give an X,Y,Z move the bot right away converts that to an A,B,C target coordinate and approaches it linearly. This is why it has to segmentize on the fly. So at any given point you know the next X,Y,Z target and the current A,B,C, and when you hit an endstop you need to find out what the current X,Y,Z position is.

The same thing happens if you probe the bed using a switch.
machinofacture
 
Posts: 20
Joined: Tue Jun 17, 2014 12:02 am

Next

Return to GUS Simpson

Who is online

Users browsing this forum: No registered users and 1 guest

cron