G70,G71,G72 looping not drawing

[powerio25]

The issue tracker is not a support forum

The LinuxCNC issue tracker is to report bugs in the software. If you have a question about how to use the software, use one of the other methods detailed on our community support page: http://linuxcnc.org/community/

(delete this section before submitting your bug report)

Here are the steps I follow to reproduce the issue:

1. g71.txt

2. 3.

This is what I expected to happen:

First the patch , this code in attachment run good.

This is what happened instead:

in src/emc/rs274ngc/interp_g7x.cc try { switch(cycle) { case 70: path.do_g70(&motion,x,z,d,e,p); break; -case 71: path.do_g71(&motion,subcycle,x,z,u,w,d,i,r); break; -case 72: path.do_g72(&motion,subcycle,x,z,u,w,d,i,r); break; case 71: if(x!=imag(start)) { std::complex end{real(start),x}; path.emplace_back(std::make_unique( start, end )); } path.do_g71(&motion,subcycle,x,z,u,w,d,i,r); break; case 72: if(z!=real(start)) { std::complex end{z,imag(start)}; path.emplace_back(std::make_unique( start, end )); } path.do_g72(&motion,subcycle,x,z,u,w,d,i,r); break; } } catch(std::string &s) { ERS("G7X error: %s", s.c_str());

It worked properly before this:

(If the behavior changed after making a particular change in hardware or software, describe the change you think is responsible. E.g., "after upgrading from LinuxCNC 2.7.3 to 2.7.4")

Information about my hardware and software:

• I am using this Linux distribution and version (often, shown by lsb_release -a):
• I am using this kernel version (shown by uname -a):
• I am running ...
  • [ ] A binary version from linuxcnc.org (including buildbot.linuxcnc.org)
  • [ ] A binary I built myself
  • [ ] A binary version from some other source besides linuxcnc.org
• I am using this LinuxCNC version (shown in package manager or, for git versions, scripts/get-version-from-git):
• I am using this user interface (GUI) (e.g., AXIS, Touchy, gmoccapy, etc):
• I am using this interface hardware vendor and chipset (e.g., parallel port, ethernet port, FPGA card):

[havardAasen]

What version of LinuxCNC do you use?

This patch seems identical to the one in #2677, which is included in 2.9.1

[petterreinholdtsen]

[Håvard]

What version of LinuxCNC do you use?

This patch seems identical to the one in #2677, which is included in 2.9.1

Is this related to the tests in tests/interp/g71-endless-loop/ and tests/interp/g71-loop/, which try to trigger the endless loop problem in the parser?

-- Vennlig hilsen Petter Reinholdtsen

[powerio25]

I use 2.9.0 pre0. the program in g71.txt ran correctly before the latest patch:

in src/emc/rs274ngc/interp_g7x.cc try { switch(cycle) { case 70: path.do_g70(&motion,x,z,d,e,p); break; -case 71: path.do_g71(&motion,subcycle,x,z,u,w,d,i,r); break; -case 72: path.do_g72(&motion,subcycle,x,z,u,w,d,i,r); break; case 71: if(x!=imag(start)) { std::complex end{real(start),x}; path.emplace_back(std::make_unique( start, end )); } path.do_g71(&motion,subcycle,x,z,u,w,d,i,r); break; case 72: if(z!=real(start)) { std::complex end{z,imag(start)}; path.emplace_back(std::make_unique( start, end )); } path.do_g72(&motion,subcycle,x,z,u,w,d,i,r); break; } } catch(std::string &s) { ERS("G7X error: %s", s.c_str());

[havardAasen]

I tested the ngc file, it believe it should be safe to use 2.9.0-pre1, not latest, but still three years newer than what your currently running.

---

I did have a look at this, though, I doubt I can provide any fix for it.

What I found out, or perhaps rediscovered is summarized below. All values are obtained from the supplied ngc file.

Comparing master to 2.9.0-pre0. We add a new segment to the path in https://github.com/LinuxCNC/linuxcnc/blob/73b24daf11d55b7ac349fbeb75c47be3f4870db3/src/emc/rs274ngc/interp_g7x.cc#L1176-L1182

The new segment has values

start: -415 + 170i
end:   -415 + 168i

At this point path consists of 12 segments.

we insert connecting arcs https://github.com/LinuxCNC/linuxcnc/blob/73b24daf11d55b7ac349fbeb75c47be3f4870db3/src/emc/rs274ngc/interp_g7x.cc#L855-L868

When the connecting arcs has been added, path consists of 14 segments where the last two has the values

start: -415 + 170.40000000000001i
end:   -415.39999999999998 + 170i

start: -415.39999999999998 + 170i
end:   -415.39999999999998 + 168i

After that we end up in pocket(), which does it's thing until the last segment, never returning from the recursive call. I'm not sure if its the values in the segment itself or if its something else.

[powerio25]

My file interp_g7x.cc is the same at actual master, i have add manually last patch , but not can drawing gcode sensed.

for(auto p=begin(); p!=--end(); p++) { auto n=p; ++n; if(real((p)->ep()-(n)->sp())>1e-2) { // insert connecting arc auto s((p)->dup()); auto e((n)->dup()); s->offset(-max_distance); e->offset(-max_distance); auto center=(s->ep()+e->sp())/2.0; emplace(n, std::make_unique( distance>0,(p)->ep(),center,(n)->sp())); p++;

this part of code was already in my file.

i have add manually and recompiled only this :

case 71: if(x!=imag(start)) { std::complex end{real(start),x}; path.emplace_back(std::make_unique( start, end )); } path.do_g71(&motion,subcycle,x,z,u,w,d,i,r); break; case 72: if(z!=real(start)) { std::complex end{z,imag(start)}; path.emplace_back(std::make_unique( start, end )); } path.do_g72(&motion,subcycle,x,z,u,w,d,i,r); break; }

[havardAasen]

I've managed to come up with a solution, though I'm uncertain if it's a hack or a fix. I find the function to be a on the larger side for a recursive one, with to many paths to cover.

The proposed solution is the following:

diff --git a/src/emc/rs274ngc/interp_g7x.cc b/src/emc/rs274ngc/interp_g7x.cc
index 3f15ae5f42..018988e07c 100644
--- a/src/emc/rs274ngc/interp_g7x.cc
+++ b/src/emc/rs274ngc/interp_g7x.cc
@@ -776,6 +776,10 @@ void g7x::pocket(int cycle, std::complex<double> location, iterator p,
            }
            return;
        }
+
+       if (p==std::prev(end()))
+           break;
+
        if(std::abs(imag(location)-x)>tolerance) {
            /* Our x coordinate is beyond the current segment, move onto
               the next

end() always points one past the last element, so std::prev(end()) will be the last element to look for. The code after this only check for intersections, but that shouldn't be any problem since we're already on the last path.

The tests we have succeeds with this patch but I wish we had more of them, to be certain nothing breaks.

[powerio25]

I have test this fix and it now running ok I will test this fix for many program in nexts week and advise for result.

Thanks

[powerio25]

HI .

I have test the program in test.zip and run all good with last fix : if (p==std::prev(end()))

• break;

I thing merge it and advise if have some problem in future

test.zip