parametric question

[PaintItBlue]

I am having problems getting the vf-2 to accept some different amounts for variables, any explanation would be welcome. Machine is in inch increments if it matters.
these are being changed then checked , it is not a string of reassiging #800 commands consectutively
#800=X.x(input)/ X.x (output checked at variables screen using m01/opstop)

#800=100.52/100.519997
#800=100.5 /100.5
#800=1000.5/1000.5
#800=1000.52/1000.520020
#800=1259.08/1259.079956
#800=1259.8/1259.800049

going to try this on the mini mill and see if i get the same results, but not till tommorow, it's tied up with job.

[gar]

080104-1644 EST USA

PaintItBlue:

I do not understand this either. How old is your machine?

I do not believe my machines convert 100.5200 into a floating point for storage. It looks like a possible error converting to floating point and then back again. In a system like a CNC machine I would think that data moves, adds, and subtracts would be done in integer arithmetic to avoid cumulative rounding errors. With todays processors and the travel range of machines I would even think multiply and divide would be in integer.

I will try to remember to run the experiment on one of my machines.

Maybe your numbers are too big. Try 30.52 .

.

[gar]

080104-2032 EST USA

PaintItBlue:

I tried the experiment on our oldest HAAS, 93, VF-2.
63.52 stores as 63.520000
64.52 stores as 64.519997

#100 = 10.052 this stores ok
#101 = #100 * 10.0 reads out of #101 100.519997

Looks like a floating point rounding problem. So do not use large numbers.

For positioning on a VF-2 why would you need such a large number.

.

[PaintItBlue]

did some more tests, it seems to be an error with more than 4 places in the whole number AND more than 2 places in the decimal, or xxx(3).xxx(3)

all ok:

1.5=1.500000
10.5=10.500000
100.5=100.500000
1000.5=1000.500000
10000.5=10000.500000

errors show at xxxx(4).xx(2):

1.51=1.510000
10.51=10.510000
100.51=100.510002
1000.51=1000.510010
10000.51=10000.509766

errors show at xxx(3).xxx(3):

1.515=1.515000
10.515=10.515000
100.515=100.514999
1000.515=1000.515015
10000.515=10000.514648 <<wtf??

no errors:
1.5=1.500000
1.51=1.510000
1.511=1.511000
1.5111=1.511100
1.51111=1.511110
1.511111=1.511111

[gar]

080105-1347 EST USA

PaintItBlue:

Visit http://en.wikipedia.org/wiki/Floating_point for some background.

I think you should give up on the idea of using one variable location to store two different values.

Since you want to work with paired values consider putting the pair in adjacent memory locations.

You could do this internal subroutines instead of external routines,

#800 = 1.054
#801 = 8.
#802 = 1.255
#802 = 8.

and so on.

There are indexing means that will allow you to access a pair at a time.

You do not need to manually load these at the machine. Create a different program or multiple programs that contain the values. Such as

%
O100
#800 = 1.054
#801 = 8.
#802 = 1.255
#802 = 8.
M99
%

You could also include the random G52 offsets in here as well. I won't go into how at this time.

A different one
%
O101
#800 = 1.525
#801 = 7.
#802 = 1.010
#802 = 9.
M99
%

In the main program you call O100 or which ever one is to be used at the start of the program:

%
O500 (main program)
M98 P100 (this loads the values into #800s)
(rest of your code)
M30
%

.

[PaintItBlue]

I will take your advice and give up on the 2 variables and just builds a table like this:
#801=major fixture 1
#802=pitch fixture 1
#803=minor fixture 1
#804=major fixt. 2
#805=pitch fixt. 2
#806=minor fixt. 2
etc etc

Your way works better with some excel spreadsheets i have been working on for jobcards. It is going to be a dedicated machine pretty much so i going to used the 154p1-154p99(? forget high range) for the ~25-30 perm fixture positions we will have.As parts get larger we get fewer orders and they are larger pcs 1-2 runs). Although i did use your g52 example to write the logic and loops counts for the intial x,y web centerline probing and for the lockdown plate clearance holes, and the part lockdown holes.


I did get it working by fixing the dual variable, then integer *.001 to reduce 1259 to1.259 and then find the .08 remainder[original 1259.08 - 1259.(fixed) * 100 to change .08to 8, then rounding this number, the amount of rounding errors was maybe .000345 which isnlt enough to affect the .xx places i would be using ~05 to ~56 for pitch. I will take your advice and give up on this idea. i definatley wouldn;t risk these results for moevment commands.