Bit of a coding Conundrum

Quote from SkyeFire

In KRL, it's easy to create an interrupt based on Boolean algebra of almost arbitrary complexity, and can be re-programmed on the fly. In RAPID, I had to edit the EIO file to create my Boolean logic down to a single virtual input, and use that to trigger my interrupt.

(disclaimer: the last time I did interrupt handling with RAPID was ~2006, so this may have changed since then. But KRL supported this as far back as the 90s.)

Industry is inherently conservative -- any change only happens when the advantage of a new method has a major ROI. So improvement happens in small incremental steps until a big jump happens, everyone jumps on the bandwagon, then things settle down again for a while.

(you think industrial automation is bad, though? Try nuclear, or medical -- yow)

Often this happens when new technology or methods reach a point where a new entrant into the market can compete with the established interests -- see Tesla vs the Big Three.

There's also another issue: the vast majority of robot or PLC code you produce will have to be maintained, and understood, by plant-level operators who spend so little time doing code (as opposed to electrical work, mechanical maintenance, etc) that any "cutomer-facing" code must be simple, plain, and easy to understand. And easy to modify, b/c there's never going to be a system built so well that no one ever needs to touch-up a point, or modify a variable.

More recently, UR provides a Python programing interface, but it's more than a little janky, from my experience, and lacks a lot of realtime motion/signal control that the Big Iron robots have (last I tried, doing a reliable spray/dispense on a UR wasn't possible). And KUKA has the iiWA, which is programmed in Java (why Java, it sucks) and only implements the robot as a library, but again, the implementation left a lot to be desired. I've heard that the KRC5 is supposed to be available with the Sunrise/Java setup in place of VxWorks/KSS, but I've not encountered one in the wild. And given that consistency across a plant and a company is a valuable feature, and most industrial robots get used for 5-10 years before being replaced, I imagine any migration is going to take a while.

Display More

Ahh you definitely don't have to do all of that to declare interrupts anymore in Rapid, Maybe they learnt from Kuka haha Its literally the same as KRL now.

As for the maintaining of things, wouldn't you agree that we should then be writing more step by step functions that operators can use with little knowledge? This is one area I would say Kuka is very weak on and also why i prefer strings, I wrote a commissioning module a while back in rapid, that basically gives you a graphical step by step guide to setting up a material handling system, all of the text was pulled from text files into arrays, the movements were from Nullframe basically so you would just touch up the Base via the interface and the rest is done. In rapid this is a very nice way to drive things.

In KRL, usertech's are obscure and not all all accessible for the majority of people so you really lack a lot of the great benefits that rapid gives you through the almost "iPhone'esque appy" nature of them. Although i suppose you might be able to achieve the same through MsgDlg's?

Quote from hermann

You are mixing things up.

1. User Interface: Here Kuka is really very poor, you need some expensive software packages and they always are something like hitting the eye from behind trough the chest. Here string handling ABB like is very handy.

2. Programming the logic, here as already stated i don't need symbolic access to variables during runtime. A different thing are symbolic program references, that's in many cases usefull.

For going back to you example in the first post. Just one Codeexample, you want to call a routine like:

Code

InterruptSet ('ON','GUN1','GUN2','GUN3')

Is the following one that much more complicated ?

Code

InterruptSet ('ON',GUN[1],GUN[2],GUN[3])

One more thing that's annoying me, if you acces variables or whatever symbolic during runtime:

You can create runtime errors just by a small typo, sometimes they can be unrevealed a long time, until a specific case happens. Then the exception/error is thrown somwhere in that fancy routine that converts the strings and trys to access the variable. Debugging this part is most annoying.

If you are accessing variables the 'old' style, the compiler/syntax check of the robot system reveals them before you start the program.

As my summary:

You can prefer strings, if you are happy with them, but sadly not on Kuka Robots (may be except the LBR IWAA, they use Java afaik).

I don't use them (except in extremely rare cases), and I hope that I never ever will have to make changes on a robot programed by you.

Display More

You wouldn’t have to make changes on a robot programmed by me  

Quote from panic mode

there is a pinned topic for feedback and suggestions to KUKA. feel free to add it to the list.

Honestly I actually do like KRL though, it has definitely grown on me considering I was a hardcore ABB guy, and it is pretty functional for almost everything I want to do bar a few annoying bits like above haha, plus it always manages to surprise me with new random Variables for things, It’s like a mystery box KRL does feel more clunky though, like if you dig techie stuff then it’s great for poking around with things. ABB’s are exceptionally well thought out, but they don’t have so much Charm, possibly in part because of how well Documented they are.

Quote from SkyeFire

I will mention there's one drawback to the ref-by-string in RAPID that I've run into personally. When coming cold to a large, complex software package that's not heavily documented and/or commented, the ref-strings make it much harder to track down the whole program flow. Because now instead of simply using RobotStudio's Find All References tool, or even doing a mass text search, you now have to do those and then track down every %"string"% occurrence in the entire robot, and backtrack, and then backtrack every line that sets a value to every one of those string variables.

Makes for a lot more work trying to build a flowchart. When you think you've found every way a PROC can be called, there's always a chance of some call-by-string you didn't catch calling it. Based on my experience, even when I have that option, I tend to use it only sparingly, if at all.

True, Definitely can see that. Although I want to add in all of this (maybe I didn’t actually say this) but I’ve only been talking about using strings to run background/system level stuff. Nothing that the average user needs to mess with. All of the front end stuff make as simple and readable as you can for sure.