What your calculations modify and what program uses as a base are two different things....
More precisely programmed motions do not care about value in $BASE since they all use own base value which remains unmodified
Thanks for replay.
So far I understand.
it's just that I did not succeed, to get the robot to go after my calculated positions
I would love to get som help on my way with it.
i have banged my head at this for a week 
You are writing calculated base to $BASE instead of BASE_DATA[2] that motions are using
I have tested changing this line.
$ BASE = fShiftedBase
to:
$ BASE_DATA [2] = fShiftedBase (this one i get error)
BASE_DATA [2] = fShiftedBase
BASE_DATA [2] = BASE_DATA [2]: fShiftedBase
which code is correct?
I've been sitting with this for a long time now it feels like, things don't look so clear 
neither.... i explained why your code did not produce any changes but .... that is not the only issue.
you are doing this in a loop and each iteration would alter base.
so even after single iteration base would be changed. worse, changes are cumulative.
golden rule is to not destroy data that you will want to use later on.
[size=1em]you could for example:[/size]
[size=1em]1. measure that base as base ten for example (BASE_DATA[10] is unmodified base). [/size]
[size=1em]2. leave your motions use base 2 (BASE_DATA[2])[/size]
[size=1em]3. and in your program before ILF motions add something like[/size]
[size=1em] BASE_DATA[2] = BASE_DATA[10]:fShiftedBase[/size]
4. make sure that teaching of points in your ILF is done when fShiftedBase is a nullframe
I've learned a BASE_DATA [32] as my original base
BASE_DATA [1] has no values. X, Y, Z, A, B, C = 0
The positions I learned are learned in BASE_DATA [1] when everything is set to Nullframe.
And when I test drive I get Workspace error.
I replace BASE_DATA [32] TO BASE_DATA [1]
It does not work completely but almost, it moves in the wrong direction;) and as you wrote it adds movement 100, 200, 300mm
But I'm not worried about that.
First run, i can se that BASE_DATA[32] and fShiftedBase moves in, BASE_DATA[1] but i get Workspace error.
I have a lot to learn I know! but must get it right!
i attached the new program
Important: to Teach the points PrePick, Pick, Exit, etc, there are two requirements:
1. Base 1 = Base 32
2. Pick position is for an object at the 0 location for both X and Y Counters
also note that "to teach" has different meaning from "to learn". those points are taught....
i give up! i´am stuck! i will never get it to work. 
I just made sure that fShiftedBase and fShiftFrame are at 0.
nXCounter, nYCounter is at 0
Base 32 is learned and made a copy of it to Base 1.
Made a Tuch up on my positions in Base 1.
And still get workspace error.
When I look at Base 1, the first round will be just like BASE 32.
but in the second loop it adds the whole of Base 32 again to Base 1, which gives me very high numbers of X, Y, Z 
Like I said, I'm noob at this but willing to learn
Okay, the problem is here:
;create shifted Base from Original Base and Shift Frame
fShiftedBase = BASE_DATA[32] : fShiftFrame
BASE_Data[1] = BASE_DATA[1] : fShiftedBase ; activate shifted BaseIt should be a single line: BASE_DATA[1] = BASE_DATA[32] : fShiftFrame
Because you shift B32, and then apply that as a shift to B1, you're getting the huge offsets.
Thanks for all the help!
I got it to work with this code. now i have to get the status and turn right
fShiftedBase = $NULLFRAME ; init to all 0s
fShiftFrame = $NULLFRAME ; init to all 0s
FOR nXCounter = nXMin to nXMax
FOR nYCounter = nYMin TO nYMax
fShiftFrame.X = nXCounter * rXSize
fShiftFrame.Y = nYCounter * rYSize
; activate shifted Base
BASE_Data[1] = BASE_DATA[32] : fShiftFrame
POS
ENDFOR
ENDFOR
Status and Turn should not be an issue, unless your pallet pattern forces the robot to cross through a singularity (for example, A5 + in one area, A5 - in another).
The simplest way to deal with this is probably to use a careful combination of LIN and PTP motions. While PTP motions strictly obey S&T values, LIN motions will ignore S&T settings in favor of maintaining a linear path. So if moving to particular sections of the pallet are causing the wrist to flip over, using a LIN instead of a PTP might resolve it. However, if the LIN motion suffers singularity issues, you might need to establish more than one PTP point as a good starting location for the LIN motions, and use IF statements based on the counters to control which PTP point you use. Also, LIN motions can "wind up" the wrist, which will then be "unwound" by the first PTP motion afterward. So be aware.
Another means might be to "strip" the S&T values from your points, but that would mean you'd give up the easily teachable points. Something like
DECL FRAME TempPos ; temporary position variable with XYZABC, no S&T or E1-E6
TempPos = xPickPosition ; where "PickPosition" was a point taught using an Inline Form
PTP TempPos : {X 0,Y 0,Z 100,A 0,B 0, C 0} ; move to 100mm above pick position
LIN TempPos ; move to pick position
; grab object
LIN TempPos : {X 0,Y 0,Z 100,A 0,B 0,C 0} ; move to 100mm above pick position
PTP xAbovePallet ; Inline Form taught position, will use fill S&T so watch for the wrist "unwinding"
