recording realtime cartesian position in a file on roboguide

I think without karel you have no chance.

What's the final application of the data you will gather, and what is the time sample rate you intend to use? That will help me determine what is the best way to do what you want.

We will likely need Karel to do this, or an additional option.

Since you're gonna be writing to a file, you're bound to use KAREL. If you're using KAREL anyways, you might as well use the system variables for the current position ($SCR_GRP[1].$MCH_POS_X/Y/Z) directly, instead of pushing these into a register and then reading the register value in KAREL.

You can create a KAREL program in which you:

1) open the file

2A) periodically sample the time; a timestamp used to measure elapsed time in microseconds is available via the GET_USEC_TIM and GET_USEC_SUB functions. This result wraps after 2 minutes, but if you're only interested in relative time you can work around this. If you require the system's absolute time in timestamps, use the GET_TIME function, but I doubt this will have high enough precision. What I prefer to do is log an absolute timestamp of the system's time once when starting, and from there start logging the high-precision timestamps that can wrap.

2B) in the same loop, sample the robot's position (using either the system variable directly, or by reading register values), and write the values to the file. In my experience the FANUC's 8ms cycle time can be reached if you're simply logging a position to a file.

I read in your other posts you're interested in the positions during execution of a program. Then at the start of your main TP program you need to start the KAREL logging program in the background (RUN your_KAREL_prog). Note that your main TP program will not exit until the background KAREL program has finished. So be sure to add some condition to abort the logging loop (use a flag for example, which is easily set from the TP program).

It looks your KAREL program should work, yes. But there are some style improvements I'd personally make:

ROUTINE init_cond
BEGIN
IF OPOUT[1] = ON
THEN
ENDIF
END init_cond

This routine doesn't do anything; might as well delete it unless you were planning to add some functionality in here.

ROUTINE write_file
BEGIN
WRITE FTP_FILE ($SCR_GRP[1].$MCH_POS_X,',')
WRITE FTP_FILE ($SCR_GRP[1].$MCH_POS_Y,',')
WRITE FTP_FILE ($SCR_GRP[1].$MCH_POS_Z,',')
WRITE FTP_FILE ($TIMER[1].$TIMER_VAL,CR)
DELAY 100
END write_file

I'd move the DELAY statement outside of the routine, and into the loop in the program's main body. If you need a very precise sampling time of 100ms it might be easier to regulate it this way. If you don't care about a very exact sampling time this should be fine (but subtract a few ms that goes into the logging).

Note my earlier post where I mention some other options for timestamps. No need to change this though if it works for you.

WHILE TRUE DO
init_cond
write_file
ENDWHILE

This is an endless loop. One option would be to use a FLAG to enable/disable the logger. The first line would then become WHILE FLG[1] DO so it will automatically finish the program once you set F[1]=OFF in your TP program.

As for the TP program: the CALL statement will block the 'parent' program until the other program is finished, whereas the RUN statement will start running the 'child' program in the background while the 'parent' program continues. So change the call to:

F[1]=ON
RUN DATARECORDER(100, 20000, 'UD1:logfile.dt')

! do whatever you like while the logging is active here
! ...

F[1]=OFF