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

[andy pugh]

On Tue, 13 Dec 2022 at 18:59, andy pugh  wrote:

joints[joint_num].free_tp.curr_pos = H[joint_num].home; **
> This line is new ***
>

Runtests passes with this fix, FWIW.

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

[andy pugh]

On Sat, 10 Dec 2022 at 23:14, Dewey Garrett  wrote:

>
> > Is anyone else able to reproduce this behaviour?
>
> $ wget www.panix.com/~dgarrett/stuff/arc.tgz
> $ tar xzf arc.tgz
> $ cd arc
>

Using this test (thanks, up until this point I had been unable to reproduce
the issue) I have been able to find what seems to be a problem.

I believe that what is happening is that the homing sequence happens in
joint mode, and then at the end the joint positions (via kins) are used to
calculate the initial _axis_ positions.
The joint positions after homing are based on the joint-pos-fb pins (which,
for a machine with any kind of feedback, including stephen feedback) is
correct behaviour, it's your best information about the actual position of
the machine.

However, this means that the initial axis position after homing is not
exactly the home position.

The test G-code explicitly uses X and Y coordinates and so the start and
end positions of the arc, if an arc is the first _axis_ mode movement after
homing, are not identical enough to be identified as a full circle.

I have found a way to make this initial arc happen, by modifying homing.c
around line 1341:

   case HOME_FINISHED:
H[joint_num].homing = 0;
H[joint_num].homed = 1; // finished
H[joint_num].home_state = HOME_IDLE;
joints[joint_num].free_tp.curr_pos = H[joint_num].home; **
This line is new ***
immediate_state = 1;
H[joint_num].joint_in_sequence = 0;
break;

This fixes the issue. But does it make homing (for example to encoder
feedback) less accurate? I think it might, but I am not sure. The offsets
from feedback / index to machine coordinates have already been set at this
point.
Possibly with this change there will be a small remaining offset between
feedback and commanded position at the switch to world mode, but then that
might not be a bad thing, the machine will then move more exactly to home.
(Possibly).

This issue is only seen when a feed-rate, full circle arc is commanded with
a specific syntax[1] immediately after the switch from joint mode to world
mode at the end of homing. I think that is an unusual use-case.
There is a chance that my fix here is worse than the disease.

[1] An arc of the format G2 Z-1 J4 F1000 (ie, the "from here in XY"
shorthand) will work as-expected, even without this bug fix.

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

[andy pugh]

On Sat, 10 Dec 2022 at 23:14, Dewey Garrett  wrote:

> a) not reproducible if  all joints set immediate homing
> as there are no residual position errors
>

Thanks for that, the original problem description was very garbled but
seemed to be indicating that there was no movement during homing on his
machine, and so I had deliberately set immediate hiking for most of my
tests.

The underlying issue seems to be that homing doesn't actually get all the
way to the defined home position. In fact it seems to be 2.5 * CART_FUZZ
away from the defined home position.

Interestingly g2 x0 y0 z-1 j4 f1000 gives the error but g2 z-1 j4 f1000
does not, because that uses the actual not-quite-zero starting point.

I don't know how important _this_ bug is as it would be very unusual to
machine an arc immediately after homing.

A kludgy workaround is to just widen the tolerance distance at which a full
circle is assumed. CART_FUZZ is 1e-8 units (appears to be the units of the
config)

if (d < 10 * CART_FUZZ){
circle->angle = PM_2_PI;
}

But I think it would be better to set the axis position _exactly_ to the
home position at the last point in the homing sequence.

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

[Nicklas SB Karlsson]

lör 2022-12-10 klockan 23:10 + skrev Dewey Garrett:
> 
> > Is anyone else able to reproduce this behaviour?
> 
> $ wget www.panix.com/~dgarrett/stuff/arc.tgz
> $ tar xzf arc.tgz
> $ cd arc
> 
> 1) start from command line
> $ linuxcnc arc.ini
> 
> 2) Initialize
> F1 -- Machine on
> F2 -- Estop off
> Ctrl-HOME --- Home all
> # Display shows one turn spiral
> 
> 3) Examine residual settings after homing:
> (too small to be visible on display)
> # example:
> $ halcmd show pin axis.[xyz].pos-cmd
> Component Pins:
> Owner   Type  Dir Value  Name
>     23  float OUT  2.569163e-08  axis.x.pos-cmd
>     23  float OUT  2.845021e-09  axis.y.pos-cmd
>     23  float OUT  2.569163e-08  axis.z.pos-cmd
> 
> 4) r - Run program
> #  observe errant linear (z) move, no spiral
> 
> 5) r - Run program
> # observe correct execution of circle at z=-1
There is an issue if end point for a circle is exaxtly at one turn.
Adding a nanometer to not make it slightly more or less solve the
problem?



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

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

[Greg C]

If it helps, after following the steps below, I can reproduce everything
described.

-Greg

On Sat, Dec 10, 2022 at 6:14 PM Dewey Garrett  wrote:

>
> > Is anyone else able to reproduce this behaviour?
>
> $ wget www.panix.com/~dgarrett/stuff/arc.tgz
> $ tar xzf arc.tgz
> $ cd arc
>
> 1) start from command line
> $ linuxcnc arc.ini
>
> 2) Initialize
> F1 -- Machine on
> F2 -- Estop off
> Ctrl-HOME --- Home all
> # Display shows one turn spiral
>
> 3) Examine residual settings after homing:
> (too small to be visible on display)
> # example:
> $ halcmd show pin axis.[xyz].pos-cmd
> Component Pins:
> Owner   Type  Dir Value  Name
> 23  float OUT  2.569163e-08  axis.x.pos-cmd
> 23  float OUT  2.845021e-09  axis.y.pos-cmd
> 23  float OUT  2.569163e-08  axis.z.pos-cmd
>
> 4) r - Run program
> #  observe errant linear (z) move, no spiral
>
> 5) r - Run program
> # observe correct execution of circle at z=-1
>
>
> 6) Start over: repeat 1),2),3) (at home position)
> 7) Ctrl-R  Reload program
> # note display shows the incorrect errant linear move only
>
> Notes:
> a) not reproducible if  all joints set immediate homing
> as there are no residual position errors
> --
> Dewey Garrett
>
>
>
> ___
> 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.

[Dewey Garrett]

> Is anyone else able to reproduce this behaviour?

$ wget www.panix.com/~dgarrett/stuff/arc.tgz
$ tar xzf arc.tgz
$ cd arc

1) start from command line
$ linuxcnc arc.ini

2) Initialize
F1 -- Machine on
F2 -- Estop off
Ctrl-HOME --- Home all
# Display shows one turn spiral

3) Examine residual settings after homing:
(too small to be visible on display)
# example:
$ halcmd show pin axis.[xyz].pos-cmd
Component Pins:
Owner   Type  Dir Value  Name
23  float OUT  2.569163e-08  axis.x.pos-cmd
23  float OUT  2.845021e-09  axis.y.pos-cmd
23  float OUT  2.569163e-08  axis.z.pos-cmd

4) r - Run program
#  observe errant linear (z) move, no spiral

5) r - Run program
# observe correct execution of circle at z=-1

   
6) Start over: repeat 1),2),3) (at home position)
7) Ctrl-R  Reload program
# note display shows the incorrect errant linear move only

Notes:
a) not reproducible if  all joints set immediate homing
as there are no residual position errors
-- 
Dewey Garrett



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

Searching for "linuxcnc go reference" lands me on a forum page where the 
user said go reference then something about reference the axis so I'm 
thinking it's homing the axis. The Axis sim is too clever and does a 
bunch of moves to simulate a real machine homing but that may be masking 
the issue.


JT

On 12/10/2022 12:53 PM, andy pugh wrote:

The original corresponent has tried the latest Master and says.

(Three plane test spiral code)
"is good executed,
but if start linuxcnc and go reference,
after reference is finisch and in mdi start g2 x0y0z-1 j4 f1000
the tool go directly again at z-1 , not executed circle."

Is anyone else able to reproduce this behaviour?




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

Any clue what "go reference" means?

JT

On 12/10/2022 12:53 PM, andy pugh wrote:

The original corresponent has tried the latest Master and says.

(Three plane test spiral code)
"is good executed,
but if start linuxcnc and go reference,
after reference is finisch and in mdi start g2 x0y0z-1 j4 f1000
the tool go directly again at z-1 , not executed circle."

Is anyone else able to reproduce this behaviour?




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

The original corresponent has tried the latest Master and says.

(Three plane test spiral code)
"is good executed,
but if start linuxcnc and go reference,
after reference is finisch and in mdi start g2 x0y0z-1 j4 f1000
the tool go directly again at z-1 , not executed circle."

Is anyone else able to reproduce this behaviour?

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

[andy pugh]

On Fri, 9 Dec 2022 at 23:50, Stuart Stevenson  wrote:

> I think I would pay attention to G90/G91.


Shouldn't really matter. It's a different way to define the start and end
points, but that happens in untouched code.

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

[Stuart Stevenson]

I think I would pay attention to G90/G91.

On Wed, Dec 7, 2022 at 7:48 PM Greg C  wrote:

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


-- 
Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.

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

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