Display More
Warning: long answer ahead. I just thought I'd take the opportunity to highlight some of the benefits of Karel, as it doesn't seem like there are that many 'supporters' here on the board.Short version: you need: a text editor, option R632, roboguide or winolpc (ktrans.exe and related support files, really), the manual(s) and a way to transfer binaries to your controller (ftp, usb, cf).
[hr]
longer version:
You need four things to do any Karel development:
[list type=decimal]
- a text editor
- a 'compiler'
- controller support
- a brain
[/list]
1) can be any editor really. People here on the board have been using UltraEdit, Notepad++, vim, notepad and even the editor built into Roboguide. Syntax highlighting and completion depend on support by the editor for such things, and the availability of a suitable dictionary / language definition file (see here for files for Notepad++ fi). The Roboguide editor also supports highlighting.2) The controller only really executes something called p-code which is a form of byte code not unlike that of Smalltalk or Java. Karel sources (.kl) are converted into binaries (.pc) using ktrans.exe (on the command line) or using Roboguide (which uses the same libraries 'under the hood'). Final step is to copy those binaries to your controller. Roboguide can do this for you (send to robot), you could use ftp (which is what Roboguide does) or a usb stick / memory card. There's no magic, it's just a set of binary files that need to be copied to the right place on the controller.
3) is most important: without the proper options, you'll not be able to use anything you've produced in 1 and 2. As far as I know, you'll need option "R632 - KAREL" on your controller (at least, that is the nr it has on my R-30iA. May be different for older controllers). The dependency resolution during install of your controller should have installed all other necessary Karel bits.
Don't take 4) too serious :). Apart from information on Karel in general, having a small amount of programming experience really helps. Common sense too, as well as any Karel reference guides you can get your hands on. MARRC75KR07091E should be the document nr for the "KAREL Reference Manual", which I think may be considered the "bible" of Karel programming. Karel isn't difficult however, and you should not be discouraged by its sometimes archaic syntax or limitations.
With regards to motion (at least on R-30iA+), Karel is at a disadvantage compared to TP: apparently the motion planners on the Karel side haven't seen much development for at least a couple of years. Fanuc advises (read: almost requires) you to program al motion in TP. Karel can use things like Position and Integer registers to communicate and 'parametrise' motions programmed in TP programs.With some difficulty, you could probably get TP to do most of the things Karel supports. Karel is however a relatively high-level structured programming language (similar to Pascal), whereas I'd compare TP to assembly. Complex logic, data structures, information hiding and separation of concerns are much, much easier to use and implement with Karel. As soon as your application grows beyond a mere "pick up here, place there" kind of thing, I tend to go for Karel (however: motion is still TP).
One thing that TP cannot do, is socket (network) and serial communication: you'll always need to use Karel for that. If your project requires you to communicate with a vision system, or an rfid scanner, or anything that isn't already supported by Fanuc or an mfg that provides you with stuff to install on your robot (and you don't want to use a fieldbus), Karel can be used to implement an interface. Karel also includes support for vector math, terminal IO, interaction with the IO subsystem, creating menus and forms (think the textual GUIs on the TP you're familiar with, with dropdowns, input validation and real-time updating of display items) and dictionaries (allowing you to create multi-lingual programs).
Finally: of course Karel has its flaws, and some serious ones at that. Compared to many modern programming languages (even those used in other industrial robot controllers), its syntax is archaic, imposes ridiculous constraints (12-character identifier limit, strict requirements on file layout, no support for hexadecimal, no generic byte-buffer type, no proper string support, etc) and there is no support for conveniences like macros, proper include path / library infrastructure or a sane debugger.
hth,
PS: as one other example of something that Karel can do that TP cannot: (dynamic) web page generation. Afaik, the entire irVision interface is built on this. Even the pages part of the default web server option use it. A recent posting on this board (KAREL unit testing framework) shows how you can exploit this to implement some rather complex functionality.
Actualmente estoy trabajando con un robot de soldadura, el cual tiene funciones de oscilación, Tendrás alguna idea de donde puedo encontrar las funciones de oscilación para modificarlas??
Lo que trato de hacer es ver que tareas hace esta función de oscilación para entender como funciona. De esta manera podría crear mi propio tipo de oscilación.
"I am currently working with a welding robot, which has oscillating functions. Will you have any idea where I can find the oscillation functions to modify them?
What I try to do is see what tasks this oscillation function does to understand how it works. This way I could create my own type of oscillation."