Re: [Emc-developers] Arc Bug, help needed.

[Greg C]

FWIW the preview works here on a Virtual Machine, homed in place with g2 as
the first move, G20 or G21.

12th Gen Intel(R) Core(TM) i7-12700KF

-Greg

On Wed, Dec 7, 2022 at 6:43 PM Peter C. Wallace  wrote:

> On Wed, 7 Dec 2022, andy pugh wrote:
>
> > Date: Wed, 7 Dec 2022 21:54:41 +
> > From: andy pugh 
> > Reply-To: EMC developers 
> > To: EMC developers 
> > Subject: Re: [Emc-developers] Arc Bug, help needed.
> >
> >> On Wed, 7 Dec 2022 at 20:36, John Thornton  wrote:
> >>
> >> I can confirm the bug is in the 2.9 branch that is currently in Debian,
> >> I'm unable to build a RIP on 2.9 to see if it's still there as I get
>
>
> >metric or imperial config?
> >Did you run the test command in G20 or G21?
> >NO_FORCE_HOMING?
> >
> >What CPU are you running? (It is getting to the point that I am wondering
> >if that matters)
>
>
> I have no issue with G20 or G21 with current master
>
> (with g2 x0 y0 j5 z-2 f1000 as the first linuxCNC motion at startup)
>
> of course X,Y must be 0 at the start
>
> Peter Wallace
>
>
> ___
> 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] Bug#1025433: Copyright issue

[andy pugh]

On Thu, 8 Dec 2022 at 00:42, Adam Ant  wrote:

>
> The correct course of action is to ask Paolo Mantegazza rather than
> debating symantics.
> You can not just pull substantial chunks of code from one source and then
> claim that you wrote it.
>

But Paulo didn't write it _either_

If you go back in time to 2003:
https://github.com/LinuxCNC/linuxcnc/blob/07bc1e161f834d8b192fe279819261294e5fe150/src/rtapi/procfs_macros.h
and compare that to a 1999 version of the RTAI file, the only line in
common is "#include "

At some point _both_ files included a chunk of work from Erwin Rol:

// proc print macros - Contributed by: Erwin Rol (er...@muffin.org)

_Most_ of both files was written by Erwin Rol. But both files existed
previously, and separately, as far as I can tell looking back in both
archives.

-- 
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
#ifndef PROCFS_MACROS_H
#define PROCFS_MACROS_H
/***
*PROC_FS MACROS*
/
#ifdef CONFIG_PROC_FS
#include 

/* proc print macros - Contributed by: Erwin Rol (er...@muffin.org)
   and shamelessly ripped from rtai_proc_fs.h, part of the RTAI
   project.  See http://www.rtai.org for more details.

   macro that holds the local variables that
   we use in the PROC_PRINT_* macros. We have
   this macro so we can add variables with out
   changing the users of this macro, of course
   only when the names don't colide!
*/

#define PROC_PRINT_VARS \
off_t pos = 0;  \
off_t begin = 0;\
int len = 0 /* no ";" */

/* macro that prints in the procfs read buffer.
   this macro expects the function arguments to be
   named as follows.
   static int FOO(char *page, char **start,
off_t off, int count, int *eof, void *data)  */

#define PROC_PRINT(fmt,args...) \
len += sprintf(page + len , fmt, ##args);   \
pos += len; \
if(pos < off) { \
len = 0;\
begin = pos;\
}   \
if(pos > off + count)   \
goto done;

/* macro to leave the read function from another
   place than at the end.   */
#define PROC_PRINT_RETURN  \
*eof = 1;  \
goto done   // no ";"

/* macro that should only used once at the end of the
   read function, to return from another place in the
   read function use the PROC_PRINT_RETURN macro.   */
#define PROC_PRINT_DONE \
*eof = 1;   \
done:   \
*start = page + (off - begin);  \
len -= (off - begin);   \
if(len > count) \
len = count;\
if(len < 0) \
len = 0;\
return len  // no ";"

#endif /* PROC_FS */
#endif /* PROCFS_MACROS_H */


rtai_proc_fs.h_RTAI_1999
Description: Binary data
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Arc Bug, help needed.

[Peter C. Wallace]

On Wed, 7 Dec 2022, andy pugh wrote:


Date: Wed, 7 Dec 2022 21:54:41 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] Arc Bug, help needed.


On Wed, 7 Dec 2022 at 20:36, John Thornton  wrote:

I can confirm the bug is in the 2.9 branch that is currently in Debian,
I'm unable to build a RIP on 2.9 to see if it's still there as I get




metric or imperial config?
Did you run the test command in G20 or G21?
NO_FORCE_HOMING?

What CPU are you running? (It is getting to the point that I am wondering
if that matters)



I have no issue with G20 or G21 with current master

(with g2 x0 y0 j5 z-2 f1000 as the first linuxCNC motion at startup)

of course X,Y must be 0 at the start

Peter Wallace


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

Re: [Emc-developers] Arc Bug, help needed.

[John Thornton]

Turned out I needed to install libpython3.11-dev on debian 12

JT

On 12/7/2022 3:52 PM, John Thornton wrote:

dpkg-checkbuilddeps returns nothing so they are satisfied

I attached the config.log

On 12/7/2022 2:37 PM, Sebastian Kuzminsky wrote:

On 12/7/22 13:31, John Thornton wrote:
I can confirm the bug is in the 2.9 branch that is currently in 
Debian, I'm unable to build a RIP on 2.9 to see if it's still there 
as I get configure errors I don't understand how to fix.


configure error could not link test program to Python... Maybe the 
main Python library has been installed in some non-standard library 
path.


Python 3 came installed with Debian 12...


Do you have all the 2.9 build dependencies installed?  Check with:

$ debian/configure
$ dpkg-checkbuilddeps

(Per the instructions here: 
 
.)






___
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] Arc Bug, help needed.

[John Thornton]

Looks like the Axis sim defaults to G20, I think the Axis sim does not 
have NO_FORCE_HOMING in the ini.


AMD Ryzen 5 5600X 6-Core Processor.

Noel on the IRC confirmed the bug in axis but not in qtdragon... then it 
got too cold for him in the shop.


JT

On 12/7/2022 3:54 PM, andy pugh wrote:

On Wed, 7 Dec 2022 at 20:36, John Thornton  wrote:


I can confirm the bug is in the 2.9 branch that is currently in Debian,
I'm unable to build a RIP on 2.9 to see if it's still there as I get


metric or imperial config?
Did you run the test command in G20 or G21?
NO_FORCE_HOMING?

What CPU are you running? (It is getting to the point that I am wondering
if that matters)




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

Re: [Emc-developers] Arc Bug, help needed.

[andy pugh]

On Wed, 7 Dec 2022 at 20:36, John Thornton  wrote:

> I can confirm the bug is in the 2.9 branch that is currently in Debian,
> I'm unable to build a RIP on 2.9 to see if it's still there as I get


metric or imperial config?
Did you run the test command in G20 or G21?
NO_FORCE_HOMING?

What CPU are you running? (It is getting to the point that I am wondering
if that matters)

-- 
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] Arc Bug, help needed.

[John Thornton]

dpkg-checkbuilddeps returns nothing so they are satisfied

I attached the config.log

On 12/7/2022 2:37 PM, Sebastian Kuzminsky wrote:

On 12/7/22 13:31, John Thornton wrote:
I can confirm the bug is in the 2.9 branch that is currently in 
Debian, I'm unable to build a RIP on 2.9 to see if it's still there 
as I get configure errors I don't understand how to fix.


configure error could not link test program to Python... Maybe the 
main Python library has been installed in some non-standard library 
path.


Python 3 came installed with Debian 12...


Do you have all the 2.9 build dependencies installed?  Check with:

$ debian/configure
$ dpkg-checkbuilddeps

(Per the instructions here: 
 
.)


This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by LinuxCNC configure 2.9.0~pre1, which was
generated by GNU Autoconf 2.71.  Invocation command line was

  $ ./configure --disable-build-documentation-translation

## - ##
## Platform. ##
## - ##

hostname = machineshop
uname -m = x86_64
uname -r = 6.0.0-4-rt-amd64
uname -s = Linux
uname -v = #1 SMP PREEMPT_RT Debian 6.0.8-1 (2022-11-11)

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = x86_64
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/john/bin/
PATH: /usr/local/bin/
PATH: /usr/bin/
PATH: /bin/
PATH: /usr/local/games/
PATH: /usr/games/


## --- ##
## Core tests. ##
## --- ##

configure:2837: looking for aux files: config.guess config.sub install-sh
configure:2850:  trying ./
configure:2879:   ./config.guess found
configure:2879:   ./config.sub found
configure:2861:   ./install-sh found
configure:3064: checking for g++
configure:3085: found /usr/bin/g++
configure:3096: result: g++
configure:3123: checking for C++ compiler version
configure:3132: g++ --version >&5
g++ (Debian 12.2.0-9) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3143: $? = 0
configure:3132: g++ -v >&5
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-9' 
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-12 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin 
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-12-lH3g9c/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-lH3g9c/gcc-12-12.2.0/debian/tmp-gcn/usr
 --enable-offload-defaulted --without-cuda-driver --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-9) 
... rest of stderr output deleted ...
configure:3143: $? = 0
configure:3132: g++ -V >&5
g++: error: unrecognized command-line option '-V'
g++: fatal error: no input files
compilation terminated.
configure:3143: $? = 1
configure:3132: g++ -qversion >&5
g++: error: unrecognized command-line option '-qversion'; did you mean 
'--version'?
g++: fatal error: no input files
compilation terminated.
configure:3143: $? = 1
configure:3163: checking whether the C++ compiler works
configure:3185: g++conftest.cpp  >&5
configure:3189: $? = 0
configure:3239: result: yes
configure:3242: checking for C++ compiler default output file name
configure:3244: result: a.out
configure:3250: checking for suffix of executables
configure:3257: g++ -o conftestconftest.cpp  >&5
configure:3261: $? = 0
configure:3284: result: 
configure:3306: checking whether we are cross compiling
configure:3314: g++ -o conftestconftest.cpp  >&5
configure:3318: $? = 0
configure:3325: ./conftest
configure:3329: $? = 0
configure:3344: result: no
configure:3349: checking 

Re: [Emc-developers] Arc Bug, help needed.

[John Thornton]

Thanks Seb, missing a bunch of build dependencies... trying to 
multi-task and make parts at the same time so I get distracted and 
forget the stuff I should know by heart now.


JT

On 12/7/2022 2:37 PM, Sebastian Kuzminsky wrote:

On 12/7/22 13:31, John Thornton wrote:
I can confirm the bug is in the 2.9 branch that is currently in 
Debian, I'm unable to build a RIP on 2.9 to see if it's still there 
as I get configure errors I don't understand how to fix.


configure error could not link test program to Python... Maybe the 
main Python library has been installed in some non-standard library 
path.


Python 3 came installed with Debian 12...


Do you have all the 2.9 build dependencies installed?  Check with:

$ debian/configure
$ dpkg-checkbuilddeps

(Per the instructions here: 
 
.)






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

Re: [Emc-developers] Arc Bug, help needed.

[John Thornton]

Thanks Seb, missing a bunch of build dependencies... trying to 
multi-task and make parts at the same time so I get distracted and 
forget the stuff I should know by heart now.


JT

On 12/7/2022 2:37 PM, Sebastian Kuzminsky wrote:

On 12/7/22 13:31, John Thornton wrote:
I can confirm the bug is in the 2.9 branch that is currently in 
Debian, I'm unable to build a RIP on 2.9 to see if it's still there 
as I get configure errors I don't understand how to fix.


configure error could not link test program to Python... Maybe the 
main Python library has been installed in some non-standard library 
path.


Python 3 came installed with Debian 12...


Do you have all the 2.9 build dependencies installed?  Check with:

$ debian/configure
$ dpkg-checkbuilddeps

(Per the instructions here: 
 
.)






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

Re: [Emc-developers] Arc Bug, help needed.

[Sebastian Kuzminsky]

On 12/7/22 13:31, John Thornton wrote:
I can confirm the bug is in the 2.9 branch that is currently in Debian, 
I'm unable to build a RIP on 2.9 to see if it's still there as I get 
configure errors I don't understand how to fix.


configure error could not link test program to Python... Maybe the main 
Python library has been installed in some non-standard library path.


Python 3 came installed with Debian 12...


Do you have all the 2.9 build dependencies installed?  Check with:

$ debian/configure
$ dpkg-checkbuilddeps

(Per the instructions here: 
 
.)



--
Sebastian Kuzminsky


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

Re: [Emc-developers] Arc Bug, help needed.

[John Thornton]

I can confirm the bug is in the 2.9 branch that is currently in Debian, 
I'm unable to build a RIP on 2.9 to see if it's still there as I get 
configure errors I don't understand how to fix.


configure error could not link test program to Python... Maybe the main 
Python library has been installed in some non-standard library path.


Python 3 came installed with Debian 12...

JT

On 12/7/2022 12:55 PM, John Thornton wrote:
Yes, it shows up in the preview when ran from the MDI, but if I try 
and repeat the move after a G0 Z0 I get the proper arc circle down to 
Z-2.


If I start the Axis sim then release the estop and press power then 
enter G2 X0 Y0 Z-2 F1000 in the MDI only the Z move happens. Then if I 
do Z0 and then repeat the arc move it works as expected so it's 
something to do when LinuxCNC makes the first move.


Back to work for me.

On 12/7/2022 8:38 AM, andy pugh wrote:

On Wed, 7 Dec 2022 at 14:31, John Thornton  wrote:


I can reproduce the problem in 2.9 with an Axis sim, the move shown on
the backport is Z only. I need to connect to a machine to test if the
backport is what happens.


Do you mean "backplot" or "preview"? If it shows up in the preview then
things are even more messed up than I thought.




___
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] Arc Bug, help needed.

[gene heskett]

On 12/7/22 11:19, andy pugh wrote:

On Wed, 7 Dec 2022 at 15:49, gene heskett  wrote:

Which doesn't look like its related to your g2 problem. I do not see a

g2 test by that name.



There isn't a G2 test in the tests.

The test is

"if open axis.

Comand g2 x0 y0 j5 z-2 f1000.

The machine not execution g2 , but only Z-2."

after the tests have been run, I must not have a good environment left, 
all I get is syntax error, line 4 unexpected EOF.  That is running it as 
a script from my command line, which is probably wrong.  Trying to be 
helpful Andy, but probably I'm just list noise. If you can add it to the 
git repo, I'd be willing to re-run the thing with it in a proper form. 
My script starts with a fresh git pull.


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, 1940)
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] Arc Bug, help needed.

[John Thornton]

Yes, it shows up in the preview when ran from the MDI, but if I try and 
repeat the move after a G0 Z0 I get the proper arc circle down to Z-2.


If I start the Axis sim then release the estop and press power then 
enter G2 X0 Y0 Z-2 F1000 in the MDI only the Z move happens. Then if I 
do Z0 and then repeat the arc move it works as expected so it's 
something to do when LinuxCNC makes the first move.


Back to work for me.

On 12/7/2022 8:38 AM, andy pugh wrote:

On Wed, 7 Dec 2022 at 14:31, John Thornton  wrote:


I can reproduce the problem in 2.9 with an Axis sim, the move shown on
the backport is Z only. I need to connect to a machine to test if the
backport is what happens.


Do you mean "backplot" or "preview"? If it shows up in the preview then
things are even more messed up than I thought.




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

Re: [Emc-developers] Arc Bug, help needed.

[Peter C. Wallace]

On Wed, 7 Dec 2022, andy pugh wrote:


Date: Wed, 7 Dec 2022 11:50:09 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] Arc Bug, help needed.

In February I fixed this bug:
https://github.com/LinuxCNC/linuxcnc/issues/1528

But, it seems, I failed to properly consider full-circle spiral arcs, and
the test was wrong.

https://github.com/LinuxCNC/linuxcnc/issues/2169
(Note that this issue report was _not_ raised by the original reporter, 
and furthermore seems to show a _different_ issue.


I investigated and found a test case that I could reproduce, and put in a
fix for that. (linked in the issue report above)

However it is reported that the original bug (that I have never 
reproduced) still exists.


Here is the problem description:

"if open axis.

Comand g2 x0 y0 j5 z-2 f1000.

The machine not execution g2 , but only Z-2."

I think that the system needs to be set up for immediate homing to 0,0,0 
as I have an unconfirmed report that this specific problem does not occur 
if the axes have moved. (But then the test cases that Tom_L shows in the 
bug report has the third arc going wrong too)



I don't get the bug with 2.10, immediate homing, first move after linuxcnc 
loaded or with previous motion either with  MDI or as 2 line ngc:


g2 x0 y0 j5 z-2 f1000
m2

Preview and path are OK


Peter Wallace


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

Re: [Emc-developers] Arc Bug, help needed.

[andy pugh]

On Wed, 7 Dec 2022 at 15:49, gene heskett  wrote:

Which doesn't look like its related to your g2 problem. I do not see a
> g2 test by that name.


There isn't a G2 test in the tests.

The test is

"if open axis.

Comand g2 x0 y0 j5 z-2 f1000.

The machine not execution g2 , but only Z-2."

-- 
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] Arc Bug, help needed.

[gene heskett]

On 12/7/22 09:39, andy pugh wrote:

On Wed, 7 Dec 2022 at 14:31, John Thornton  wrote:


I can reproduce the problem in 2.9 with an Axis sim, the move shown on
the backport is Z only. I need to connect to a machine to test if the
backport is what happens.



Do you mean "backplot" or "preview"? If it shows up in the preview then
things are even more messed up than I thought.


Running runtests on my rpi4b gets this:
Runtest: 248 tests run, 248 successful, 0 failed + 0 expected, 3 skipped

however, way back up the backtrace is this:
*** 
/media/pi/workspace/buster-linuxcnc/tests/interp/m98m99/12-M99-endless-main-program: 
XPASS: Passed, but was expected to fail


Which doesn't look like its related to your g2 problem. I do not see a 
g2 test by that name.


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, 1940)
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] Arc Bug, help needed.

[andy pugh]

On Wed, 7 Dec 2022 at 14:31, John Thornton  wrote:

> I can reproduce the problem in 2.9 with an Axis sim, the move shown on
> the backport is Z only. I need to connect to a machine to test if the
> backport is what happens.


Do you mean "backplot" or "preview"? If it shows up in the preview then
things are even more messed up than I thought.

-- 
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] Arc Bug, help needed.

[John Thornton]

I can reproduce the problem in 2.9 with an Axis sim, the move shown on 
the backport is Z only. I need to connect to a machine to test if the 
backport is what happens.


I'll have to update my local copy to verify that I have the latest... 
but first work.


JT

On 12/7/2022 5:50 AM, andy pugh wrote:

In February I fixed this bug:
https://github.com/LinuxCNC/linuxcnc/issues/1528

But, it seems, I failed to properly consider full-circle spiral arcs, and
the test was wrong.

https://github.com/LinuxCNC/linuxcnc/issues/2169
(Note that this issue report was _not_ raised by the original reporter, and
furthermore seems to show a _different_ issue.

I investigated and found a test case that I could reproduce, and put in a
fix for that. (linked in the issue report above)

However it is reported that the original bug (that I have never reproduced)
still exists.

Here is the problem description:

"if open axis.

Comand g2 x0 y0 j5 z-2 f1000.

The machine not execution g2 , but only Z-2."

I think that the system needs to be set up for immediate homing to 0,0,0 as
I have an unconfirmed report that this specific problem does not occur if
the axes have moved.
(But then the test cases that Tom_L shows in the bug report has the third
arc going wrong too)

The problem that I have is that my system appears to be working perfectly,
so I can't investigate the issue here.

I could revert the original patch, but then that reintroduces a known bug,
so I don't want to do that.

So, first help needed, someone who can compile from source _and_ can
reproduce the reported problems. (think that there might be two, and one
might well be an uninitialised "start" for the arc in the just-homed case)

This clearly can't go out as-is, I am only glad that I didn't put the
original fix in 2.8 (I thought that I had, actually)




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

Re: [Emc-developers] Arc Bug, help needed.

[gene heskett]

On 12/7/22 06:51, andy pugh wrote:

In February I fixed this bug:
https://github.com/LinuxCNC/linuxcnc/issues/1528

But, it seems, I failed to properly consider full-circle spiral arcs, and
the test was wrong.

https://github.com/LinuxCNC/linuxcnc/issues/2169
(Note that this issue report was _not_ raised by the original reporter, and
furthermore seems to show a _different_ issue.

I investigated and found a test case that I could reproduce, and put in a
fix for that. (linked in the issue report above)

However it is reported that the original bug (that I have never reproduced)
still exists.

Here is the problem description:

"if open axis.

Comand g2 x0 y0 j5 z-2 f1000.

The machine not execution g2 , but only Z-2."

I think that the system needs to be set up for immediate homing to 0,0,0 as
I have an unconfirmed report that this specific problem does not occur if
the axes have moved.
(But then the test cases that Tom_L shows in the bug report has the third
arc going wrong too)

The problem that I have is that my system appears to be working perfectly,
so I can't investigate the issue here.

I could revert the original patch, but then that reintroduces a known bug,
so I don't want to do that.

So, first help needed, someone who can compile from source _and_ can
reproduce the reported problems. (think that there might be two, and one
might well be an uninitialised "start" for the arc in the just-homed case)

This clearly can't go out as-is, I am only glad that I didn't put the
original fix in 2.8 (I thought that I had, actually)

I'm running that now, on the rpi4, takes about an hour on the rpi4b, and 
I have bash set for lots of history. Script does a fresh pull so its 
about 5 minutes old right now.


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, 1940)
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] Arc Bug, help needed.

[gene heskett]

On 12/7/22 06:51, andy pugh wrote:

In February I fixed this bug:
https://github.com/LinuxCNC/linuxcnc/issues/1528

But, it seems, I failed to properly consider full-circle spiral arcs, and
the test was wrong.

https://github.com/LinuxCNC/linuxcnc/issues/2169
(Note that this issue report was _not_ raised by the original reporter, and
furthermore seems to show a _different_ issue.

I investigated and found a test case that I could reproduce, and put in a
fix for that. (linked in the issue report above)

However it is reported that the original bug (that I have never reproduced)
still exists.

Here is the problem description:

"if open axis.

Comand g2 x0 y0 j5 z-2 f1000.

The machine not execution g2 , but only Z-2."

I think that the system needs to be set up for immediate homing to 0,0,0 as
I have an unconfirmed report that this specific problem does not occur if
the axes have moved.
(But then the test cases that Tom_L shows in the bug report has the third
arc going wrong too)

The problem that I have is that my system appears to be working perfectly,
so I can't investigate the issue here.

I could revert the original patch, but then that reintroduces a known bug,
so I don't want to do that.

So, first help needed, someone who can compile from source _and_ can
reproduce the reported problems. (think that there might be two, and one
might well be an uninitialised "start" for the arc in the just-homed case)

This clearly can't go out as-is, I am only glad that I didn't put the
original fix in 2.8 (I thought that I had, actually)

If this is in buster, i've a script that builds master just to the end 
of runtests. Would that provide any useful info?


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, 1940)
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] Arc Bug, help needed.

[andy pugh]

In February I fixed this bug:
https://github.com/LinuxCNC/linuxcnc/issues/1528

But, it seems, I failed to properly consider full-circle spiral arcs, and
the test was wrong.

https://github.com/LinuxCNC/linuxcnc/issues/2169
(Note that this issue report was _not_ raised by the original reporter, and
furthermore seems to show a _different_ issue.

I investigated and found a test case that I could reproduce, and put in a
fix for that. (linked in the issue report above)

However it is reported that the original bug (that I have never reproduced)
still exists.

Here is the problem description:

"if open axis.

Comand g2 x0 y0 j5 z-2 f1000.

The machine not execution g2 , but only Z-2."

I think that the system needs to be set up for immediate homing to 0,0,0 as
I have an unconfirmed report that this specific problem does not occur if
the axes have moved.
(But then the test cases that Tom_L shows in the bug report has the third
arc going wrong too)

The problem that I have is that my system appears to be working perfectly,
so I can't investigate the issue here.

I could revert the original patch, but then that reintroduces a known bug,
so I don't want to do that.

So, first help needed, someone who can compile from source _and_ can
reproduce the reported problems. (think that there might be two, and one
might well be an uninitialised "start" for the arc in the just-homed case)

This clearly can't go out as-is, I am only glad that I didn't put the
original fix in 2.8 (I thought that I had, actually)

-- 
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