Help! Something has gone terribly wrong! Bug?

More
11 Jan 2012 06:18 #16563 by NicHoza
Hello. I seem to be experiencing a bug with EMC2, which is visible through the AXIS interface (and perhaps caused by AXIS? I'm not sure exactly what AXIS does).

The problem is that when I run a particular program, at a particular point in the program, all three axis suddenly begin to rapidly move several inches when they shouldn't.

The following screenshot shows the problem (I paused the program soon after it started moving incorrectly) -- note that at the bottom of the screen it shows the command in the program that it is currently executing (G01 X3.5688 Y0.1734 Z-0.592 F10). Note also that the current X Y and Z positions are all within half an inch of this position. Then notice that the distance-to-go-X (DTGX) is 3.6 inches, and there are similar problems with the other axis. The A axis seems to be on its way to 90 degrees, with no reason for doing so that I can think of.

I have experienced this once before with a different, simpler program. If I remember correctly, it would not happen at the same point in the program every time, but rather at random points. It is as though it suddenly switches coordinates (e.g., G54 to G55). If you know what is happening, please help! Thanks! I'm running EMC 2.3.5 with AXIS 2.3.5.

Please Log in or Create an account to join the conversation.

More
11 Jan 2012 07:40 #16567 by cncbasher
you are running version 2.3.5 ... are you able to upgrade to 2.3.5
or post gcode program which shows fault

Please Log in or Create an account to join the conversation.

More
11 Jan 2012 08:24 #16571 by NicHoza
I have attached the gcode. It is generated by a program I wrote, and is quite long (almost 20,000 lines). It also contains some subroutines (O100 and O200). Is there any chance the length or the subroutines could be causing a problem?

I could upgrade to a different version but I am hesitant to do so unless I know that doing so would fix this problem. This is not a known bug?

Thanks for any help!

File Attachment:

File Name: compass_057_fam3.ngc
File Size:477 KB
Attachments:

Please Log in or Create an account to join the conversation.

More
11 Jan 2012 10:53 #16577 by Rick G

The problem is that when I run a particular program, at a particular point in the program, all three axis suddenly begin to rapidly move several inches when they shouldn't.

I have experienced this once before with a different, simpler program. If I remember correctly, it would not happen at the same point in the program every time, but rather at random points. I


Have you determined if the problem is always at the same point now?

If so could you show what portion of the code is the problem?

I believe there may have been bug fixes for subroutines since the version you are running.

Rick G

Please Log in or Create an account to join the conversation.

More
11 Jan 2012 11:51 #16582 by BigJohnT
NicHoza wrote:

I have attached the gcode. It is generated by a program I wrote, and is quite long (almost 20,000 lines). It also contains some subroutines (O100 and O200). Is there any chance the length or the subroutines could be causing a problem?

I could upgrade to a different version but I am hesitant to do so unless I know that doing so would fix this problem. This is not a known bug?

Thanks for any help!

File Attachment:

File Name: compass_057_fam3.ngc
File Size:477 KB


I would say that your g code is causing the problem as there is no known bug in EMC that will cause it to go where it is not commanded to go. The length of the file is not a problem as long as you have enough memory to load it iirc.

Some things to look for are subroutines that don't have unique numbers, subroutines before the call which would use subroutines in your directory instead of the one in your file.

John

Please Log in or Create an account to join the conversation.

More
11 Jan 2012 11:54 - 11 Jan 2012 11:55 #16583 by BigJohnT
Rick G wrote:

I believe there may have been bug fixes for subroutines since the version you are running.

Rick G


The only bug fix I can find is in 2.4.3 and involves run from line.

task: Improve behavior when RFL line is between subroutine definition and use


John
Last edit: 11 Jan 2012 11:55 by BigJohnT.

Please Log in or Create an account to join the conversation.

More
11 Jan 2012 19:22 #16608 by NicHoza

Have you determined if the problem is always at the same point now?


I have only run it twice, but it happened at the same spot each time.

If so could you show what portion of the code is the problem?


As previously mentioned and shown in the screenshot, it happens on or near the line "G01 X3.5688 Y0.1734 Z-0.592 F10" which is within subroutine O100

I would say that your g code is causing the problem as there is no known bug in EMC that will cause it to go where it is not commanded to go.


I would say that my g code is definitely not causing the problem, since there is nowhere in the code that has the X axis go anywhere close to +7", which is where it was going.

The length of the file is not a problem as long as you have enough memory to load it iirc.


What if I do not have enough memory to load it? Will it give me an error message, or will it try to run it anyway, resulting in strange things happening?

Some things to look for are subroutines that don't have unique numbers, subroutines before the call which would use subroutines in your directory instead of the one in your file.


This is backwards. Subroutines may only be called after they are defined. (see linuxcnc.org/docs/html/gcode_main.html#r3_1 ). The names are unique, and it begins running the subroutine correctly. Then, in the middle of the subroutine, it goes crazy!

Thanks for the responses. Please help!

Please Log in or Create an account to join the conversation.

More
11 Jan 2012 23:04 - 11 Jan 2012 23:05 #16620 by BigJohnT
NicHoza wrote:

Have you determined if the problem is always at the same point now?


I have only run it twice, but it happened at the same spot each time.


It is most definitely your g code that is causing the problem if it happens in the same place each time you run the file. If your g code does not rely on special hardware like probe inputs can you zip the file and attach it to a reply?

I have to assume there would be an error if your file is too large but I've not seen one yet. Or it might start disk swapping... did you look at memory usage when you load the file?

Yea, I meant a call before a subroutine, good catch.

John
Last edit: 11 Jan 2012 23:05 by BigJohnT.

Please Log in or Create an account to join the conversation.

More
24 Jan 2012 09:40 #17091 by NicHoza
I have eliminated memory as a possible cause. I checked, and I was using about 300MB of memory and I only had 256MB of physical memory, so this seemed like a likely problem, but I replaced the memory with a 1GB memory card and I am still experiencing the problem.

My most recent test (new but similar program) has yielded very strange, similar but distinctly different, results:

After running for a while, the program suddenly jumped back to a previous part of the program, and started running from there. I let it keep going, and at the same point it suddenly jumped back again to a slightly different point.

Here is what the program looks like:

O100 sub
stuff
O100 endsub

O200 sub
stuff
O200 endsub

O100 call
stuff
*!*!*!*!*!*!*!*!*!
stuff
O200 call
stuff

At the point where I put in *!*!*!*!*!*!*!*!*!, it suddenly jumps to a point right in the *middle* of the O100 subroutine. This has happened repeatedly for different large programs of mine. It sometimes jumps from the same point repeatedly, and sometimes jumps from random points. It only happens with large programs, and it seems like a bad pointer somewhere. Someone out there MUST have experienced this. It is definitely NOT a problem with my g code.

It seems possible (although this is just a guess) that it is jumping to the point where the coordinate system was last changed (e.g., G55 to G56).

Please Log in or Create an account to join the conversation.

More
24 Jan 2012 22:55 #17105 by NicHoza
UPDATE: I replaced each subroutine call (e.g., "O100 call") with the contents of the subroutine, thereby eliminating the subroutines altogether. This fixed the problem. There is definitely a bug in EMC2 related to subroutines!

NOTE: I was a bad scientist, and I manipulated two variables. The other thing I changed is that I removed the line numbers. It seems very unlikely that this would do anything, but ya never know.

Please Log in or Create an account to join the conversation.

Time to create page: 0.284 seconds
Powered by Kunena Forum