Re: [Emc-developers] 2.7.15 PID Fix

[Gene Heskett]

On Wednesday 04 March 2020 12:52:09 andy pugh wrote:

> On Wed, 4 Mar 2020 at 17:26, Peter C. Wallace  wrote:
> > It was first added to 2.8 and them merged into 2.7 before the
> > 2.7.15 release AFAIK
>
> I think that they were added in 2010:
> https://github.com/LinuxCNC/linuxcnc/commit/44586b831e1ef5e826003190ab
>317cda76b6e8e3#diff-912d11dfa52738be509f63e4ff1922a4 (And that commit
> also includes documentation of the pins)

Sort of. But it does provide some hints as to how to utilize it to 
improve control, If you have encoder feedback on axis axis then you 
could feed the feedback.deriv pin with the velocity of that axis's 
encoder. But from reading that, I fail to deduct a source for cmd.deriv. 
I am envisioning a differential, for instance between current command 
and previous command or maybe a sum2 with one input set for a gain of -1 
and an rc lag from the command input to the other input giving a 
differential output according to the charge across the cap. Since we 
don't have a cap in hal components, we'ed have to use a low pass.  But I 
quickly run out of imagination as to the rc time constant to synthesize.

just discussing the howto's would I think be educational for those of us 
who never got the transcendental stuff in school 70+ years ago.

Help?

Thanks

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.7.15 PID Fix

[Jon Elson]

On 03/04/2020 02:14 PM, andy pugh wrote:

On Wed, 4 Mar 2020 at 18:07, Peter C. Wallace  wrote:

I meant the patch that made the command derivative behavior match the

feedback
derivative behavior (and the manual), that was quite recent.


Ah, sorry. I thought you were explaining the statement that the pins are
not in the docs.
( Which appears not to actually be true:
http://linuxcnc.org/docs/2.7/html/man/man9/pid.9.html )




It took me a while to find where you got this link from :

http://linuxcnc.org/docs/2.7/html/man/man9/pid.9.html

But, in the same html tree, there is :
http://linuxcnc.org/docs/2.7/html/hal/rtcomps.html#_pid
Which has fewer pins.  These should be harmonized.


Jon


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] [Emc-users] Open source CNC architecture

[Robert Murphy]

It's a shame you think there are "parallel port zealots". The parallel
port is just one of the interfaces that linuxcnc supports. Still a quite
viable as an entry level interface or a "quick & dirty" one. A lot of us
have gone with the various motion cards from MESA.

And Murphy', Lawno that's an ancient law thought up by the Bards &
Druids of old. Twas used to describe a particularly bad battle of the
clan Murchadh against the Danes. I would take this with a dram of whisky
as it may or may not be true*.*

A modified Slackware build script to produce a Slackware-type package
was really helpful when building a LFS & BLFS system.

On 5/3/20 5:00 am, Rafael Skodlar wrote:

On 2020-02-19 00:11, Robert Murphy wrote:


On 19/2/20 5:47 pm, Rafael Skodlar wrote:

On 2020-02-17 04:49, Les Newell wrote:



  One issue jumps to mind that is different.  The tiny shop I have
doesn't have room for a Keyboard, Mouse and Display by the lathe.  I
currently have a nice work triangle set up for the lathe toolbench
and tool cabinet.  It would require a lot of work to change that at
a cost of space lost somewhere else.


Monitor on the wall behind the lathe? Support arm bolted to the wall
for the keyboard? If you wanted these things you'd make room. As you
don't want them you won't make the room. I'm not saying that's a bad
thing. We just have different requirements.


. snip


/opt/linuxcnc-v2.8/bin
/opt/linuxcnc-v2.8/etc
/opt/linuxcnc-v2.8/lib
/opt/linuxcnc-v2.8/man
/opt/linuxcnc-v2.8/log

Latest release would be:
/opt/linuxcnc -> link to /opt/linuxcnc-v2.8.
Your path to LinuxCNC binaries or scripts would always be
/opt/linuxcnc/bin etc.



Dunno why you are calling that the "Slackware Method" and I've been
running a 24/7 Slackware server for years. Never in all my years I have
seen that method used in Slackware or mentioned in the docs. Actually I
can't recall any official Slackware packages installing into /opt and
linking as you say. Have you used Slackware ?


That's the first one I used. Before Yggdrasil, Redhat, Mandrake,
Xandros, and Debian.

Don't take everything so literally. I was just giving an example for
files locations. Ubuntu uses /srv a lot. Put application wherever you
want, /usr/local for what I care. What I wanted to point out is
simplicity in managing multiple versions of some application or service.

https://www.slackbook.org/html/package-management.html
"Packages are built to be extracted in the root directory" which makes
it easier to put them under chrooted directory.

"Apparently many people in the Linux community think that a packager
manager must by definition include dependency checking. Well, that
simply isn't the case, as Slackware most certainly does not."

that means it won't mess with other packages (dependencies) as many
_standard package utilities_ do. Sometimes that's good, other times
it's not.

You obviously did not read this:
http://www.slackware.com/config/packages.php
"Slackware's packaging system uses ordinary compressed tar files."
and that's what I was reffering to. Read the docs before you tell
somebody else !!!



Puppy Linux and Salix use a "Plug in" file system for apps. But usually
a squashfs file system that can be loaded on boot.

If you read the Linuxcnc docs you'd be aware of a Run In Place install.
Which is the recommended method before a full upgrade.

I'm beginning to think you don't know too much about Linuxcnc and are
trying a push it something that suits your needs or business model.


Is that a Murphy law? I'm glad to see you know everything and how
things should be. I observe trends in the industry and point them out
to parallel port zealots. Opening discussion for software architecture
is not automatic _business model_.

As a sysadmin I've seen volumes of good and bad software that's hard
to maintain or fix in some cases. I'm not saying LinuxCNC is this or
that. It's great what people have done with it so far. A lot of work
is ahead since Python 2.7 reached it's end of life.

Since you know so much, tell me what's going on here:
file emc2-dev/src/emc/motion/teleop-notes has a reference to
http://jmkasunich.com/pics/emc2-motion-dataflow.pdf

How many more such things are there?

Now go learn about hard and soft links, PATH, and chroot in Unix.


Why not do your own crowd funding, fork Linuxcnc and pay for someone to
break it up and rearrange it to suit your needs.


That's because I don't have more money than you do.



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.7.15 PID Fix

[andy pugh]

On Wed, 4 Mar 2020 at 18:07, Peter C. Wallace  wrote:

I meant the patch that made the command derivative behavior match the
> feedback
> derivative behavior (and the manual), that was quite recent.
>

Ah, sorry. I thought you were explaining the statement that the pins are
not in the docs.
( Which appears not to actually be true:
http://linuxcnc.org/docs/2.7/html/man/man9/pid.9.html )


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.7.15 PID Fix

[Peter C. Wallace]

On Wed, 4 Mar 2020, andy pugh wrote:


Date: Wed, 4 Mar 2020 17:52:09 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On Wed, 4 Mar 2020 at 17:26, Peter C. Wallace  wrote:



It was first added to 2.8 and them merged into 2.7 before the

2> 2.7.15 release AFAIK

I think that they were added in 2010:
https://github.com/LinuxCNC/linuxcnc/commit/44586b831e1ef5e826003190ab317cda76b6e8e3#diff-912d11dfa52738be509f63e4ff1922a4
(And that commit also includes documentation of the pins)


I meant the patch that made the command derivative behavior match the feedback 
derivative behavior (and the manual), that was quite recent.




--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
?? George Fitch, Atlanta Constitution Newspaper, 1912


Peter Wallace
Mesa Electronics
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.7.15 PID Fix

[andy pugh]

On Wed, 4 Mar 2020 at 17:26, Peter C. Wallace  wrote:

> It was first added to 2.8 and them merged into 2.7 before the
> 2.7.15 release AFAIK

I think that they were added in 2010:
https://github.com/LinuxCNC/linuxcnc/commit/44586b831e1ef5e826003190ab317cda76b6e8e3#diff-912d11dfa52738be509f63e4ff1922a4
(And that commit also includes documentation of the pins)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.7.15 PID Fix

[Peter C. Wallace]

On Wed, 4 Mar 2020, andy pugh wrote:


Date: Wed, 4 Mar 2020 17:20:02 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On Wed, 4 Mar 2020 at 16:55, Peter C. Wallace  wrote:



> As for the docs, the generic 2.7 docs do NOT show any reference to
> pid.x.command-deriv
> Am I looking in the wrong place, or has it been removed?

It was added early in 2.8 and it works the same as feedback-deriv
(value calculated internally if unconnected)


I don't think that is right, as the problem we are seeing is with
2.7.15 systems.


It was first added to 2.8 and them merged into 2.7 before the
2.7.15 release AFAIK

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.7.15 PID Fix

[andy pugh]

On Wed, 4 Mar 2020 at 16:55, Peter C. Wallace  wrote:

> > As for the docs, the generic 2.7 docs do NOT show any reference to
> > pid.x.command-deriv
> > Am I looking in the wrong place, or has it been removed?
>
> It was added early in 2.8 and it works the same as feedback-deriv
> (value calculated internally if unconnected)

I don't think that is right, as the problem we are seeing is with
2.7.15 systems.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.7.15 PID Fix

[Peter C. Wallace]

On Wed, 4 Mar 2020, Jon Elson wrote:


Date: Wed, 04 Mar 2020 10:44:26 -0600
From: Jon Elson 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On 03/03/2020 09:22 PM, Peter C. Wallace wrote:


No, command-deriv is only used for the FF1 feedforward calculation

But, I DO use FF1 in practically all my configs, and it does seem to work.


It will work because if the command-deriv pin is not connected the derivative 
will be calculated internally


So, the problem is linking a signal to the command-deriv pin, but then NOT 
feeding it the correct derivative.  I can't see any way to fix this in PID.
The new 2.7.15 PID is not wrong, it just exposes an error in other code (the 
configs) that hadn't been right for

some time.


I guess without linking to command-deriv then PID calculates this internally 
by difference between this command and
the most recent command.  If you link a signal to command-deriv but do not 
provide the correct value, PID

would misbehave for sure.


Yes, you will get a 0 FF1 PID term



Not clear what to do in this case, but fixing the broken configs and the 
autoconfig program that creates these
seems important.  Documenting the problem is critical, and explaining what 
the user needs to do to

make his system run right.




As for the docs, the generic 2.7 docs do NOT show any reference to 
pid.x.command-deriv

Am I looking in the wrong place, or has it been removed?


It was added early in 2.8 and it works the same as feedback-deriv
(value calculated internally if unconnected)




Jon


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Pico Systems ppmc driver does not show up in some locations of the docs

[Jon Elson]

Mostly to John T.,

I note that there is an entry in the docs under "Hardware 
Drivers" for "Pico Drivers", but no entries under
"HAL component List" where other drivers are listed.  I 
guess it really only needs one line to
list that the PPMC driver supports the PPMC (analog servo 
interface), Universal PWM Controller and
Universal Stepper Controller.  It might also be good to have 
a note in this section that more detailed

info is available one level up in "Hardware Drivers".

Jon


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.7.15 PID Fix

[Jon Elson]

On 03/03/2020 09:22 PM, Peter C. Wallace wrote:


No, command-deriv is only used for the FF1 feedforward 
calculation
But, I DO use FF1 in practically all my configs, and it does 
seem to work.  So, the problem is linking a signal to the 
command-deriv pin, but then NOT feeding it the correct 
derivative.  I can't see any way to fix this in PID.
The new 2.7.15 PID is not wrong, it just exposes an error in 
other code (the configs) that hadn't been right for

some time.
I guess without linking to command-deriv then PID calculates 
this internally by difference between this command and
the most recent command.  If you link a signal to 
command-deriv but do not provide the correct value, PID

would misbehave for sure.

Not clear what to do in this case, but fixing the broken 
configs and the autoconfig program that creates these
seems important.  Documenting the problem is critical, and 
explaining what the user needs to do to

make his system run right.

As for the docs, the generic 2.7 docs do NOT show any 
reference to pid.x.command-deriv

Am I looking in the wrong place, or has it been removed?

Jon


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] translate linuxcnc documentation into Chinese

[0x fff]

Gene Heskett
Thank you very much, I have a rpi4, and will try it,

Gene Heskett  于2020年3月3日周二 下午10:46写道：

> On Tuesday 03 March 2020 08:35:14 0x fff wrote:
>
> > cool, So LinuxCNC can also run on Raspberry Pi 4?
> >
> Yes, I've been doing it for several months. Before that, an rpi3b for
> about 3 years.
>
> click on the link in my sig, then add "lathe-stf" to the address  bar and
> hit return, then click on "linuxcnc4rpi4". There  you will find a README
> that should tell you how to install the preempt-rt kernel thats also
> there, and the debs for LinuxCNC, a sample jpeg screenshot showing what
> it looks like on my screen, and the config that runs a cnc converted
> Sheldon 11x54 lathe here. I started out with an rpi3b for about 3 years
> but it was a wee bit overworked, but the rpi4b only has to be pushed to
> 800 MHz to do it very well. Because the interface card I used had gpio
> to throw away, quite a bit of control gingerbread has been added, like a
> pair of 100 ppr hand dials replacing the original hand cranks, and all
> the lathes power is controlled by LinuxCNC, so when I walk away it draws
> about 15 watts. Since LCNC is a better compound that a real one, there
> isn't one on the lathe. Bed wear on a 70 yo machine has been measured
> and compensated for by LinuxCNC, and for rigid tapping, the turn around
> overshoot at the bottom of a hole is measured and displayed so you can
> cut air for a reading, then substract that in your code, thereby
> stopping short of running into the bottom of a hole and breaking a $30
> tap off in the hole, and that not only costs money but takes a day to
> remove the broken tap (w/o damaging the threads) with an EDM setup.
>
> My upload bandwidth is slow, but be me  guest.
>
> > Bari  于2020年3月3日周二 下午3:41写道：
> >
> > > Hello,
> > >
> > > I spent some time in China setting up a new business to make 3D
> > > printers and other CNC machines. We actually had LinuxCNC running on
> > > the Cubieboard2 and Cubieboard4
> > > https://en.wikipedia.org/wiki/Cubieboard back in 2014.
> > >
> > > On 3/2/20 8:07 AM, 0x fff wrote:
> > > > hello, everyone.
> > > >  I am a newcomer from China
> > > >  I am very interested in this project, I now plan to translate
> > > > its documentation into Chinese, I will start with "getting
> > > > started" If I encounter difficulties in the translation process,
> > > > hope to get everyone's help
> > > >
> > > > ___
> > > > Emc-developers mailing list
> > > > Emc-developers@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> > >
> > > ___
> > > Emc-developers mailing list
> > > Emc-developers@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Runtests

[Gene Heskett]

On Wednesday 04 March 2020 04:42:06 andy pugh wrote:

> On Wed, 4 Mar 2020 at 01:30, Gene Heskett  wrote:
> > I am too, wondering why you are watching kern.log. when far more
> > data is output to syslog.
>
> Because kern.log is where the RTAPI logging data ends up when using
> RTAI. (tail-ing kern.log is equivalent to continually polling dmesg)

I wasn't aware of that, thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Runtests

[andy pugh]

On Wed, 4 Mar 2020 at 01:30, Gene Heskett  wrote:

> I am too, wondering why you are watching kern.log. when far more data is
> output to syslog.

Because kern.log is where the RTAPI logging data ends up when using RTAI.
(tail-ing kern.log is equivalent to continually polling dmesg)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers