Could you please provide guidance on how to populate the position as a configuration string?
Below is a minimal code example of how to set a cartesian position's configuration string
VAR
status : INTEGER
MyCartPos : XYZWPR
BEGIN
CNV_STR_CONF('NDB,0,0,0', MyCartPos.CONFIG_DATA, status)
IF (status <> 0) THEN
-- handle error
ENDIF
END MyProgHave you tried looking for the task with GET_TASK_INFO, and then aborting the task (number) with ABORT PROGRAM[n]? Haven't worked with it myself, but just looking at the description from the Karel Programming Guide it seems this might work.
I don't know of any built-in methods either. But if you express your cylinder as a cone without any slant and create your own wrapper function/program to convert conical to cartesian coordinates (with the cone parameters saved in registers for example) you will only have to do the logic once right? Or am I missing something?
Yes it's possible to map the override directly to a value on a GI. However this is a direct mapping, whereas Nation's BG-logic example allows to have more complex control of the override by letting the robot check with for example if the teach pendant is enabled or not. This means you can allow the GI to control the override only if the TP is disabled while allowing manual adjustments if the TP is enabled.
So basically, if you're gonna go for a simple direct override control: map it using the Override Select option. But if you want to be able to do more fancy stuff, do it yourself in a BG logic program.
If you have a backup in roboguide already, you can save all programs on there (Teach > Save all TP programs) and either save them as *.TP or *.LS (the latter only if you have the software option to load LS files on the robot).
Alternatively, if you have an AOA (All Of the Above) backup (instead of an image backup), you can browse through the backup directory and find the GET_HOME program there.
You are using R[3] for both the outer FOR-loop, and your count variable. Line 25 will increment the FOR-loop variable to 5, causing the FOR loop to terminate because R[3] outside its limits; while it has only passed through the outer loop once.
So just use two separate registers for this and it should execute 12 times as expected.
EDIT: Try to walk through the for-loop structure in STEP mode to follow what the registers are doing in each iteration of the for-loops. That should get you some more insight into what was going wrong and for-loops in general.
From the KAREL manual, CNV_REAL_STR documentation. Sounds like your string is too small to contain the number.
If you're changing the frame number, yes, but not if you're changing the frame itself.
To change a user frame, you can use the system variable $MNUFRAME[1,n] where n is the frame number. This changes the actual value of the user frame (datatype POSITION). Whereas if you only need to switch between two pre-defined user frames, use $MNUFRAMENUM[1], which selects which user frame is currently active.
As for executing executing TP programs, look into using the KAREL built-in CALL_PROG(prog_name, prog_index).
You're selecting the program in one screen, then looking at the data in the other screen; that's where you're going wrong. You need to select a program in the same screen you want to look at its data.
So let's say you want to run PROGRAM_A while monitoring its variables in the second screen:
If you already are in double mode (showing select screen and KAREL Vars) the KAREL Vars screen remains blank if you select a KAREL program.
There's a way to work around this.
The 'DATA > KAREL Vars' will show you the variables of the program currently selected. However, you can select which KAREL program's variables to view per screen (note this is only for viewing variables, running programs is still only allowed in the main screen). So simply open up the 'select' menu on your second/third screen, select the program, press 'enter', and go to the data screen.
NB: take note when you're doing this in roboguide, that the KAREL program may still be selected in the second/third screen, and will therefore be somewhat hidden (won't show at the top of the tp). This may lead to the weird behaviour where you're compiling a currently opened program: build output will say the translation is successful (ie no compile errors), but still fail the build. Has happened to me more than I care to admit 
I have a set of positions saved in a TPE program, of which I need to be able to choose which position the robot is at. Comparing the current position with each of these and to check if one is within limits works fine, as long as I'm using FINE motion instructions. I need to be able to use CNT values as well; which would trigger the comparison before the robot has actually reached its target position.
How can I obtain the robot's destination position including its orientation? I have found the system variables $SCR_GRP[1].$DST_POS_X/Y/Z, but I'm missing variables for the WPR values. As long as my reference positions are spaced apart far enough it should be fine. But I'd rather not take any unnecessary risks, because why wouldn't this information be available..
Yes there is, I'm using the Alarm Code List operator's manual. You can try looking for it from the fanuc website, or I can send it to you (just dm me an emailaddress or something).
I'd say the 'USER' screen is a useful one; when debugging I print a bunch of statements with variables or without variables (print statements are 'checkpoints'). Also it's sometimes useful to throw in a bunch of PAUSE instructions, so you can cycle through the program while watching the associated *.VR file on the second screen. I think there's also a system variable that can toggle the 'STEP' functionality to also step through every single KAREL instruction (but I feel like this is a little overkill; my personal preference is adding manual PAUSE instructions).
Oh and always check for any built-in's status variable and report back if it's unequal to zero.
That's all I have to add really.. it's not much so I wholeheartedly agree with the sentiment that KAREL is a pain to debug... I suppose it encourages you to keep programming in a structured way 
Single Point Of Contact
I wasn't aware of the abbreviation, but seeing your search result made me think it's probably Single Point Of Control, so close..
A *.VR file is a variable file, and can't be executed. My guess is, it used to be a KAREL program (*.PC file), which has a variable file 'behind the scenes'. The *.PC file contains the logic of how the associated variables in the *.VR file are used. When you delete the KAREL program, you're left with the variable file (unless you delete this one too of course).
So yes *.VR files show up in the select menu, but only to be able to look inside/store values in the variables.
It's possible to round (up/down/nearest) a register value; but it sounds like something else is going wrong, and it would be a waste to try and solve it by throwing away sub-millimeter precision with rounding the values.
If I put a value of 754.999 in a register, and throw that register into a PR's axis, the value is correctly copied (and not rounded). Can you describe what you are doing exactly, and at what step the rounding of the value is introduced?
Do you want to only use TP, or is KAREL an option for you as well?
And what is your desired output? The way you represent it as an array of 0/1's can be done with KAREL, but you could also use a series of 16 flags if you can't use KAREL for example.
Anyhow, you would want to do logical AND comparisons with the values for the individual bits. In KAREL this is very easily done. With only TP at your disposal it's definitely possible as well, but it might not be very readable.
Maybe I'm misunderstanding: the issue is you're seeing reversed direction of motion in a linear external axis between your real world setup and a backupped/mirrored roboguide cell right?
We've noticed that some electrical outlets didn't conform to the standard, and had their phases reversed. With 3-phase AC motors this could mean the direction is reversed as well. I'm not sure if this is applicable to the motors you're using; but just throwing it out there.
That should work, I open files on UD1/UT1 with the 'AP' accessor and start writing immediately after and it works fine. I used to write to the 'PIP' device as well, and I'm pretty sure I used the same approach there.
If you're worried something went wrong you should add a check for the status after opening the file (IO_STATUS(pipe)). (Or maybe you already had that but just omitted it from the example..)
