Lineardeltakins joint offset

[jean-paul moniz]

Ok,

I'm breaking this off into a separate thread.

Looks like We have to change the way we think about these offset pins. either that or I'm not understanding something.

Currently with the code I have.

The offset pins will offset each joint when in Coord however there seems to be a bug that I am looking in to.

It seems that if you switch between joint and world the offset will continue to add from each transition  Joint > world meaning:

1. setp lineardeltakins.J0off 0
2. Home machine in joint
3. J0 = 0.00 J1= 0.00 J2= 0.00
4. Switch to world
5. X = 0.000 Y = 0.000 Z = 0.00
6. Switch to joint
7. J0 = 0.00 J1= 0.00 J2= 0.00
8. setp lineardeltakins.J0off 1
9. Switch to world
10. X = 0.000 Y = 2.000 Z = 0.00
11. Switch to joint
12. J0 = 1.00 J1= 0.00 J2= 0.00
13. Switch to world
14. X = 0.000 Y = 4.000 Z = 0.00
15. Switch to joint
16. J0 = 2.00 J1= 0.00 J2= 0.00

Keeps incrementing every switch by the value of the offset.

Thinking we need an enable input or just handle it in hal.

JP

 

[Bas de Bruijn]

On 10 Jan 2015, at 21:07, jean-paul moniz <jmo...@pmiautomation.com> wrote:

Keeps incrementing every switch by the value of the offset.

first thought is: do you not need to reverse the offsets in the kinematics inverse? But i’d have to read up what’s exactly happening.

https://github.com/jpmoniz/machinekit/blob/a8172d9950ca781008104006df6494c82ad271c0/src/emc/kinematics/lineardeltakins-common.h#L70

[jean-paul moniz]

I tried that already.  Looks like you apply the offset and then write the offset to zero after a switch from World > joint seems to work. Anything else just causes repeating additions or subtractions. 

[Bas de Bruijn]

ok

the only thing you want to do is move a certain amount (your offset) of the joint position. Because when you calibrate with the nozzle at a tower position you want to be at heigh 0.1 mm, but if you can easily move your finger under the nozzle you’re obviously not at z=0.1 mm. You want to change the offset, without it influencing the xyz coordinate.

what you do here is something I would expect.

But what I’d also expect is that the offsets should be added here also. Like:

joints[0] = z + sqrt(L2 - sq(Ax-x) - sq(Ay-y)) + J0off; joints[1] = z + sqrt(L2 - sq(Bx-x) - sq(By-y)) + J1off; joints[2] = z + sqrt(L2 - sq(Cx-x) - sq(Cy-y)) + J2off;

if you do that, then I would expect that if you’d set J0off to 1, then joint[0] would move 1 mm, but the xyz value does not change. Because the cartesian coordinate is determined at the time when you home with your HOME_OFFSET for the [AXIS_n]

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at http://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[jean-paul moniz]

Tried that but still got the same behavior.  This is what i had.

Enter code here...  
 joints[0] = (z + sqrt(L2 - sq(Ax-x) - sq(Ay-y))) - J0off;

 joints[1] = (z + sqrt(L2 - sq(Bx-x) - sq(By-y))) - J1off;

 joints[2] = (z + sqrt(L2 - sq(Cx-x) - sq(Cy-y))) - J2off;

[Charles Steinkuehler]

On 1/10/2015 3:30 PM, jean-paul moniz wrote:
> Tried that but still got the same behavior. This is what i had.
>
> Enter code here...
> joints[0] = (z + sqrt(L2 - sq(Ax-x) - sq(Ay-y))) - J0off;
> joints[1] = (z + sqrt(L2 - sq(Bx-x) - sq(By-y))) - J1off;
> joints[2] = (z + sqrt(L2 - sq(Cx-x) - sq(Cy-y))) - J2off;

I think your problem is you need to apply or not apply the offset based
on whether or not you're homing the joint.

If you just apply a fixed offset all the time, it will "disappear" as
soon as you execute a homing operation.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Bas de Bruijn]

Its strange, I’ve been trying to find in the code what actually happens when you switch from world to joint mode and vice versa. But can’t find it.

you gave:

1. setp lineardeltakins.J0off 0
2. Home machine in joint
3. J0 = 0.00 J1= 0.00 J2= 0.00
4. Switch to world
5. X = 0.000 Y = 0.000 Z = 0.00
6. Switch to joint
7. J0 = 0.00 J1= 0.00 J2= 0.00
8. setp lineardeltakins.J0off 1
9. Switch to world
10. X = 0.000 Y = 2.000 Z = 0.00
11. Switch to joint
12. J0 = 1.00 J1= 0.00 J2= 0.00
13. Switch to world
14. X = 0.000 Y = 4.000 Z = 0.00
15. Switch to joint
16. J0 = 2.00 J1= 0.00 J2= 0.00

I don’t think you actually home at all (don’t give the command to home) so the thing is only happening when switching from joint -> world

see [8], [10] and [12]. that makes sense, I’d expect J0 to be 1.00

so, some dumb duck-shooting, because I really have no idea what happens when you switch between the modes. And I still think that both the calculations should take the offsets into account.

inverse:

joints[0] = z + sqrt(L2 - sq(Ax-x) - sq(Ay-y)) + J0off;

forward:

double q1 = joints[0] - J0off;

have you tried homing directly after you change one of the offset values?

what happens then?

are you able to modify J0off, J1off and J2off and _see_ the carriage moving without influencing X, Y and Z coordinates in the screen, and without switching modes?

did you do other modifications in other parts of the code other then kinematics that might interfere?

What do you do here?

--
Charles Steinkuehler
cha...@steinkuehler.net

[jean-paul moniz]

No I was not homing. Just simply switching back and forth from joint to world.  I'm starting to think kinematics is the wrong place to be fudging with joints like this.  It makes more sense to me just to mess about with the homing code. Could this same approach not be applied to the homing code and just create a hal pin in there? 

inverse:

joints[0] = z + sqrt(L2 - sq(Ax-x) - sq(Ay-y)) + J0off;

forward:

double q1 = joints[0] - J0off;

have you tried homing directly after you change one of the offset values?
what happens then?

Zeros out the joints as per INI settings.  I'm testing in sim enviro right now  one I get it to a point I will test on the printer. 

are you able to modify J0off, J1off and J2off and _see_ the carriage moving without influencing X, Y and Z coordinates in the screen, and without switching modes?

did you do other modifications in other parts of the code other then kinematics that might interfere?
What do you do here?

Nothing as of yet just working through the Kinematics right now.

[Bas de Bruijn]

> On 11 Jan 2015, at 00:15, jean-paul moniz <jmo...@pmiautomation.com> wrote:
>
> No I was not homing. Just simply switching back and forth from joint to world. I'm starting to think kinematics is the wrong place to be fudging with joints like this. It makes more sense to me just to mess about with the homing code.

Might, but what's wrong with our logic? I think this is a good place, and if the switching of modes? Or the sim is the culprit?

We define the geometry here in the kinematics. I'll pull your modifications tomorrow and will try on my printer. No sim, real thing.

Bas

[jmo...@pmiautomation.com]

Just tried it on my printer. Works fine for me. Guess it was something funny with the sim config.

FYI. I am adding on the inverse and subtracting on the forward. Really doesn't matter as long as they are inverted.

So here is where were at. A joint offset can be applied while running with the lineardeltakins.J#off. Pin. With one downside. I'm questioning what accelerations and velocities are being applied to the offset. Really we are writing directly to the joint. I say this as I am getting following errors when setting the hal pins to large values (10mm). Of course that's probably 10x larger than we intend to apply but it brought this to light.

Second issue is that offsetting in world is useless. The offset needs to be applied in joint. However if you apply an offset while in joint it does not cause motion. Feeling like it has to do with not in telop mode. 

So round and round we go.

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message  
From: Bas de Bruijn
Sent: Saturday, January 10, 2015 6:25 PM
To: jean-paul moniz
Cc: machi...@googlegroups.com; cha...@steinkuehler.net; jmo...@pmiautomation.com
Subject: Re: [Machinekit] Lineardeltakins joint offset

[Bas de Bruijn]

On 11 Jan 2015, at 07:34, jmo...@pmiautomation.com wrote:

Just tried it on my printer. Works fine for me. Guess it was something funny with the sim config.

FYI. I am adding on the inverse and subtracting on the forward. Really doesn't matter as long as they are inverted.

So here is where were at. A joint offset can be applied while running with the lineardeltakins.J#off. Pin. With one downside. I'm questioning what accelerations and velocities are being applied to the offset.

they are the same as “normal” the stepgen_max_vel and stepgen_max_acc

Really we are writing directly to the joint. I say this as I am getting following errors when setting the hal pins to large values (10mm). Of course that's probably 10x larger than we intend to apply but it brought this to light.

that’s the same for changing the delta radius with a big value. When youre calibrating manually you’d change in steps of 0.1 mm, paper test, lower 0.1 mm, paper test, etc.

when you change the J0off from 0 to 10, and say the joint[0] is at 800, then suddenly it should be at 810, that error is too big and you’d get the joint following error.

Second issue is that offsetting in world is useless.

yes, that’s where you can use G-command for that, I’d go to Z=3 and do G92 Z0 if for example I want to print on a 3mm mirror glass that I put on the bed.

The offset needs to be applied in joint. However if you apply an offset while in joint it does not cause motion. Feeling like it has to do with not in telop mode. 

i don’t know about the modes, but when calibrating you (meaning myself) don’t care about the joints-mode. So I’d stay in world and just calibrate the printer, and when calibrated go print.

[Michael Haberler]

> Am 11.01.2015 um 00:15 schrieb jean-paul moniz <jmo...@pmiautomation.com>:
>
>
>
> On Saturday, January 10, 2015 at 6:00:28 PM UTC-5, Bas de Bruijn wrote:
>
> On 10 Jan 2015, at 22:41, Charles Steinkuehler <cha...@steinkuehler.net> wrote:
>
>> On 1/10/2015 3:30 PM, jean-paul moniz wrote:
>>> Tried that but still got the same behavior. This is what i had.
>>>
>>> Enter code here...
>>> joints[0] = (z + sqrt(L2 - sq(Ax-x) - sq(Ay-y))) - J0off;
>>> joints[1] = (z + sqrt(L2 - sq(Bx-x) - sq(By-y))) - J1off;
>>> joints[2] = (z + sqrt(L2 - sq(Cx-x) - sq(Cy-y))) - J2off;
>>
>> I think your problem is you need to apply or not apply the offset based
>> on whether or not you're homing the joint.

it IS the wrong place for a _changable_ offset

the reason is - if you fiddle kinematics values mid-flight you will create sudden jumps in position feedback _within the control loop_
in other words, you suddenly create a huge following error, and the loop cannot follow - bang

also: even if the machine is stopped, you need to be super-careful to not create sudden 'position warps' - the code for the mode-switching logic in motion is anything but obvious (see also the thread on modeless motion: https://github.com/machinekit/machinekit/issues/396)



this is the same reason why probekins (http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ProbeKins) is neat, simple and wrong - I just blundered down the wrong path by doing it in kins

if you do offsets, you need to apply them _before_ the movement command enters the control loop and the endpoint of the next move is calculated; once it is, you get into the 'cannot change mid-flight without violating machine constraints' problem

now that said, the current code goes to the other extreme which is to apply all offsets (tool, g5,g92) at the canon layer, that is, as it falls out of the interpreter (https://github.com/machinekit/machinekit/blob/master/src/emc/task/emccanon.cc), which is why an offset cannot be changed while motion is paused (e.g. changing a broken tool and setting new tool offsets)

a more flexible solution would be to have offset correction of any kind at the very moment before the endpoint of a move is calculated (once the move is calculated, fiddling kins is too late and it wont get you anywhere)

if you read the motion code, you'll find that somebody actually passed offset values to motion, but then did nothing with it; an idea which fell into oblivion, but it was the right one

I know this is involved, not easy to understand and a tad disappointing, and I dont have an easy solution for you; sorry about that.


- Michael

[Bas de Bruijn]

On 11 Jan 2015, at 11:02, Michael Haberler <mai...@mah.priv.at> wrote:

Am 11.01.2015 um 00:15 schrieb jean-paul moniz <jmo...@pmiautomation.com>:



On Saturday, January 10, 2015 at 6:00:28 PM UTC-5, Bas de Bruijn wrote:

On 10 Jan 2015, at 22:41, Charles Steinkuehler <cha...@steinkuehler.net> wrote:

On 1/10/2015 3:30 PM, jean-paul moniz wrote:

Tried that but still got the same behavior.  This is what i had.

Enter code here...   
joints[0] = (z + sqrt(L2 - sq(Ax-x) - sq(Ay-y))) - J0off;
joints[1] = (z + sqrt(L2 - sq(Bx-x) - sq(By-y))) - J1off;
joints[2] = (z + sqrt(L2 - sq(Cx-x) - sq(Cy-y))) - J2off;

I think your problem is you need to apply or not apply the offset based
on whether or not you're homing the joint.

it IS the wrong place for a _changable_ offset

I agree, I see them as debugging pins, to find the offset and then set them once and for all (until I modify frame/endswitches) in the INI file.

A concession between working smarter and somebody spending the coming 2 weeks coding.

IMO you’d only need those “debugging pins" when setting up your machine, do the initial calibration (meaning at the level tweaking of the offset switches) finding the values once and correct the HOME_OFFSET in the INI file. I have 3 different HOME_OFFSETS because each endswitch just isn’t exactly at the position it should be due to manufacturing tolerances.

the reason is - if you fiddle kinematics values mid-flight you will create sudden jumps in position feedback _within the control loop_
in other words, you suddenly create a huge following error, and the loop cannot follow - bang

also: even if the machine is stopped, you need to be super-careful to not create sudden 'position warps' - the code for the mode-switching logic in motion is anything but obvious (see also the thread on modeless motion:https://github.com/machinekit/machinekit/issues/396)

I think the original thread (several, not this one) was about being able to set the HOME_OFFSET values at another points then only when loading the INI file. Now you must close machinekit, change the ini-values and run again to get them loaded correctly. When calibrating a delta printer this _can_ be cumbersome.

https://groups.google.com/forum/#!topic/machinekit/R1uzcWMmnvE

https://groups.google.com/forum/#!topic/machinekit/PDmftDoqaGQ

https://groups.google.com/forum/#!topic/machinekit/O2FZO2ySrmI

[jmo...@pmiautomation.com]

Actually I have it working and making sense now.

The pin should Be set in joint mode only. Setting the pin in joint does not cause motion and creates the rotation of the axis required.

This is looking very useful now.

Sent from my BlackBerry 10 smartphone on the Rogers network.

From: Bas de Bruijn Sent: Sunday, January 11, 2015 4:52 AM To: jmo...@pmiautomation.com Cc: machi...@googlegroups.com; cha...@steinkuehler.net

[Charles Steinkuehler]

On 1/11/2015 12:34 AM, jmo...@pmiautomation.com wrote:
> Just tried it on my printer. Works fine for me. Guess it was
> something funny with the sim config.
>
> FYI. I am adding on the inverse and subtracting on the forward.
> Really doesn't matter as long as they are inverted.
>
> So here is where were at. A joint offset can be applied while running
> with the lineardeltakins.J#off. Pin. With one downside. I'm
> questioning what accelerations and velocities are being applied to
> the offset. Really we are writing directly to the joint. I say this
> as I am getting following errors when setting the hal pins to large
> values (10mm). Of course that's probably 10x larger than we intend to
> apply but it brought this to light.
>
> Second issue is that offsetting in world is useless. The offset needs
> to be applied in joint. However if you apply an offset while in joint
> it does not cause motion. Feeling like it has to do with not in telop
> mode.
>
> So round and round we go.

I took a look at the homing code, and I think the functionality
necessary to assist with auto-calibration can be added by a very simple
patch. The joint structures are statically allocated in shared memory
and near as I can tell the only thing that ever sets the home_offset for
a joint is the EMCMOT_SET_HOMING_PARAMS command, which probably looks
like it gets run exactly once when the Axis GUI loads.

A chunk of shared memory used internally by a HAL process (motion) is
pretty much the definition of a HAL parameter, so it's possible to
simply give HAL the existing address of the joints->home_offset values
and _presto_ they're now changeable HAL parameters.

The patch is super simple. I've verified it builds, but I can't test
until I get my system with home switches reconnected (it's currently in
pieces from my last road-trip). Anyway, I pushed a branch I think will
give you editable home offsets. The proposed usage method is:

1) Launch linuxcnc
2) Home axis
3) Test axis homing as needed
4) Adjust HAL parameter "axis.N.home_offset" as required
5) Return to #2 if home_offset changed
6) Store updated home_offset in the INI file

The change is in my home_offset branch on github, here's the massive
commit summary:

https://github.com/cdsteinkuehler/linuxcnc/compare/home_offset?expand=1

I'll try to get my machine up and running soon so I can test. Until
then, no guarantees this won't totally blow up! :)

...but at least it launches and runs:

debian@beaglebone:~/machinekit/src$ halcmd show param axis
Parameters:
Owner Type Dir Value Name
90 float RW 1 axis.0.home_offset
90 float RW 2 axis.1.home_offset
90 float RW 3 axis.2.home_offset
90 float RW 0 axis.3.home_offset

If this works for you (and Michael promises not to shoot me!), I'll
clean it up a bit and send a PR to the Machinekit repo (the old joints
struct needs to be removed to avoid wasting memory).

--
Charles Steinkuehler
cha...@steinkuehler.net

[andy pugh]

On 11 January 2015 at 10:02, Michael Haberler <mai...@mah.priv.at> wrote:
> the reason is - if you fiddle kinematics values mid-flight you will create sudden jumps in position feedback _within the control loop_
> in other words, you suddenly create a huge following error, and the loop cannot follow - bang

If the offset was applied via a limit3 then it would be OK.

It seems to me that in some ways it "belongs" in kinematics because it
is part of the machine geometry description. I see homing as something
entirely different related to finding a repeatable but arbitrary
location for the actuator.

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Bas de Bruijn]

I just compiled your branch and I see the following behaviour.

My initial home_offset for joint[0] in my INI file is 711.1

We're in joint mode when I home (startup unhomed machine).

- press the “home” button with joint[n] selected

- the joint[0] shows 711.1 after homing

- other joints are also properly homed

in the terminal i do:

- halcmd axis.0.home_offset 720

- I press the home button (I only home joint[0])

- the carriage goes up, triggers the endswitch

- i see “720.0” flash by in the screen

- immediately the carriage travels down to the position 711.1

I did not expect that.

Bas

[jmo...@pmiautomation.com]

Bas,

Can you try the hal pins I added to the kins?   For me they work fine. Rule of thumb is to only set the pins when in joint.

JP

Sent from my BlackBerry 10 smartphone on the Rogers network.

From: Bas de Bruijn Sent: Sunday, January 11, 2015 4:56 PM To: Charles Steinkuehler Cc: machi...@googlegroups.com

Subject: Re: [Machinekit] Lineardeltakins joint offset

You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/5bjHTzH5HRo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.

[Charles Steinkuehler]

[resent to list]

Thanks for testing (I'm about half-way through putting my delta with
end-stops back together). I wouldn't have expected that behavior
either, but then nothing with the legacy code is ever easy. That's why
I tend to stay down in HAL/RTAPI/driver land where things are *mostly*
sane, and at least I don't have to deal with NML. ;-)

I'll dig around a bit and see if I can spot what's going on.

...some testing with a config w/o home switches exhibits odd behavior
(instead of simply zeroing the axis positions, the axis actually _move_
by the home_offset amount). I think there is definitely something
strange going on, and I'm going to side with Michael in saying that most
of this stuff should get nuked from orbit (just to be sure), and
re-worked in a post NML environment with multiple sources for motion
commands.

The kinematics hack seems to work well enough the HAL parameter for
home_offset isn't required in the short term, I just thought it might be
easy to implement. Shows what I get for thinking. :-)

--
Charles Steinkuehler
cha...@steinkuehler.net

[andy pugh]

On 12 January 2015 at 00:53, Charles Steinkuehler

<cha...@steinkuehler.net> wrote:
> That's why
> I tend to stay down in HAL/RTAPI/driver land where things are *mostly*
> sane, and at least I don't have to deal with NML. ;-)

Partly why I suggested kins rather (despite the f-error issue) for
this. I have almost no idea about what us going on above the RT
cutoff.

[jmo...@pmiautomation.com]

The f-error is not an issue anymore in my mind. When I was playing with it last night 2AM‎. My mind was not thinking well. There is no logical need to adjust the offset while in world. So what I suspect I will do is just create an Mcode that switches to joint and apply the offset then signal the user to re-home the machine. When applying the offset in joint mode, motion is not allowed for some reason (my guess is something to do with telop). Applying the offset in joint is not an issue as you have to be in joint anyways to home. After homing again the probing can be repeated to confirm.

JP

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message  

From: andy pugh
Sent: Sunday, January 11, 2015 8:31 PM
To: Charles Steinkuehler
Cc: Machinekit Mailing List

Subject: Re: [Machinekit] Lineardeltakins joint offset

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---

You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/5bjHTzH5HRo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.

[Bas de Bruijn]

Hi,

I think for a efficient way of calibrating we’d need both JP's and Chatles’ solution. (Only talking about manual calibration, let’s keep it simple for now)

@Charles,

I have the feeling (while you made the HAL pins you mentioned something of memory use cleanup) that there is still some legacy stuff (old way). Could that not be the source of the move? because the move to the “old” offset (INI file value) seems to be in a commanded motion. No f-error despite the big change in value. So perhaps it’s still being commanded to go to the old_copy-value of the INI file.

@JP

I will try to test your branch tonight (europe, morning while I write this).

I think the f-error issue is still there, because when I calibrate, I go to the tower position in world mode. go down to the bed in small steps. I’d do that with the “debugpins” lineardeltakins.J0off

@Andy,

I think about it this way: we need to be able to find the switch distance error (all cumulated error of the position during build and manufacturing). I’d use JP’s kinematics pins for this + charles’ method of changing the home_offset value.

• find all 3 offset values (or 2 actually because the first one sets the pace, it’s the reference the second 2 should refer to).
• adjust the delta radius in the same way.
• when done, we know everything.
• calculate the correct tower height (ini value + the J0off value),
• set axis.0.home_offset with the resulting value from above
• set J0off to zero again
• change the INI values in the .ini file
• re-home the machine

all without having to switch off the machine multiple times.

Bas

On 12 Jan 2015, at 02:43, jmo...@pmiautomation.com wrote:

The f-error is not an issue anymore in my mind. When I was playing with it last night 2AM‎. My mind was not thinking well. There is no logical need to adjust the offset while in world. So what I suspect I will do is just create an Mcode that switches to joint and apply the offset then signal the user to re-home the machine. When applying the offset in joint mode, motion is not allowed for some reason (my guess is something to do with telop). Applying the offset in joint is not an issue as you have to be in joint anyways to home. After homing again the probing can be repeated to confirm.

JP

[Charles Steinkuehler]

On 1/12/2015 12:35 AM, Bas de Bruijn wrote:
> Hi, I think for a efficient way of calibrating we’d need both JP's

> and Charles’ solution. (Only talking about manual calibration, let’s

> keep it simple for now)
>
> @Charles, I have the feeling (while you made the HAL pins you
> mentioned something of memory use cleanup) that there is still some
> legacy stuff (old way). Could that not be the source of the move?
> because the move to the “old” offset (INI file value) seems to be in
> a commanded motion. No f-error despite the big change in value. So
> perhaps it’s still being commanded to go to the old_copy-value of the
> INI file.

Someone needs to test this change on a system with homing switches to
see if it works as expected. If so, I can easily clean up the code and
send a PR. I was confused by the move after homing, but it actually
should move if HOME != HOME_OFFSET, even on my machine w/o switches.

I'll try and get my Kossel that I use for testing the gantry code and
homing back together soon so I can verify here.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Bas de Bruijn]

> On 12 Jan 2015, at 13:15, Charles Steinkuehler <cha...@steinkuehler.net> wrote:
>
>> On 1/12/2015 12:35 AM, Bas de Bruijn wrote:
>> Hi, I think for a efficient way of calibrating we’d need both JP's
>> and Charles’ solution. (Only talking about manual calibration, let’s
>> keep it simple for now)
>>
>> @Charles, I have the feeling (while you made the HAL pins you
>> mentioned something of memory use cleanup) that there is still some
>> legacy stuff (old way). Could that not be the source of the move?
>> because the move to the “old” offset (INI file value) seems to be in
>> a commanded motion. No f-error despite the big change in value. So
>> perhaps it’s still being commanded to go to the old_copy-value of the
>> INI file.
>
> Someone needs to test this change on a system with homing switches to
> see if it works as expected. If so, I can easily clean up the code and
> send a PR. I was confused by the move after homing, but it actually
> should move if HOME != HOME_OFFSET, even on my machine w/o switches.

Yes of course. I hadn't thought about HOME and so I didn't change HOME.
I ran on a physical machine with physical home switches yesterday evening FWIW.

Bas

>
> I'll try and get my Kossel that I use for testing the gantry code and
> homing back together soon so I can verify here.
>
> --
> Charles Steinkuehler
> cha...@steinkuehler.net
>

[Viesturs Lācis]

On Sunday, January 11, 2015 at 11:56:09 PM UTC+2, Bas de Bruijn wrote:

in the terminal i do:

- halcmd axis.0.home_offset 720

- I press the home button (I only home joint[0])

- the carriage goes up, triggers the endswitch

- i see “720.0” flash by in the screen

- immediately the carriage travels down to the position 711.1

I did not expect that.

That is totally ok and should be expected. Home_offset is location of home switch in joint coordinates, home is position, where joint moves at home_final_vel after it has homed. I am sure that initially home and home_offset were the same in your INI file, so it did not go anywhere. Now that they are different, joint will go to its home position, just like it always would do.

[Viesturs Lācis]

On Monday, January 12, 2015 at 2:40:47 PM UTC+2, Bas de Bruijn wrote:

> On 12 Jan 2015, at 13:15, Charles Steinkuehler <cha...@steinkuehler.net> wrote:
>
>> On 1/12/2015 12:35 AM, Bas de Bruijn wrote:
>> Hi, I think for a efficient way of calibrating we’d need both JP's
>> and Charles’ solution. (Only talking about manual calibration, let’s
>> keep it simple for now)
>>
>> @Charles, I have the feeling (while you made the HAL pins you
>> mentioned something of memory use cleanup) that there is still some
>> legacy stuff (old way). Could that not be the source of the move?
>> because the move to the “old” offset (INI file value) seems to be in
>> a commanded motion. No f-error despite the big change in value. So
>> perhaps it’s still being commanded to go to the old_copy-value of the
>> INI file.
>
> Someone needs to test this change on a system with homing switches to
> see if it works as expected.  If so, I can easily clean up the code and
> send a PR.  I was confused by the move after homing, but it actually
> should move if HOME != HOME_OFFSET, even on my machine w/o switches.

Yes of course. I hadn't thought about HOME and so I didn't change HOME.
I ran on a physical machine with physical home switches yesterday evening FWIW.

Damn, I should read the whole thread before posting. The question had already been answered...

[Charles Steinkuehler]

This should probably become an issue on github at some point...

On 1/12/2015 6:40 AM, Bas de Bruijn wrote:
>
>> On 12 Jan 2015, at 13:15, Charles Steinkuehler <cha...@steinkuehler.net> wrote:
>>
>>> On 1/12/2015 12:35 AM, Bas de Bruijn wrote:
>>> Hi, I think for a efficient way of calibrating we’d need both JP's
>>> and Charles’ solution. (Only talking about manual calibration, let’s
>>> keep it simple for now)
>>>
>>> @Charles, I have the feeling (while you made the HAL pins you
>>> mentioned something of memory use cleanup) that there is still some
>>> legacy stuff (old way). Could that not be the source of the move?
>>> because the move to the “old” offset (INI file value) seems to be in
>>> a commanded motion. No f-error despite the big change in value. So
>>> perhaps it’s still being commanded to go to the old_copy-value of the
>>> INI file.
>>
>> Someone needs to test this change on a system with homing switches to
>> see if it works as expected. If so, I can easily clean up the code and
>> send a PR. I was confused by the move after homing, but it actually
>> should move if HOME != HOME_OFFSET, even on my machine w/o switches.
>
> Yes of course. I hadn't thought about HOME and so I didn't change HOME.
> I ran on a physical machine with physical home switches yesterday evening FWIW.

So if this is working, the question is:

Should I export any other joint parameters while messing with the code?

https://github.com/cdsteinkuehler/linuxcnc/blob/home_offset/src/emc/motion/motion.c#L1009-L1056

...I think it might make sense to export:

joint->max_pos_limit = 1.0;
joint->min_pos_limit = -1.0;
joint->vel_limit = 1.0;
joint->acc_limit = 1.0;
joint->min_ferror = 0.01;
joint->max_ferror = 1.0;
joint->home = 0.0;
joint->backlash = 0.0;

...and it might make sense to export:

joint->home_search_vel = 0.0;
joint->home_latch_vel = 0.0;
joint->home_final_vel = -1;
joint->home_offset = 0.0;
joint->home_sequence = -1;

...anything else is probably asking for trouble.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Bas de Bruijn]

On 12 Jan 2015, at 15:31, Charles Steinkuehler <cha...@steinkuehler.net> wrote:

> This should probably become an issue on github at some point…

I’ve taken the latest and put it in the comments on https://github.com/machinekit/machinekit/issues/423

[Charles Steinkuehler]

TL;DR
Exporting HOME and HOME_OFFSET to HAL appears safe and seems to work as
expected. Other exported values do not work properly or have little
need to be changed dynamically.

On 1/12/2015 8:31 AM, Charles Steinkuehler wrote:
>
> So if this is working, the question is:
>
> Should I export any other joint parameters while messing with the code?

I've gone ahead and cleaned up the code and added a few more exported
values. The summary of what's changed can be found at the same link:

https://github.com/cdsteinkuehler/linuxcnc/blob/home_offset/src/emc/motion/motion.c#L1009-L1056

These are exported, and appear to be safe and working as expected:

joint->home = 0.0;
joint->home_offset = 0.0;

These look safe to export, but don't seem to work as expected when
changed via HAL:

joint->vel_limit = 1.0;
joint->acc_limit = 1.0;

These values don't look safe to export w/o fiddling with the
"new_config" logic in taskintf.cc:

joint->max_pos_limit = 1.0;
joint->min_pos_limit = -1.0;

joint->min_ferror = 0.01;
joint->max_ferror = 1.0;

joint->backlash = 0.0;

...and these don't seem like they really need to be exported:

joint->home_search_vel = 0.0;
joint->home_latch_vel = 0.0;
joint->home_final_vel = -1;

joint->home_sequence = -1;

Please test if you can!

Warning: The change to the emcmot_debug_t removing the deprecated
joints array requires a full rebuild. The dependency files don't seem
to properly rebuild everything that relies on the mot_priv.h file.

Sorry. :(

PR sent and pending build results.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Daren Schwenke]

FWIW, the relevant variables from the marlin delta firmware with auto calibration and bed leveling contain the following, all floats:

3 endstop adjustments (separate from home_offset, which is static)

6 variables representing variations in tower geometry and will compensate for skew.

delta radius (starting value is static until calibration)

delta diagonal rod (in there, but I don't think it changes)

max_position (don't know what these do yet)

3 z_probe_offset variables to account for positioning of the probe

[Daren Schwenke]

3 max_position variables that is..

[Daren Schwenke]

When calibrating, when I used the calibrated delta_radius as my radius to create my three outer points for re-calibrating, I noticed that my connecting rods for the axis being calibrated were perfectly vertical.  

Is this an anomaly of my particular delta build, or a result of the math?

[Charles Steinkuehler]

On 1/12/2015 5:54 PM, Daren Schwenke wrote:
> When calibrating, when I used the calibrated delta_radius as my radius to
> create my three outer points for re-calibrating, I noticed that my
> connecting rods for the axis being calibrated were perfectly vertical.
> Is this an anomaly of my particular delta build, or a result of the math?

Assuming your delta radius is correct, it's a result of the math.

If your effector is in the middle of the bed (X=0, Y=0), the delta
radius is the "horizontal" distance covered by the diagonal rods (or
more specifically, the distance in the XY plane between the pivot point
on the effector and the pivot point on the carriage for the delta arms,
all of which _should_ be the same length).

If you move the effector from the middle of the bed directly towards one
of the towers by the delta radius distance, the close tower's rods
_should_ be *EXACTLY* vertical by definition. If they are not, you have
an error in your calibration values or your build.

--
Charles Steinkuehler
cha...@steinkuehler.net

[jean-paul moniz]

Ok So this is what I have come up with so far. 

I decided to embed a Glade tab in axis to allow users to read their  INI home parameters. I'm showing all but may just show the relevant parameters in regards to delta calibration. I am able to read the INI settings and set the parameters if a user changes the values.

Things I don't have working an need direction on.

1.Writing the INI file.

                  I had this working standalone (before embedding in axis)  Once I embedded it in axis upon the first write of the INI something gets corrupted in the INI and cannot restart after closing the current session. Here is a pastebin of the save handler 

http://pastebin.com/JznmGqpm

2. Read/Write Hal pins and system parameters/named parameters from python.  Is this possible or is there some sort of hand off required. 

On Saturday, January 10, 2015 at 3:07:33 PM UTC-5, jean-paul moniz wrote:

Ok,

I'm breaking this off into a separate thread.

Looks like We have to change the way we think about these offset pins. either that or I'm not understanding something.

Currently with the code I have.

The offset pins will offset each joint when in Coord however there seems to be a bug that I am looking in to.

It seems that if you switch between joint and world the offset will continue to add from each transition  Joint > world meaning:

1. setp lineardeltakins.J0off 0
2. Home machine in joint
3. J0 = 0.00 J1= 0.00 J2= 0.00
4. Switch to world
5. X = 0.000 Y = 0.000 Z = 0.00
6. Switch to joint
7. J0 = 0.00 J1= 0.00 J2= 0.00
8. setp lineardeltakins.J0off 1
9. Switch to world
10. X = 0.000 Y = 2.000 Z = 0.00
11. Switch to joint
12. J0 = 1.00 J1= 0.00 J2= 0.00
13. Switch to world
14. X = 0.000 Y = 4.000 Z = 0.00
15. Switch to joint
16. J0 = 2.00 J1= 0.00 J2= 0.00

Keeps incrementing every switch by the value of the offset.

Thinking we need an enable input or just handle it in hal.

JP