Or I need to use CONTINUE inside the function in every line?
Continue only has influence to the next line, your MyFunction() consist of many lines, so every line breaking the advance pointer needs a "continue" before.
..
LOOP
CONTINUE ; !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
IF diSTART_MISSION THEN
CONITNUE
wait for diENABLE_MISSION
CONITNUE
interrupt on 21
CONITNUE
SWITCH giNUMBER_MISSION
..that is one of the problems. there should only be one $config.dat file and it is in KRC:\R1\System
Sorry, don't agree. There always existed two $config.dat, exactly in those folders. But the one in \Steu\ normally is empty. Even if i never have used it or seen one with some content it looks like one can insert global variables. Maybe this is BMW standard, don't know that standard.
The sps.sub looks like standard one, or at least only very small changes.
Could it be that the PLC, wich is still installed and powered up and connected via DeviceNet is blocking something? All the in and outputs like gates and lightbarier are disconnected.
You can, and should comment out the devnet driver. Don't think that devnet can block something to prevent moving in T1 mode. Except the auto ext signals $move_enable and $drives_off, bind both to $in[1025].
I commented out the devicenet part in the iosys file once. Before i did that i saw all kinds of in and outputs with dutch description of its function. After i commented it out the io deccriptions went to something generic.
This is strange. The comments are just comments/longtexts, when changing iosys those comments normally don't change. Never have seen that behaviour.
Idealy i want to remove the cabinet with the plc from the robot controller.
In my opinion there is no PLC in the cabinet. That is an IO-module. It does nothing without a (Safety-) PLC connected to it. Share the module type number (the most left one, can't read it on the photos), or look for it at Beckhoff. You can see a Ethernet wire going from the module to the right side of the cabinet, where some more Ethernet wires end. Guess there once an ethernet switch was located, and a external Safety PLC was connected to that switch.
Those M_xxxx error numbers aren't good. Many of them only disappear after a cold restart. Did you ever try a cold restart? Or your system is missing the correct text files for getting the text for the message number.
Found the schematics to bridge X11 and X13 plug. My system is BMW E60 configuration if i'm correct. Did the wiring but something is keeping the controller from enabling the drives.
This should be enough to move the robot in T1 mode and to remove the cabinet with beckhoff stuff.
Continue has an effect only to the very next line, the next line in your code is an empty line, so continue has no effect at all.
Edit: you need some more Continue before every line accessing an input.
That's what signal SBH is for. Robot program can be active and as soon as robot begins to move he is stopped by safety. But anyway in your case I also wluld feel safer using the procedure you realized.
Why do you hard stop the main program while moving external axis? I would stop it by interrupt, wait for finishing movement of external axis, then return from the interrupt. In my opinion this would be much easier to handle
8.1 PLC pulse $EXT_START for 1000ms 8.2 PLC PULSE $CONF_MESS
You confirm messages after trying to start program, program doesn't start while error messages are active. You have to do it the other way round.
Change 8.1 and 8.2.
But anyway, signals like drive_on, ext_start and conf_mess have corresponding input like drive_ready, pro_act and err_msg. It's better to wait/handle those feedback signals instead of just pulsing the outputs.
I would like to see if i can overwrite the tcp velocity globally based on the value incoming in sps.sub.
Try it, and you will see, that it's not possible.
Variables for movements are only accessible from main interpreter. Second thing is, even if you can access the variable $vel.cp it wouldn't have the effect you want. The movements are prepared in advance with all parameters like tool, base, speed.. in a buffer after this you can't change any of the parameters.
The only thing you can set in Sps.sub, to change speed ad hoc, is the override $ov_pro or $ov_appl.
Or you can set the variable you use in main program for speed, but this has an effect just after the look ahead buffer has reached the time of changing the variable.
Those local registers beginning from 10001 are local registers and unique in every single TP program, even when they have the same number, they "don't know" each other. Each TP program has its own R[10001].
You have to make all network changes on the Smartpad HMI. Should be somewhere under menu "setup - Network" or similar. When there is no TAB for KONI, you are missing the option for KONI.
But should be possible to connect via KLI.
On some KSS versions there are settings in a xml file that prevent connecting from a normal PC via remote desktop. But don't remember the exact file and setting to change it.
Probably you can't connect Smartpad an PC at the same time. Only one rdp session at one time.
.. However, the TCPs do not stay in position perfectly when I rotate them around x and y...
Specify 'not perfectly'. You never will get a perfect result on a real robot. Would say a deviation of round about 1 mm while turning for +/- 45° is very good.
Probably mastering isn't OK. Checking witness marks also isn't a valid check for mastering. The visual check isn't exact enough for a good mastering. When someone did zero mastering in the past, the witness marks match, but the mastering isn't as good as from factory or with quick mastering (without doing zero mastering before). Same if a motor or measurement system has been changed.
The screenshots don't match. The first one shows different payloads for each gripper, the three other show the same for gripper 1-3. 
That's curious.
One thing is reading, understanding and following error messages. Your screenshot shows that you are trying to deploy project while robot is in automatic mode. Switch to T1.
Switching from T1 to AUT or EXT can also be prohibited when robot has safe robot option and has violated a safety zone like cell area.
..
I found a similar thread in the forum, but is a KRC4 - KSS 8.6.6.
..
And why not posting a link to the thread you have found?
.. but when I assign my position register to UTOOL the tool center floats off to an unrelated point ..
This is the expected behavior when assigning actual position of tcp to the utool. UTOOL represent the coordinates of tcp in respect to flange, when you change UTOOL coordinates you change the tcp, that's what you see when the green spehere moves.
What do you want to achieve?
Use *,1,*,*,*,*,*.
Not the number but the position of the '1' represent the group.
Had the same problem with my laptop, the very same cell (1:1 copy of mine) had no problem at all on a different laptop. So looks like an incompatibility of RG and graphic card.
Changing resolution of the imported stl (f. e. with Meshlab) made it a bit better, but didn't fix the problem complete.
Try:
If (DI[1]=ON) THENDid you try to unplug/replug the KCP/Smartpad?
Ever used the search function of the forum? 😉
