You need for sure to use Karel in order to import the points, splitting the CSV file, then getting the coordinates and use PR as a buffer as Hermann stated.
But I recommend you to handle the logic part of getting the positions and writting the PR on karel, but using TP to move the robot through the PR positions.
Problem with karel is that you will not be able to debug and see the program pointer, so you will not be able to debug it easily.
You will likelly need to check the NUT/FUT and turn number on every position if you use J movements, if you use L movements you will not need it but you can run into problems of reaching an axis limit because robot will move with the shortest path to the next position. You may need to "unwind" the 6th axis sometimes.
Best way I think you can do this is to create 1 TP program, 1 Karel program and one BG Logic (this is needed, I explain later)
- On the first one, the "main" one do all the movements and logic to check if there are positions to move, use two buffers instead of one in order to avoid issues with circular buffers and the need to clear positions while in movement. You should also call the second karel program with "RUN" so it can run as a "background task"
- On the second one (the one called from first task) handle all logic to process the CSV file, but make it simple, something like this:
- Read one CSV point and put coordinates in registers R[190] to R[196]
- Increment a variable counting the number of points processed, this is to keep count of what point number you should check next.... maybe store it in case you want to start from there instead of the first point of the file if you abort program.
- Wait for the BGlogic to save that point to a PR (see next)
- Return to the first step.
- On the third program (the BGLogic one) handle a flag to copy data from R[190]-R[196] to the next free buffer position, then signal the second task to continue and provide the next point.
It may seem very complicated and the "BGLogic" program may seem excesive, but it has a reason. You CAN'T overwrite a PR register position using another task (even removing the group mask) without the task locking the motion group when rewritting the PR register)
This is the case if you do it using a TP program called with "RUN". I'm not sure if a Karel subroutine is allowed to overwrite the PR register while in motion but you can try, if not you will need to do this)
This problem doesn't happen if you use BGLogic to do that.
As you handle 2 buffers instead of one, when you finish with point buffer number one, switch to buffer number two and delete everything on buffer1 so the other task can fill it with new positions (this will be be easier to debug)
If you finally need a BGlogic program, the only way to check what is doing is using addictional registers to keep a "virtual pointer". You can also see the program pointer of additional tasks called with the "RUN" instruction through "Select -> Monitor" while on a secondary screen, but if KArel is used you will only see the current line number instead of the full code.... good news is that karel line number seems to match with the source code so you can at least see where a problem happens.
I've worked with circular buffers on the past, and handling the logic part in order to not overwrite positions while moving through the buffer is tricky, but it can be done, just remember any safety you add is welcome since the robot will be moving in automatic reading from a file... and a little error on the file processing can lead to a crash.
It's possible to do this, but it will require patience and work, also a lot of debug since you will experience issues for sure. Take it easy as it's not an easy task to do that.
. Best regards