Macro program - GT operator illogical behavior

[ThickChips]

Hello,

Unsure if macro assistance is a permissible topic of the forum. 

HAAS NGC control

I am trying to test for the following condition:

N10		(512= num passes, 513 =stepover)
N11		#601 = [#512 * #513]
N12		(510 = bore size, 511 = tool size)
N13		#602 = [#510-#511]/2
N14		M00
N15		IF [#601 GT #602] GOTO 5002 (5002= DISPLAY ERROR)

Under current inputs, N15 evaluates as if #601 is in fact greater than #602, and therefore GOTO 5002 executes.

The issue is, this is invalid behavior under current inputs. #601 AND #602 are BOTH displayed as 9.000000 in the control before N15 executes (at N14)

That it to say, neither is greater than the other. 

Further, the following lines did not evaluate properly either:

N15		IF [ROUND[#601] GT #602] GOTO 5002 (5002= DISPLAY ERROR)

And this as well....

N15		IF [ROUND[#601] GT ROUND[#602]] GOTO 5002 (5002= DISPLAY ERROR)

Note that #512 and #513 are initialized in program header as decimals like... (whether that matters or not) ...

#512 = 1.0
#513 = .05

This is also true for #510 and #511 - initialized as decimals. 

Am i going insane or am I missing something?

 

Appreciate another set of eyes. Thanks a lot

 

 

 

 

[Werktuigbouwer]

Have you also checked the inputs at line N14?.

 

Mayby the control is overwriting it somewhere.

[ThickChips]

1 minute ago, Werktuigbouwer said:

Have you also checked the inputs at line N14?.

 

Maybe the control is overwriting it somewhere.

Yes. M00 executes. Check the vars and both equal 9.000000 which is what is expected based on my inputs.

[JParis]

I cannot speak to Haas macro formatting

N10 (512= num passes, 513 =stepover)

N11 #601 = [#512 * #513]

N12 (510 = bore size, 511 = tool size)

N13 #602 = [#510-#511]/2

N14 M00

N15 IF [#601 GT #602] GOTO 5002 (5002= DISPLAY ERROR)

 

but Fanuc Macro

#512=9(Number of passes)

#513=.05(Stepover)

#601=[[#512]*[#513]]

#510=1.00(Bore Size)

#511=.375(Tool size)

#602=[[#510]-[#511]/2

M00

IF[#601GT#602]GOTO5002

N5002=#3000=99(DISPLAYERROR)

Haven't tested it but that's a sketch that I would use...I would probably reorder to define all variables at the top...then to math....then do checking

[Zoffen]

If this is haas you need to cancel the look ahead for macros to calculate correctly.

G103 P1 should limit the look ahead to 1 block and then things should go smoothly. In theory.

G103 turns the look ahead back on.

Hope this helps!

[crazy^millman]

I think the process is laid out odd like JParis mentioned. What does the complete macro look like? 

[ThickChips]

@Zoffen

Man, I was really hoping this was the golden ticket (G103 p1). Sadly, it didn't seem to affect behavior. Tried at top of program. Before the line. Adding empty blocks before the block in question. No effect.

@JParis @crazy^millman

The process isn't odd.  The complete context just isn't provided. Nevertheless, to rule out any doubt I used a variant of @JParis example to isolate the issue. And my findings are quite... unpredictable.

 

I did some extensive testing this morning. Below describes a number of tests and their results. Here are the cliff-notes:

• It is important to understand all tests have been run under inputs that yield identical results for #601 and #602. That is to say #601=#602 in all tests, regardless of inputs. No testing was done where they are not equivalent, and I assume said tests would pass fine. 
• G103 P1 had no affect - but I didn't include it in the tests below - more testing would be ideal.
• M00 before the IF statement directly affects this behavior. (I know the M00/M01 affects look ahead according to haas docs)
• The inputs directly affect the behavior - So, we assume some sort of numerical error is at play. (namely when #601 and #602 = .900000) it causes issues.

 

Here are the tests - also attached as individual programs. 

Tests.zip

 

(TEST 1 - PASS)
%
O0000  (MACRO)
#512 = 5.0 (pass with decimal or integer)
#513 = .05
#601 = [[#512*#513]] (=.250)
#510 = 1.00
#511 = .500

#602=[#510-#511]/2 (=.250)
IF[#601GT#602]GOTO1000 (pass - does NOT GOTO 1000)
#3000=1(PASS)
N1000
#3000=1(FAIL)
M30
%

(------------------------------------------------)

(TEST 2 - FAIL)
%
O0000  (MACRO)
#512 = 9. 
#513 = 0.1 
#601 = [[#512*#513]] (=.9 <------- inputs have changed)
#510 = 2.3 
#511 = .500

#602=[#510-#511]/2 (=.9)
IF[#601GT#602]GOTO1000(FAIL! GOES TO 1000)
#3000=1(PASS)
N1000
#3000=1(FAIL)
M30
%

(------------------------------------------------)


(TEST 3 - PASS)
%
O0000  (MACRO)
#512 = 9. 
#513 = 0.1 
#601 = [[#512*#513]] (=.9)
#510 = 2.3 
#511 = .500

#602=[#510-#511]/2 (=.9)
IF[ROUND[#601] GT ROUND[#602]] GOTO1000 (pass - does NOT GOTO 1000)
#3000=1(PASS)
N1000
#3000=1(FAIL)
M30
%

(-----------------------------------------------------)

(TEST 4 - FAILS)
%
O0000  (MACRO)
#512 = 9. 
#513 = 0.1 
#601 = [[#512*#513]] (=.9)
#510 = 2.3 
#511 = .500

#602=[#510-#511]/2 (=.9)
M00 (<------ NOTICE)
IF[ROUND[#601] GT ROUND[#602]] GOTO1000 (FAIL! GOES TO 1000)
#3000=1(PASS)
N1000
#3000=1(FAIL)
M30
%

(-----------------------------------------------------)


(TEST 5 - PASSES)
%
O0000  (MACRO)

#512 = 13. 
#513 = .0625 
#601 = [[#512*#513]] (=.8125 <------ INPUTS HAVE CHANGED!)
#510 = 2.125
#511 = .500

#602=[#510-#511]/2 (=.8125)
IF[ROUND[#601] GT ROUND[#602]] GOTO1000 (PASS - does NOT goto 1000)
#3000=1(PASS)
N1000
#3000=1(FAIL)
M30
%

(-----------------------------------------------------)


(TEST 6 - PASSES)
%
O0000  (MACRO)
#512 = 13. 
#513 = .0625 
#601 = [[#512*#513]] (=.8125 <------ INPUTS HAVE CHANGED!)
#510 = 2.125
#511 = .500

#602=[#510-#511]/2 (=.8125)
M00 (<---- PASSES EVEN WITH M00)
IF[ROUND[#601] GT ROUND[#602]] GOTO1000 
#3000=1(PASS)
N1000
#3000=1(FAIL)
M30
%

 

 

 

[ThickChips]

Update:

 

Added a 7th test with a PASS

(Inserted M00 with "working inputs" from Test #1)

(TEST 7  -  PASSES)
%
O0000  (MACRO)
#512 = 5.0 
#513 = .05
#601 = [[#512*#513]] (=.250)
#510 = 1.00
#511 = .500
M00 (<----- M00 inserted)
#602=[#510-#511]/2 (=.250)
IF[#601GT#602]GOTO1000 (pass - does NOT goto 1000)
#3000=1(PASS)
N1000
#3000=1(FAIL)
M30
%

 

 

[JParis]

Do you really want to be using LE & GE in those conditions?

Looking through your first 2 examples, you create a condition that the numbers are equal...

I'm not sure exactly what condition you are checking for but if an "equal" condition is possible, it should be accounted for in the macro statement....

and if you choose to set a separate "equal" condition check, I would do that as the first check, otherwise the order of operations could still cause funky results...

[ThickChips]

15 minutes ago, JParis said:

Do you really want to be using LE & GE in those conditions?

Looking through your first 2 examples, you create a condition that the numbers are equal...

I'm not sure exactly what condition you are checking for but if an "equal" condition is possible, it should be accounted for in the macro statement....

Yes and even if I didn't this isn't exactly relevant because the behavior is illogical.

EQ is a VALID condition under the context, and so is LT. Meaning that EQ doesn't have to be accounted for. GT needs to be accounted for.

 

EDIT: I misinterpreted LE/GE comment. My reply of 'Yes' should be 'No'

 

[JParis]

It's illogical because the equation is illogical....

Those kinds of macro statements cause problems, as you're seeing...any macro needs to account for every possible solution or you will see strange behavior...

With that I'm out

[ThickChips]

@JParis

Sorry, perhaps you could explain what part of the statement is illogical...

If you think that ".900000 > .900000 = TRUE" is logical, then you're being... illogical. 

GT operators were included in the language for a reason.

 

[Zoffen]

Are you loading the macro into the control with the Prog O00000?

I know on my machine I was told that you need to have a blank program O0000 otherwise random things will happen.

So possibly when you are using O0000 this is interfering with something in the background

--

Another thing with macro variables is that you may initialize it to #1=5.0000 but internally the control will initialize it to 5.00000021516 or something because they are using floating point numbers which are never exact. so when you do a EQ comparison it may appear that it is equal but internally it is not. I always use 4-5 decimals just to be safe. Not sure if this helps but as you see here nothing is every straightforward and I find doing things the same way leads to more consistent/expected results when doing stuff like this.

Also I never use LE and GE. I always use GT and LT a have never had an issue.

Instead of [ #1 LE 5.0000]

I will use [ #1 LT 5.0001]

--

Possibly add 2-3+ blank lines between each statement to MAKE SURE they are not being overrun by the look ahead, even when set to 1 block it seems to still like to overrun. I have had to add 5-10 blank lines between blocks to get things to work as expected and not overrun creating unexpected macro behavior.

 

I would take a few days away from this project and magically the right solution will come to you. Let your subconscious do the work for you!

[Jake L]

13 minutes ago, Zoffen said:

Another thing with macro variables is that you may initialize it to #1=5.0000 but internally the control will initialize it to 5.00000021516 or something because they are using floating point numbers which are never exact.

+1 to this

[crazy^millman]

1 hour ago, ThickChips said:

@JParis

Sorry, perhaps you could explain what part of the statement is illogical...

If you think that ".900000 > .900000 = TRUE" is logical, then you're being... illogical. 

GT operators were included in the language for a reason.

 

That is not what he is saying. He is saying your logic in the equation is looking at the math and making a determination of what is greater or less than for numbers that by your math process are being made equal with the variables values you are using. You are comparing the same #601 and #602 math with the same inputs. This will create an infinite loop that will never close. If .9 is less than .9 then goto 1000 if .9 is greater than .9 then go to 1000. Replace the .9 with the .25 it is still resulting in the same result even thought you are using #510-#513 for values the issue is the end results for each equation is the same value. 

 

In every example your process is using values that will equal themselves, but you are using a greater or less than equation when it should be a equal too equation since you are comparing apples to apples and not apples to oranges. Like suggested step away and don't take the help as a personal insult it is not meant that way.

[ThickChips]

9 minutes ago, crazy^millman said:

That is not what he is saying. He is saying your logic in the equation is looking at the math and making a determination of what is greater or less than for numbers that by your math process are being made equal with the variables values you are using. You are comparing the same #601 and #602 math with the same inputs. This will create an infinite loop that will never close. If .9 is less than .9 then goto 1000 if .9 is greater than .9 then go to 1000. Replace the .9 with the .25 it is still resulting in the same result even thought you are using #510-#513 for values the issue is the end results for each equation is the same value. 

 

In every example your process is using values that will equal themselves, but you are using a greater or less than equation when it should be a equal too equation since you are comparing apples to apples and not apples to oranges. Like suggested step away and don't take the help as a personal insult it is not meant that way.

I've taken nothing personal. I'm merely pointing out what is true and what is not true. Someone may not like the way code is written, it doesn't change the fact that it is logically valid under the rules of the language.

Respectfully, there is a lot of fallacies within your comment....

 

Quote

create an infinite loop that will never close

 

No infinite loop is possible under these tests. IF GT is true, then it goes to 1000. If GT is false, it continues execution. I would like to see a code example that demonstrates an infinite loop.

 

Next, you say this,

Quote

Replace the .9 with the .25 it is still resulting in the same result even thought you are using #510-#513 for values the issue is the end results for each equation is the same value. 

 

This is false! I provided the tests, did you review them? 

Test 1 checks:  IS .25 > .25? Result is NO - PASS

Test 2 checks: IS .9 > .9? Result is YES - FAIL <-------------- NOT TRUE

Quote

(TEST 1 - PASS)
%
O0000  (MACRO)
#512 = 5.0 (pass with decimal or integer)
#513 = .05
#601 = [[#512*#513]] (=.250)
#510 = 1.00
#511 = .500

#602=[#510-#511]/2 (=.250)
IF[#601GT#602]GOTO1000 (pass - does NOT GOTO 1000)
#3000=1(PASS)
N1000
#3000=1(FAIL)
M30
%

(------------------------------------------------)

(TEST 2 - FAIL)
%
O0000  (MACRO)
#512 = 9. 
#513 = 0.1 
#601 = [[#512*#513]] (=.9 <------- inputs have changed)
#510 = 2.3 
#511 = .500

#602=[#510-#511]/2 (=.9)
IF[#601GT#602]GOTO1000(FAIL! GOES TO 1000)
#3000=1(PASS)
N1000
#3000=1(FAIL)
M30
%

 

 

 

 

 

[crazy^millman]

9 minutes ago, ThickChips said:

I've taken nothing personal. I'm merely pointing out what is true and what is not true. Someone may not like the way code is written, it doesn't change the fact that it is logically valid under the rules of the language.

Respectfully, there is a lot of fallacies within your comment....

 

 

No infinite loop is possible under these tests. IF GT is true, then it goes to 1000. If GT is false, it continues execution. I would like to see a code example that demonstrates an infinite loop.

 

Next, you say this,

 

This is false! I provided the tests, did you review them? 

Test 1 checks:  IS .25 > .25? Result is NO - PASS

Test 2 checks: IS .9 > .9? Result is YES - FAIL <-------------- NOT TRUE

 

 

 

 

 

You are really tying to pass that math off as legit? How in the world can .25 be greater (<) than or even less than (>) .25? It is equal (=) to itself every day of the week and twice on Sunday.

I have a quarter it is equal to a quarter. Now the quarter is greater than a dime, nickle and penny, but less than a half dollar, dollar and such. It can never be greater than or less than itself and you keep trying to say it is.

Now if you want me to check out of this conversation I am glad too no sweat off  my back, but I did review every equation and you and not explaining yourself correctly when is come to understanding the correct use of greater than or less than for the process you are using. 

 

 

[ThickChips]

Quote

How in the world can .25 be greater (<) than or even less than (>) .25?

Precisely - it CANT BE - so why is GOTO 1000 being executed? 

Quote

It can never be greater than or less than itself

And again - CORRECT. Therefore, WHY is GT returning TRUE (going to 1000)?
 

[crazy^millman]

38 minutes ago, ThickChips said:

Precisely - it CANT BE - so why is GOTO 1000 being executed? 

And again - CORRECT. Therefore, WHY is GT returning TRUE (going to 1000)?
 

That I cannot answer that is a question you will have to ask the machine builder. However why are you even trying to make that possible? What problem are you trying to solve by doing what you are doing? You have not once explained what you're trying to accomplish you just keep throwing out equations that make no logical sense and then want us to explain why they do or they don't make sense when they don't make sense to begin with. That is why JParis and myself are confused since what is the end game here? What are you trying to accomplish with this macro? Should it do what it is doing no it should not. That aside I never keep beating a dead horse I know something is not going to work then I acknowledge it will not work and move on. You have run how many tests and spent how much time proving it doesn't work. Okay what is the process and method you are trying to accomplish? What they end goal in mind then maybe someone can offer an alternative way to get there? You have proven it doesn't work, but then you keep asking your question in a way to have someone help you understand a process that should even be used to begin with. If you are trying to error proof something then you have to do something different.

You should have a if #601 = #602 goto 1000 then after that use your less than or greater than logic. Having the greater than or less than logic first when you are testing for an equal to process is the wrong way to develop your macro. Test the first condition which is are they equal to each other. If they are and that is not the desired result then produce your error or complete your loop. If they are not equal to each other then you start the process of are they greater than or less than to each other. If there is math else where that is subtracting or adding to #601 and/or #602 to make it smaller or larger then you keep doing the equal to check until they are equal to finish that part of the macro. The way I see the math and variables you are creating a infinite loop that it cannot solve. If may prove right or wrong like suggested because at 20 places past the decimal they are greater than or less than each other, but because you cannot see that far out you are assume they are what they are not. The machine control is not that smart. If needs more help to know what your end results needs to be. This really goes for any computer program. What are the inputs and desired output. With that then we solve the process to do the error checks we need.

[ThickChips]

Argggg, were beating a dead horse here. You must understand, I attempt to defend my position respectfully. Its not personal. @JParis and you have both helped me many times with CAM related issues. So, please know that I mean no disrespect to the forum as a whole or any members:

I posted to understand why GT is not behaving properly under my circumstances. And again, respectfully, the context of my program has absolutely nothing to do with the problem I have extensively laid out here, nor am I interested in sharing it. Do you recognize that a logical operator performing UNPREDICTABLY is a MASSIVE problem for computing? Could I patch this problem with a different operator and move on? Probably. So, then I ignore the aforementioned fact that an operator is behaving illogically and HOPE that it doesn't happen again? I am not interested in making my program work. I am interested in ensuring every program I write works when I use the GT operator. 

All of that ^^^ is based on the assumption that we both AGREE that GT is not performing properly according to the spec of the language. It is unclear whether you accept that premise. So, why do I accept that premise (that testing two equal numbers for GT returns false)? Why do I accept that premise?

Well, mostly--- because almost all computer programming language have this behavior. I know this for a fact, and I also tested my sanity in those other languages. GT operators perform FALSE when comparing two equal values. Its just... logical. Perhaps I am wrong, which is a real possibility. That GT in the RS-274 standard performs unlike other programming languages, but I doubt this. (Further, my tests suggest  this is NOT the case- it is a rounding or numerical error or a look-ahead error)

Lastly, if we can AGREE that GT is not operating logically in the FAILED tests, then we can talk about things like Look-Ahead or Rounding, which in my belief is heading more in the right direction.

I'll conclude: I have Haas working on this so I will report back with what the issue is. I appreciate the discussion. 

 

[crazy^millman]

Well hopefully they have more information to help you solve it without that extra information hard to do any more to help.

I agree none of it is working correctly, but I still thank I would be testing equal to conditions before I was testing greater than or less than. i would think about limiting the decimal values before anything just to rule that out. On a HAAS control i would have no idea where to start.

[neurosis]

I really wish we still had the popcorn emoji on the forum. 

I used my own. 

[Zoffen]

Another reason is possibly the HAAS NGC got the "wokeAF" update where 2+2=5 and .9000000 is not equal to .9000000 because you know, societal discrimination or racism, or sexism, but probably all of the above.