GT and LT and GE and LE failing
14 Sep 2015 00:59 - 14 Sep 2015 01:49 #62522
by GaryLa
GT and LT and GE and LE failing was created by GaryLa
Hello all,
I have had this problem before... I assume it has to do with a rounding issue that I cannot see. Specifically, the below code fails SOMETIMES: (I will write it in psuedo-code)
FinalDepth = 0.225
EachPass = 0.010
CurrentDepth = 0.000
modulus = FinalDepth MOD EachPass
CurrentDepth = modulus
Cut modulus depth (in this case is 0.005)
while [ CurrentDepth LE FinalDepth ]
make chips...
CurrentDepth = [CurrentDepth + EachPass]
endwhile
Adding "EachPass" plus the modulus always adds up to the FinalDepth. If I change the FinalDepth to 0.125 the loop works as expected. But certain values, like 0.225 fail. The loop ends one pass early.
I think it's an internal rounding error. That is, I think "CurrentDepth" must be something like 0.225000001 which is of course, not less than or equal to FinalDepth. Although when I display them, they show equal to 6 decimal places. The LE (in this case) fails even though CurrentDepth is equal to FinalDepth.
Has anyone else seen this behavior?
BTW, I know about "TOLERANCE_ERROR" and I've checked my interp_internal.hh file - it is 0.0001. Nonetheless, I can reproduce this issue constantly.
I took out the mod value and still get the issue. In fact, the issue appears whenever the FinalDepth is set to anything over 0.1715.
I have had this problem before... I assume it has to do with a rounding issue that I cannot see. Specifically, the below code fails SOMETIMES: (I will write it in psuedo-code)
FinalDepth = 0.225
EachPass = 0.010
CurrentDepth = 0.000
modulus = FinalDepth MOD EachPass
CurrentDepth = modulus
Cut modulus depth (in this case is 0.005)
while [ CurrentDepth LE FinalDepth ]
make chips...
CurrentDepth = [CurrentDepth + EachPass]
endwhile
Adding "EachPass" plus the modulus always adds up to the FinalDepth. If I change the FinalDepth to 0.125 the loop works as expected. But certain values, like 0.225 fail. The loop ends one pass early.
I think it's an internal rounding error. That is, I think "CurrentDepth" must be something like 0.225000001 which is of course, not less than or equal to FinalDepth. Although when I display them, they show equal to 6 decimal places. The LE (in this case) fails even though CurrentDepth is equal to FinalDepth.
Has anyone else seen this behavior?
BTW, I know about "TOLERANCE_ERROR" and I've checked my interp_internal.hh file - it is 0.0001. Nonetheless, I can reproduce this issue constantly.
I took out the mod value and still get the issue. In fact, the issue appears whenever the FinalDepth is set to anything over 0.1715.
Last edit: 14 Sep 2015 01:49 by GaryLa. Reason: last bit of data
Please Log in or Create an account to join the conversation.
14 Sep 2015 05:25 #62527
by BigJohnT
Replied by BigJohnT on topic GT and LT and GE and LE failing
What I do is to check that the depth remaining is greater than the depth of cut and when that is no longer true the last cut is done at final depth... pseudo code is a good thing!
JT
JT
Please Log in or Create an account to join the conversation.
14 Sep 2015 07:53 #62548
by GaryLa
Replied by GaryLa on topic GT and LT and GE and LE failing
I have done those checks too and often have just scratched my head and re-arranged things. But sometimes loops are just better written as "Current LE Max".
However, I wanted to get to the bottom of this issue (pardon the pun!)
When I set the FinalDepth to anything over 0.1715 I get this issue.
Do you know of any way I can change the display's precision? It's always 6 decimal places for me (I'm running 2.6.something).
Although I know the TOLERANCE_ERROR is used in the FABS(a - b) < TOLERANCE_ERROR evaluation -- meaning this shouldn't be an issue, but it is. Perhaps it's simply elsewhere.
As a professional programmer, I become obsessed with finding the cause of an anomaly or bug -- sometimes it even reveals a bigger issue. Frankly I would love to contribute, but I feel this project has too many source files and I don't have the time to try and figure out what is where. I write Linux OS code all the time for various things, so it doesn't bother me to debug - if I can get some clues from you as to where to look.
However, I wanted to get to the bottom of this issue (pardon the pun!)
When I set the FinalDepth to anything over 0.1715 I get this issue.
Do you know of any way I can change the display's precision? It's always 6 decimal places for me (I'm running 2.6.something).
Although I know the TOLERANCE_ERROR is used in the FABS(a - b) < TOLERANCE_ERROR evaluation -- meaning this shouldn't be an issue, but it is. Perhaps it's simply elsewhere.
As a professional programmer, I become obsessed with finding the cause of an anomaly or bug -- sometimes it even reveals a bigger issue. Frankly I would love to contribute, but I feel this project has too many source files and I don't have the time to try and figure out what is where. I write Linux OS code all the time for various things, so it doesn't bother me to debug - if I can get some clues from you as to where to look.
Please Log in or Create an account to join the conversation.
14 Sep 2015 19:16 #62560
by BigJohnT
Replied by BigJohnT on topic GT and LT and GE and LE failing
Can you share the G code that fails?
JT
JT
Please Log in or Create an account to join the conversation.
14 Sep 2015 20:07 - 14 Sep 2015 20:08 #62562
by GaryLa
Replied by GaryLa on topic GT and LT and GE and LE failing
I would be happy to share it. I will be at the shop later today and upload it from there.
Let me say, for the record, that things like this have turned out to be my fault just as often as they've turned out to be bugs....
Let me say, for the record, that things like this have turned out to be my fault just as often as they've turned out to be bugs....
Last edit: 14 Sep 2015 20:08 by GaryLa.
Please Log in or Create an account to join the conversation.
14 Sep 2015 23:35 #62572
by andypugh
From an old email
open /usr/share/pyshared/rs274/glcanon.py
Edit line 1068 and change
format = "% 6s:% 9.3f"
to
format = "% 6s:% 9.6f"
for 6 digits of decimals/
Then save the file.
It's python code, so no need to recompile anything.
Replied by andypugh on topic GT and LT and GE and LE failing
Do you know of any way I can change the display's precision? It's always 6 decimal places for me (I'm running 2.6.something)
From an old email
open /usr/share/pyshared/rs274/glcanon.py
Edit line 1068 and change
format = "% 6s:% 9.3f"
to
format = "% 6s:% 9.6f"
for 6 digits of decimals/
Then save the file.
It's python code, so no need to recompile anything.
Please Log in or Create an account to join the conversation.
15 Sep 2015 09:11 - 15 Sep 2015 09:12 #62602
by GaryLa
Replied by GaryLa on topic GT and LT and GE and LE failing
Thank you, but I knew about that already from a post of yours a while back - very helpful - I've used the file to make modest screen changes.
I was actually referring to the "status" messages which scroll into existence in the lower right when using "debug" statements in the gcode.
If that's in the python code somewhere - great. I just figured that was in the C code somewhere.
I was actually referring to the "status" messages which scroll into existence in the lower right when using "debug" statements in the gcode.
If that's in the python code somewhere - great. I just figured that was in the C code somewhere.
Last edit: 15 Sep 2015 09:12 by GaryLa.
Please Log in or Create an account to join the conversation.
15 Sep 2015 16:48 #62606
by andypugh
I am fairly sure that is is in the C++ code. I have had a look, but couldn't find it.
One solution might be to pass the intermediate results to a custom M-code that displays them to N-places and/or in hex.
Replied by andypugh on topic GT and LT and GE and LE failing
If that's in the python code somewhere - great. I just figured that was in the C code somewhere.
I am fairly sure that is is in the C++ code. I have had a look, but couldn't find it.
One solution might be to pass the intermediate results to a custom M-code that displays them to N-places and/or in hex.
Please Log in or Create an account to join the conversation.
Time to create page: 0.073 seconds