it's simple program with Karel to move a fanuc robot 2000iA avec un contrôleur RJ3iB.

Salut tout le monde!

Hi all! I know that it's hard to start in Karel's code and i want to give a small code to move the fanuc robot in JOINT with coordinates POSITION.

this my code:

PROGRAM NAME OF PROJECT

%CMOSVARS

%SYSTEM

%NOBUSYLAMP

%NOPAUSESHFT

%ENVIRONMENT MOTN

%ENVIRONMENT sysdef

%ENVIRONMENT REGOPE

%ENVIRONMENT STRNG

%NOLOCKGROUP

%NOABORT=ERROR+COMMAND

%NOPAUSE=ERROR+COMMAND+TPENABLE

%ALPHABETIZE

%INCLUDE KLEVKEYS

%INCLUDE KLEVKMSK

%INCLUDE KLEVCCDF

%INCLUDE KLIOUOP

%INCLUDE KLIOTYPS

VAR

c: config

i: INTEGER

jnt0:JOINTPOS

rnt0:POSITION

rpos0:ARRAY[9] OF REAL

cur_current: JOINTPOS

status1: INTEGER

uframe: POSITION

utool: POSITION

BEGIN

$UFRAME = $MNUFRAME[1,1]

$UTOOL = $MNUTOOL[1,1]

uframe=$UFRAME

utool=$UTOOL

--***********************************************************************************************************POINT0 same process for other points

CNV_STR_CONF('NUT,0,0,0',c,0)

rnt0= POS(79,114,203, -179.169, -0.053, -52.294, c)

cur_current=CURJPOS(0,0)

POS2JOINT(cur_current,rnt0,uframe,utool,0,c,rpos0,jnt0,status1)

WITH $SPEED=100, $MOTYPE=JOINT, $TERMTYPE=NODECEL MOVE TO jnt0

END NAME OF PROJECT

Have fun.

because the all informations to use TPP brings me back at buy RobotGuide and I can't program in TPP to transfert many points with .CSV in my FANUC robot. I tried to program with TPP and I asked help for this but I did not success to get informations for this one.

But if you can help me with an example to do this one, frankly it's so good.

i can use Karel with NotePad++, the corrector of syntaxe Karel dowload on internet and the compilator Karel in the old version of WinOLPC that use Ktrans.exe.

Quote from HawkME

Why do you need many points from a csv file? What is your application?

I am an intern in a small business for my second year of university in automated production engineering. I was asked to program a FANUC robot that I discover for the first time. No one in the company knows how the FANUC robot works. I have to cut a piece with an ultrasonic blade. I need to import about 200-300 points into the robot with many precision. I was asked to program in Karel but when I arrived on this forum I already had 2 months of work with the Karel language. I preferred to continue with the Karel language so as not to re-start all over again from the beginning.

Quote from hermann

Fanuc recommends not to use Karel for movements since many years.

For your task, you need two paralleI running programs. A Karel program that reads the csv file, pushes the values into a ring buffer of PR[], let's say PR[10] to PR[30], use two R[] as pointer into this buffer, where one points to the last written buffer entry from Karel.

A TP program that moves to those PR[], this program uses the second R[] to show the last moved PR[] so the Karel program can fill up the next positions.

is the file read with a special function that delimits the data in the CSV file?

Quote from PnsStarter

I am sure that you do not need the ASCII upload function on RJ3iB.

So you should be able to upload '.pe' or '*.ls' programs to the controller without problems.

With '$ASCII_SAVE=1' you can save the programs from the controller as a text file.

(Or make Backup via FTP).

So you don't need Roboguide!

Display More

I will search how to use this function correctly.

Quote from HawkME

Just my opinion, but in 2 months you could probably have had the entire thing programmed in TP.

Does the set of points change? Why do you need to read them from a csv versus storing them all in the robot program.

I know but I focused too much on Karel programming as if it was THE solution for me. the points remain fixed but I did not know how to concretely import the data from a CSV file. I am just trying to understand how it works to analyze data from a CSV file and how to use PR[] in a karel program to take data from the CSV file. can I just have an example where karel reads data from a CSV file to put it in a PR[] or another way to do it?

Quote from Shellmer

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.

Display More

Thank you very much for yr explication! seriously you are so good!

Quote from Shellmer

No problem, this forum has helped me when I started at robot programming a lot, I still learn things with the questions and responses from all people who is here.

So it's time to return a little bit of knowledge.

Another thing I recommend you is to try to keep all simple on the robot program.... if you can split a Karel routine into little subroutines and handle all logic and karel calls on a TP program, it is better to do that.

That way you can debug your program better, also it makes maintaining the code easier to all people who comes next (but make sure to add remarks of what do every input parammeter if you can)

At least for me there is no benefit in obfuscating the code of the robot. People will get angry at you when they ask who programmed the robot if they can't see anything.

Having the program in a "black box" with karel is awful... but yeah, it "ensures" that they will call you to do any modification, but the most probable scenario is that they call you one time, and with the next cell they will not call you anymore.

I hoped they provided a way to optionally "unlock" the karel files when compiling in order to allow to see the content and program pointer, but I think it will never happen since there are options for all sort of things, even for loading/saving programs on ascii format, that should be a free option like the majority of other robot brands.

Just ensure to save the .kl files somewhere since the .pc files can't be decompiled and when you need to make a change if you do not have the sources you are screwed.

Display More

Yes !