subject:"\[Emc\-users\] More on XYAY configuration"

Re: [Emc-users] More on XYAY configuration

2017-08-26 Thread Jon Elson


On 08/26/2017 03:48 PM, Eric H. Johnson wrote:

Jon,

After doing piecewise refinement of encoder counts per engineering unit, I 
finally managed a reasonable tuning. There still remains a slight bit of hum 
that I do not get at higher resolutions, but the motor runs plenty cool so it 
is definitely usable.

I would note that I started with Thornton's method using ff1 and ff2, which 
basically worked on the other three axes. I could not get it to work on the 
rotary axis, so went back to using I and D.

After doing this however (and possibly other config changes I have made along 
the way), I am getting persistent following errors.

At the moment they always occur at head lifts / drops, when X and Y have 
basically come to a stop. Head lifts are performed by an air cylinder and give 
the system a bit of a jerk. Mostly I am now getting following errors in X and A.
Well, anything that adds a jerk to the system will affect 
the encoder reading.  So, you may have to just raise the value
of MIN_FERROR until it doesn't trip the following error any 
more.

I cannot reproduce this with individual MDI moves, for example. I set the 
following errors in the config absurdly high, but does not seem to have any 
effect.
Note that FERROR is a multiplier on velocity that is added 
to the MIN_FERROR.  MIN_FERROR is the allowable error when 
standing still. So, that is the one you want to adjust.


Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] More on XYAY configuration

2017-08-26 Thread Eric H. Johnson

Phillip, et al,

Turns out, I don't think it has to do with the ferror settings. The head is 
pneumatic, so I am using M64 and M65 for head up and down. The last thing I did 
before going home was to disable the head up / down output. When I run that 
way, the following errors go away entirely. There is still a dwell, so the axes 
have time to come to a complete stop, just as if the head were going up and 
down.

The head is relatively heavy and does shake the gantry when it goes up and 
down, particularly down. But I am using this same technique on other machines 
without an issue. This head is larger and heavier than on any other machine, 
however.

But again, looking at the joints ferror when the head is going up and down is 
still trivially small, a couple hundredths at most.

Regards,
Eric


On August 26, 2017 5:20:47 PM EDT, Philipp Burch  wrote:
>Hi Eric!
>
>On 26.08.2017 22:48, Eric H. Johnson wrote:
>> Jon,
>> 
>> ...
>> 
>> After doing this however (and possibly other config changes I have
>made along the way), I am getting persistent following errors.
>> 
>> At the moment they always occur at head lifts / drops, when X and Y
>have basically come to a stop. Head lifts are performed by an air
>cylinder and give the system a bit of a jerk. Mostly I am now getting
>following errors in X and A.
>> 
>> I cannot reproduce this with individual MDI moves, for example. I set
>the following errors in the config absurdly high, but does not seem to
>have any effect. Watching the joint ferrors with halmeter or halscope
>shows these ferrors to rarely exceed 0.01". My positional accuracy is
>quite good too, hitting end points within 0.001 or 0.002 at worst.
>> 
>
>As far as I remember, there are two kinds of following error tolerance.
>One is the velocity-dependent tolerance FERROR and then there's the
>static MIN_FERROR, which is used when a joint is in position (or moving
>very slowly). In case you did only extend the former, that would not
>have changed anything for the described problem when the joints are not
>moving.
>
>Bye,
>Philipp
>
>> Regards,
>> Eric
>> 
>> On August 26, 2017 3:15:02 PM EDT, Jon Elson 
>wrote:
>>> On 08/26/2017 12:39 PM, Eric H. Johnson wrote:
 Andy,

 Yes, as TYPE = ANGULAR in the joint section.

 As for P,  yes that would seem to agree with what I am seeing.

 I made some headway by starting at 24000 counts per degree (actual
>>> counts per revolution). Tuned that in, then did the same at 1000,
>500,
>>> 250 and 125. Still struggling at 66.. Can get it to run slowly,
>but
>>> goes unstable at speed and sometimes when nearing the end point.


>>> Yes, the problem with the PID is that when the scale value 
>>> going in is very low, the jumps in the user units when the 
>>> encoder or step count changes by one is much larger.  Since 
>>> position is quantized by either step count or encoder 
>>> counts, there isn't a whole lot you can do about this.  The 
>>> best is to set the FF1 as closely as you possibly can with P 
>>> and D very low, use FF2 (with real servos only) in tiny 
>>> increments to help with acceleration, and then raise P until 
>>> the error is acceptable.  D should be at the minimum you can 
>>> live with, as increasing D just amplifies the encoder count 
>>> jumps.
>>>
>>> Some systems have velocity estimation that tries to smooth 
>>> out the velocity jumps caused by this.  If you are NOT using 
>>> velocity estimation where it is available, I think you will 
>>> find it helpful.
>>>
>>> Jon
>>>
>>>
>--
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Emc-users mailing list
>>> Emc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] More on XYAY configuration

2017-08-26 Thread Philipp Burch

Hi Eric!

On 26.08.2017 22:48, Eric H. Johnson wrote:
> Jon,
> 
> ...
> 
> After doing this however (and possibly other config changes I have made along 
> the way), I am getting persistent following errors.
> 
> At the moment they always occur at head lifts / drops, when X and Y have 
> basically come to a stop. Head lifts are performed by an air cylinder and 
> give the system a bit of a jerk. Mostly I am now getting following errors in 
> X and A.
> 
> I cannot reproduce this with individual MDI moves, for example. I set the 
> following errors in the config absurdly high, but does not seem to have any 
> effect. Watching the joint ferrors with halmeter or halscope shows these 
> ferrors to rarely exceed 0.01". My positional accuracy is quite good too, 
> hitting end points within 0.001 or 0.002 at worst.
> 

As far as I remember, there are two kinds of following error tolerance.
One is the velocity-dependent tolerance FERROR and then there's the
static MIN_FERROR, which is used when a joint is in position (or moving
very slowly). In case you did only extend the former, that would not
have changed anything for the described problem when the joints are not
moving.

Bye,
Philipp

> Regards,
> Eric
> 
> On August 26, 2017 3:15:02 PM EDT, Jon Elson  wrote:
>> On 08/26/2017 12:39 PM, Eric H. Johnson wrote:
>>> Andy,
>>>
>>> Yes, as TYPE = ANGULAR in the joint section.
>>>
>>> As for P,  yes that would seem to agree with what I am seeing.
>>>
>>> I made some headway by starting at 24000 counts per degree (actual
>> counts per revolution). Tuned that in, then did the same at 1000, 500,
>> 250 and 125. Still struggling at 66.. Can get it to run slowly, but
>> goes unstable at speed and sometimes when nearing the end point.
>>>
>>>
>> Yes, the problem with the PID is that when the scale value 
>> going in is very low, the jumps in the user units when the 
>> encoder or step count changes by one is much larger.  Since 
>> position is quantized by either step count or encoder 
>> counts, there isn't a whole lot you can do about this.  The 
>> best is to set the FF1 as closely as you possibly can with P 
>> and D very low, use FF2 (with real servos only) in tiny 
>> increments to help with acceleration, and then raise P until 
>> the error is acceptable.  D should be at the minimum you can 
>> live with, as increasing D just amplifies the encoder count 
>> jumps.
>>
>> Some systems have velocity estimation that tries to smooth 
>> out the velocity jumps caused by this.  If you are NOT using 
>> velocity estimation where it is available, I think you will 
>> find it helpful.
>>
>> Jon
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
> 



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] More on XYAY configuration

2017-08-26 Thread Eric H. Johnson

Jon,

After doing piecewise refinement of encoder counts per engineering unit, I 
finally managed a reasonable tuning. There still remains a slight bit of hum 
that I do not get at higher resolutions, but the motor runs plenty cool so it 
is definitely usable.

I would note that I started with Thornton's method using ff1 and ff2, which 
basically worked on the other three axes. I could not get it to work on the 
rotary axis, so went back to using I and D. 

After doing this however (and possibly other config changes I have made along 
the way), I am getting persistent following errors.

At the moment they always occur at head lifts / drops, when X and Y have 
basically come to a stop. Head lifts are performed by an air cylinder and give 
the system a bit of a jerk. Mostly I am now getting following errors in X and A.

I cannot reproduce this with individual MDI moves, for example. I set the 
following errors in the config absurdly high, but does not seem to have any 
effect. Watching the joint ferrors with halmeter or halscope shows these 
ferrors to rarely exceed 0.01". My positional accuracy is quite good too, 
hitting end points within 0.001 or 0.002 at worst.

Regards,
Eric

On August 26, 2017 3:15:02 PM EDT, Jon Elson  wrote:
>On 08/26/2017 12:39 PM, Eric H. Johnson wrote:
>> Andy,
>>
>> Yes, as TYPE = ANGULAR in the joint section.
>>
>> As for P,  yes that would seem to agree with what I am seeing.
>>
>> I made some headway by starting at 24000 counts per degree (actual
>counts per revolution). Tuned that in, then did the same at 1000, 500,
>250 and 125. Still struggling at 66.. Can get it to run slowly, but
>goes unstable at speed and sometimes when nearing the end point.
>>
>>
>Yes, the problem with the PID is that when the scale value 
>going in is very low, the jumps in the user units when the 
>encoder or step count changes by one is much larger.  Since 
>position is quantized by either step count or encoder 
>counts, there isn't a whole lot you can do about this.  The 
>best is to set the FF1 as closely as you possibly can with P 
>and D very low, use FF2 (with real servos only) in tiny 
>increments to help with acceleration, and then raise P until 
>the error is acceptable.  D should be at the minimum you can 
>live with, as increasing D just amplifies the encoder count 
>jumps.
>
>Some systems have velocity estimation that tries to smooth 
>out the velocity jumps caused by this.  If you are NOT using 
>velocity estimation where it is available, I think you will 
>find it helpful.
>
>Jon
>
>--
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>___
>Emc-users mailing list
>Emc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-users

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] More on XYAY configuration

2017-08-26 Thread Jon Elson


On 08/26/2017 12:39 PM, Eric H. Johnson wrote:

Andy,

Yes, as TYPE = ANGULAR in the joint section.

As for P,  yes that would seem to agree with what I am seeing.

I made some headway by starting at 24000 counts per degree (actual counts per 
revolution). Tuned that in, then did the same at 1000, 500, 250 and 125. Still 
struggling at 66.. Can get it to run slowly, but goes unstable at speed and 
sometimes when nearing the end point.


Yes, the problem with the PID is that when the scale value 
going in is very low, the jumps in the user units when the 
encoder or step count changes by one is much larger.  Since 
position is quantized by either step count or encoder 
counts, there isn't a whole lot you can do about this.  The 
best is to set the FF1 as closely as you possibly can with P 
and D very low, use FF2 (with real servos only) in tiny 
increments to help with acceleration, and then raise P until 
the error is acceptable.  D should be at the minimum you can 
live with, as increasing D just amplifies the encoder count 
jumps.


Some systems have velocity estimation that tries to smooth 
out the velocity jumps caused by this.  If you are NOT using 
velocity estimation where it is available, I think you will 
find it helpful.


Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] More on XYAY configuration

2017-08-26 Thread Eric H. Johnson

Andy,

Yes, as TYPE = ANGULAR in the joint section.

As for P,  yes that would seem to agree with what I am seeing.

I made some headway by starting at 24000 counts per degree (actual counts per 
revolution). Tuned that in, then did the same at 1000, 500, 250 and 125. Still 
struggling at 66.. Can get it to run slowly, but goes unstable at speed and 
sometimes when nearing the end point.

The other problem I encountered is that when I transferred the settings from 
the test configuration (All axes independant) to the production configuration 
(Y1 and Y2 joined), the tuning for the rotary axis changed.

I copied the Axis and Joint sections, so assume there must be a difference 
somewhere else, but have not found it.

One other problem I am seeing is very occasional following errors in Y1 (joint 
1) and Y2 (joint 3). Note: the rotary axis disabled in these cases. This only 
happens while running a gcode file, I have not been able to reproduce it on 
individual MDI moves for example. I set ferror for those joints way up to 10", 
but monitoring joint.n.ferror with halmeter or halscope, I never see ferror 
exceeding about 0.01".

Regards,
Eric

On August 26, 2017 12:17:11 PM EDT, Andy Pugh  wrote:
>
>
>> On 25 Aug 2017, at 18:47, Eric H. Johnson 
>wrote:
>> 
>> Any idea what is going on here?
>
>Is A defined as rotary in the INI?
>
>Changing units will change P gain, it is volts per engineering unit of
>position error. 
>--
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>___
>Emc-users mailing list
>Emc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-users

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] More on XYAY configuration

2017-08-26 Thread Andy Pugh



> On 25 Aug 2017, at 18:47, Eric H. Johnson  wrote:
> 
> Any idea what is going on here?

Is A defined as rotary in the INI?

Changing units will change P gain, it is volts per engineering unit of position 
error. 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] More on XYAY configuration

2017-08-25 Thread Eric H. Johnson


After playing with a lot of the tuning parameters, I changed the engineering 
unit from degrees to revolutions. There are 24,000 counts per revolution or 
66.6 per degree.

If I use 24000 as the counts per revolution, then the problem goes away. 
However without teleop (test configuration) using 66.6 counts per degree 
works just fine.

The other thing I found was that I have to drop P way down to work at degrees, 
when I thought the PIDs should remain the same regardless of resolution.

For 24000 counts per revolution, I found P of about 7.5 to work best, while at 
66. counts per degree, I had to drop P to about 0.030. This holds true for 
both the test and gantry configurations.

Any idea what is going on here?

Thanks,
Eric


On August 25, 2017 11:25:38 AM EDT, "Eric H. Johnson"  
wrote:
>All,
>
>More info. The problem only seems to affect the A axis. I can do MDI
>moves to both X and Y without issue.
>
>I did notice that when I do an MDI move of A, the Y axis moves ever so
>slightly when the following error occurs, then lurches upon doing a
>machine on. A simple amplifier off will not cause Y to move.
>
>I do not see how tuning parameters for A are affecting Y.
>
>Thanks,
>Eric
>
>
>On August 25, 2017 9:13:54 AM EDT, "Eric H. Johnson"
> wrote:
>>All,
>>
>>Again with XYAY configuration under Lcnc  2.8.0-pre1. I have two
>>configurations, a checkout configuration that does not team Y1 and Y2,
>>and the production configuration which does.
>>
>>In the checkout configuration, an MDI move such as:
>>G1 a360 f5000
>>
>>Works fine.
>>
>>Transferring all the tuning and related parameters to the production
>>configuration results in a following error on joint 2 (A). This occurs
>>at the end of the move regardless of distance. Further, following it
>>with a "machine on" results in a slight lurch on Y. Cannot tell at
>this
>>point if it is one or both of the Y axes.
>>
>>The A axis does not home so all of the applicable home related values
>>are set to zero. The "home all" works and ignores A.
>>
>>Any idea what is causing the following errors in the production
>config?
>>
>>Thanks,
>>Eric
>>
>>-- 
>>Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>--
>>Check out the vibrant tech community on one of the world's most
>>engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>___
>>Emc-users mailing list
>>Emc-users@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/emc-users
>
>-- 
>Sent from my Android device with K-9 Mail. Please excuse my brevity.
>--
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>___
>Emc-users mailing list
>Emc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-users

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] More on XYAY configuration

2017-08-25 Thread Eric H. Johnson

All,

More info. The problem only seems to affect the A axis. I can do MDI moves to 
both X and Y without issue.

I did notice that when I do an MDI move of A, the Y axis moves ever so slightly 
when the following error occurs, then lurches upon doing a machine on. A simple 
amplifier off will not cause Y to move.

I do not see how tuning parameters for A are affecting Y.

Thanks,
Eric


On August 25, 2017 9:13:54 AM EDT, "Eric H. Johnson"  
wrote:
>All,
>
>Again with XYAY configuration under Lcnc  2.8.0-pre1. I have two
>configurations, a checkout configuration that does not team Y1 and Y2,
>and the production configuration which does.
>
>In the checkout configuration, an MDI move such as:
>G1 a360 f5000
>
>Works fine.
>
>Transferring all the tuning and related parameters to the production
>configuration results in a following error on joint 2 (A). This occurs
>at the end of the move regardless of distance. Further, following it
>with a "machine on" results in a slight lurch on Y. Cannot tell at this
>point if it is one or both of the Y axes.
>
>The A axis does not home so all of the applicable home related values
>are set to zero. The "home all" works and ignores A.
>
>Any idea what is causing the following errors in the production config?
>
>Thanks,
>Eric
>
>-- 
>Sent from my Android device with K-9 Mail. Please excuse my brevity.
>--
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>___
>Emc-users mailing list
>Emc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-users

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] More on XYAY configuration

2017-08-25 Thread Eric H. Johnson

All,

Again with XYAY configuration under Lcnc  2.8.0-pre1. I have two 
configurations, a checkout configuration that does not team Y1 and Y2, and the 
production configuration which does.

In the checkout configuration, an MDI move such as:
G1 a360 f5000

Works fine.

Transferring all the tuning and related parameters to the production 
configuration results in a following error on joint 2 (A). This occurs at the 
end of the move regardless of distance. Further, following it with a "machine 
on" results in a slight lurch on Y. Cannot tell at this point if it is one or 
both of the Y axes.

The A axis does not home so all of the applicable home related values are set 
to zero. The "home all" works and ignores A.

Any idea what is causing the following errors in the production config?

Thanks,
Eric

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] More on XYAY configuration

Re: [Emc-users] More on XYAY configuration

Re: [Emc-users] More on XYAY configuration

Re: [Emc-users] More on XYAY configuration

Re: [Emc-users] More on XYAY configuration

Re: [Emc-users] More on XYAY configuration

Re: [Emc-users] More on XYAY configuration

Re: [Emc-users] More on XYAY configuration

Re: [Emc-users] More on XYAY configuration

[Emc-users] More on XYAY configuration

10 matches

Site Navigation

Mail list logo

Footer information