It's useless to philosphize about those numbers. Fanuc uses this system since decades, and may be will never change because they are selling their systems like hotcakes. Older ABB robots (S3) also had the numbers, that was the beginning of robotics.
Names would be nice. You can add a description to each point if you want to.
I think fanuc's robots are very wooden. Teach pendent is like 30 years old, but is fast.
Full ack.
But the example with home is not a good choice because on fanucs home always should be PR[1].
Don't forget, this industry was born several decades ago - technology, data terminals, software and connectivity was not as developed as it is today.
Unimate - The First Industrial Robot (robotics.org)
CPU, memory sizes, data processing were no where near the sizes, speeds of today and so by the nature of this, had many restrictions.
By using positional numbers, register numbers and preinstalled macro's, meant that the advancement was about as advanced as it could get and the applications of that period were easily achieved and maintained.
Some Kuka robots, you saved/loaded data in using a tape recorder, where Kawasaki used floppy drives.
Or do we share the same thought that KUKA/ABB's way is more user-friendly?
IMHO 'more user friendly' is very opinionated as opposed to a rule - and is influenced heavily by:
1. Where you lie in terms of introduction to learning to use these robots ie what decade.
2. Which robot you first start to use.
3. The kind of applications you are involved with - pre-existing/developing.
I hope vendors like Kawasaki, Fanuc and other vendors still continue to employ this type of programming as it rocks.
Operators from back in the day (who still continue to work with them), can still continue to work with them and are indeed experts in their field.
They do not need variable names and complex algorithms to setup, commission and maintain and this reduces downtime and increases productivity.
I haven't used a Kuka or ABB for over 20 years but I know when I pick up the teach pendant, I would consider them over complicated and difficult to use.
Whereas with a Kawasaki, because they continue to include this type of programming, whether it is 25 years old or 1 years old, I could program it without hesitation, I also suspect this to be the same case with Fanuc too.
I think one of the first to use a proprietary language was PUMA with VAL (This may not be 100% accurate).
... I think one of the first to use a proprietary language was PUMA with VAL (This may not be 100% accurate)
Don't know when VAL was introduced, but I used BOSCH robots (nowadays they don't exist anymore) in early 80's. They had a complete language with variables, structures lke "if then else" "switch case" and so on. One funny feature was that there existed localized compilers (englisch, german, french ...) so the german programing language used: "wenn dann sonst" instead of "if then else" and so on.
They had multitasking, and they where able to control multiple mechanics with one controller. What a pity that they didn't survive.
Even for "pendant programming", KUKAs allow you to name points as you like, which I always found handy. Or, it'll throw an auto-generated name at the point (P1, P2, P314159, etc) if you don't want to bother.
Beyond that, it gets a bit vague. Doing a math instruction on a KUKA requires you to actually type the math out, whereas on the Fanuc it's all menu-driven. OTOH, the Fanuc method quickly becomes maddening if you have to do very much of it -- it's slower than molasses in a deep freeze.
I always preferred KUKAs, and felt handcuffed by Fanucs, but that's b/c I spent 90% of my time writing advanced code, instead of simply programming points. I also know KUKAbots much better, so there's probably some familiarity bias there.
It really comes down to who your "target market" is. If all you want is point programming with maybe the occasional bit of math or other programming, with "hand-holding" menus, then a Fanuc may suit you better (I would advise getting the ASCII Upload option, though). If you want to do advanced programming, or start integrating odd hardware, you hit a point where KUKAs are more flexible (at the cost of requiring more work from the programmer). As you climb the complexity ladder, you hit the "buy more manufacturer options" point faster with Fanucs than with KUKAs, at least in my experience.
My theory:
I believe Fanuc modeled portions of their TP language on assembly, because it is simple.
I think the reason they use registers, and the reason they are named registers, is because registers are used heavily in assembly language. A typical CPU has various registers that can store values, and are always at fixed address, so that is why I believe Fanuc went this route.
This makes the barrier to entry for the average plant guy on the floor pretty low. For example, they don't have to know about the various types of data types, or what a variable is, or how it is scoped. Here are your registers, you get 200 of them, they store numbers, you can get to them from any program, have fun. Same for PRs, but they are positions.
This is a double edge sword though, as while it easy to understand, TP lacks (or lacked for a long time) some of the more basic program flow structures virtually every language since the 70s has possessed. This also makes doing anything complicated in TP a pain, since you have to have work around the limitations of the language. This also tie's into SkyeFire's point where you need to buy an option to do anything complicated.
I agree especially with the very last part of your post Nation. The way I see it is that is a big part of their business model. They reel a customer in with a less costly robot, and then nickle and dime you to death with options. "Oh, you want to do that, sure, just buy this option", and so on and so on. That, and the fact that they put a price on Karel programming options also, unlike ABB's rapid.
Don't know when VAL was introduced, but I used BOSCH robots (nowadays they don't exist anymore) in early 80's.
I am the newbie here for sure. Cant imagine how would programming a robot in 80's feel like.
You guys are great! Have shown me quite a few angles to view this matter. "Unfriendly to advanced programmer -> a more profitable business model." is a new idea to me!
I think the reason they use registers, and the reason they are named registers, is because registers are used heavily in assembly language. A typical CPU has various registers that can store values, and are always at fixed address, so that is why I believe Fanuc went this route.
Close, but I suspect there's one extra link in that chain: CNC controllers. I don't know for certain, but what I've seen strongly suggests to me that Fanuc robot controllers and CNC controllers are almost the same beasts, under the skin -- the robot controllers are just "CNCs" with lots of extra axes, and a more complex kinematic model. CNCs came along first, and Fanuc is pretty big in the CNC controller space. And CNC controllers started out a lot closer to early microcontrollers than computers -- G-Code still looks a lot more like Assembly language. I'd be willing to bet that, when Fanuc decided to get into robots, they grabbed their existing CNC controller and just added more axes. There's obviously been some divergent evolution since then, but the roots still show.
You can see this even more explicitly with Nachi robots, which actually still (well, the last time I programmed one) use a programming language that looks more like mutant G-Code than even TP language does.
I am the newbie here for sure. Cant imagine how would programming a robot in 80's feel like.
You guys are great! Have shown me quite a few angles to view this matter. "Unfriendly to advanced programmer -> a more profitable business model." is a new idea to me!
Like any good story, there's a lot of historical reasons. Very early on, robot programming looked more like computer programming, in large part b/c teach pendants were primitive as heck -- more like a cheap pocket calculator than anything else. A 3-line, 20-40 column LCD display was a luxury in those days.
So, the early programming model was that you would have an actual computer (often running a custom OS, this was when DOS and CP/M still had competitors) attached to your robot (probably by RS-232), or an early 8086 PC "offline". You would create your programs in a primitive text editor, leaving placeholders for robot motions, then compile the program and transfer it to the robot (RS-232 or tape -- it was a Big Thing when robots started getting floppy drives). Then, on the pendant, you would scroll (slowly and painfully) through the program to reach one of the motion placeholders, jog the robot to the desired position, and "fill in" the actual motion point.
I don't miss those days (disclaimer: I only came in on the very tail end of those days), but by golly, you learned things about the nuts&bolts -- kind of like modern programming courses that force you to learn at least a little C (not C# or C++) and maybe Assembly, so that you have an idea of all the magic that modern compilers and IDEs do for you, and where to dig when the fancy-schmancy tools let you down.
Close, but I suspect there's one extra link in that chain: CNC controllers. I don't know for certain, but what I've seen strongly suggests to me that Fanuc robot controllers and CNC controllers are almost the same beasts, under the skin -- the robot controllers are just "CNCs" with lots of extra axes, and a more complex kinematic model. CNCs came along first, and Fanuc is pretty big in the CNC controller space. And CNC controllers started out a lot closer to early microcontrollers than computers -- G-Code still looks a lot more like Assembly language. I'd be willing to bet that, when Fanuc decided to get into robots, they grabbed their existing CNC controller and just added more axes. There's obviously been some divergent evolution since then, but the roots still show.
Its the reason they changed the naming pattern from RJ3 to R30iA, to commonize the naming scheme with their CNC line. One of the Fanuc salesmen told me this though, so take that with a grain of salt. Now it is diverging again, as the CNCs are up to 32i, while the robots are still at 30i.
Its the reason they changed the naming pattern from RJ3 to R30iA, to commonize the naming scheme with their CNC line. One of the Fanuc salesmen told me this though, so take that with a grain of salt. Now it is diverging again, as the CNCs are up to 32i, while the robots are still at 30i.
I've read this story about FANUC CPU naming convention somewhere. A FANUC brochure, if I recall correctly.
As far I know, there was a R-J3iC series, after rebranded to R-30iA, to match CNC naming.
You would create your programs in a primitive text editor, leaving placeholders for robot motions, then compile the program and transfer it to the robot
That's how I do it now. I find it much faster than to program by menu.
Just no rs232 or tape. Its all over ethernet now.
That's how I do it now. I find it much faster than to program by menu.
Just no rs232 or tape. Its all over ethernet now.
Oh, yes. But the industry as a whole mostly moved away from that, at least during the late 80s, 90s, and 00s. If you were doing typical auto-plant style point programming (which was more than 90% of the market), you did everything from the pendant. And most people using the deploy-from-computer model were either high-end developers (usually at the robot manufacturer) creating option packages, or you were working in some odd edge-case in general industry that needed the "fancy" programming (aerospace, CNC-type programming, CAD-to-Path, etc). As a result, the IDEs for writing robot code were pretty poor for a long time (and still are, honestly, compared to tools like Visual Studio and Eclipse). We also had the rather strange branch of "robot programming" using 3rd-party simulation tools, which would generate program code in their own "intermediate" language, which then needed a brand-specific postprocessor to convert into code the robot could actually use.
Every web developer and IT specialist I know takes one look at the state of programming and deploying on robots, and starts backing away slowly, making hex signs.... 
Edge case, general industry, fancy programming is all I do.
Would be cool if Fanuc developed a proper IDE.
Very interesting insight in this discussion. I know very little about Fanuc arms & programming. I'm looking to expand and as popular and pervasive as Fanuc robots are, I'm not sure now they would be a good fit for me.
QuoteEdge case, general industry, fancy programming is all I do.
Would be cool if Fanuc developed a proper IDE.
I've done plenty of that also. Just curious: what is your favorite choice of robot brand for this level of work?
Don't know when VAL was introduced, but I used BOSCH robots (nowadays they don't exist anymore) in early 80's. They had a complete language with variables, structures lke "if then else" "switch case" and so on....<snip>...They had multitasking, and they where able to control multiple mechanics with one controller. What a pity that they didn't survive.
You would very much like the Staubli VAL3 language and the integrated & powerful IDE Staubli Robotics Studio SRS. VAL3 does all of that. I haven't punched keys on SRS in years, but it was awesome for complex programming tasks.
I have standardized on Fanuc robots for all applications. If there is complex data manipulation or other external devices to control, I do all that in a PLC.
I've never had an industrial programming task yet that a combination of a PLC and Fanuc robot cannot achieve.
