Posts by Ash

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.

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 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 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 panic mode

I think 99% of software is bloated and inefficient. hardware makers are reaching some physical limits and cranking out new CPUs with more and more performance is harder and harder. big part of my computer resources are taken by OS alone, regardless what if anything is actually used.

years ago one could get operating system with GUI on a floppy disk. today single image in a desktop theme take more space. then there are zillion of services for things nobody used in 10 years and yet they all are running all the time.

Ok so that sounds actually rather damning of the industry to be honest, because I've often seen there are some very real limits to this field also, which probably accounts for the increasing amount of bloatware as people try to differentiate themselves or indeed expand themselves. But then what is the answer, where do we go from here? We can put everything in clouds, or on remote computers, but ultimately the control and sequences still need to drive a robot from a to b? Dunno mate. Beyond me

Really what the industrial sector in this field needs is a single unified robot architecture and language then standardised software solutions that you MUST use, period. They give you all of the logic and frameworks for any solution, download it, install it, off you pop. In theory I shouldn't even be writing anything, if it weren't for the fact that a large majority of places end up with poor installs with bugs and holes in the logic because of how subjective it is.

Quote from panic mode

uh... no. that is very simplistic view that only looks at one aspect which is the end effect.

there is a cost to everything. high cost and low cost are not the same.

parsing strings to extract integer or boolean value may look fancy on the surface but it is more complex and takes more resources (CPU time, memory, interrupts...). all resources are limited. some platform may expose more that others but programmer still need to be aware of this.

If you want to take it to that level sure, but in a world where processing power generally doubles every few years (for now) is processing power really going to be an argument in this, or should it be?

Again its not about looking fancy, yours and skyefires examples yesterday were equally as fancy if you're not familiar with code structures?

Quote from SkyeFire

I wrote a fair amount of RAPID code years ago, and a lot of KRL code over the years, and there have been times in KRL when I would have liked to have RAPID's ability to access variables, or call subroutines, by string. But it was never a show-stopper. Similarly, I can't get the degree of fine-grained Interrupt handling in RAPID that KRL gives me, but there are still ways to get the job done.

One thing to remember is that, for robot languages, the 1st, 2nd, and 3rd priority of the system engineers is always going to be safety, reliability, and motion control. Adding nice bells and whistles to the programming language (and all the testing involved to guarantee those new features have zero impact on the critical functions) is probably going to be down around 7th, maybe 9th.

90% of the robot code out in the world is probably never going to need these features. And 90% of the remainder is probably generated by the robot manufacturers as purchasable option packages. Indirect referencing by string is obviously something that KUKA, Fanuc, Kawasaki, and Nachi never felt any market demand for -- ABB is, as far as I'm aware, the only brand that supports that feature.

Intrigued by your assessment of fine grained interrupt handling? There are many more methods for error handling in ABB's I've found as opposed to Kuka's who seem more linear?

Definitely agree about safety and reliability naturally, although motion is such a limited aspect of robots, it just seems to be the get out of jail free for people to funnel the majority into being pendant jockeys. Ultimately your code and sequence will be what enables motion to either work well or perform poorly.

I personally think 90% of the world probably is just stuck with antiquated ways of industry thinking. Which is why little has moved on in 20+ years apart from faster processing and more gimmicks.

Quote from hermann

I wouldn't say that.

It contradicts to ABB programing guideline.

For me it doesn't make sense to access variables by a string that contents the name of the variable, never ever had the wish to do it. It makes programs unneccesary complicated.

If you insist on accessing variables by a string during runtime, just use ABB robots .

JM2C

Definitely doesn't contradict any Guidelines as far as I'm aware, and no, ill stick with creating whacky things in Kuka's and then whinging about why it doesn't work as it should haha

Quote from panic mode

Well I certainly can't say about ABB, have not worked with it... but i would have to side with hermann.

I do have (and continue to) program on numerous platforms for almost 40 years (personal computers from 8-bit to modern 64bit multithreaded, FPGAs, MCUs, dozens of PLC brands, robots, databases and what not...) and with many programming languages (many variants of ASM, Basic, C, C#, Java, VB, Pascal, LD, FB, IL, Graph, Euphoria, VHDL, SQL, Verilog, Lisp, Diesel... and many i do not recall). For past few years almost exclusively developing in .NET (very little robot programming).

So maybe my experience is still limited and i have not seen it all, but... in my humble opinion, I would say that what you are describing is far from common practice.

Just saying...

Display More

Fair enough, Swings and roundabouts, I guess I quite like stringy things haha

But I would disagree with Hermann, I think strings actually can give you a more clear and concise dimension to things when used properly. Complexity is definitely in the eye of the beer holder

Quote from panic mode

each company chooses what to add or not add to their products. there are differences in hardware software and programming environments. this makes translation of program from one platform to another not so straight forward, one must consider what is available or reasonable depends on target platform.

One should not ignore that all mentioned platforms are developed independently, by different companies and of course they are all proprietary. There is no universal programming model for all of them. Yes there are similarities but there are differences too.

Similarities are usually at basic level and differences are larger the more complex and less common features are. So using I/O and math are very much related, regardless of platform as this is common and basic feature. Things look very different when one starts comparing other things such as extended safety, collaboration, etc.

When it comes to programming, using large objects, string manipulation, pointers, recursion, etc may be considered costly or risky on any platform, specially when source code is in plain view and average user is not trained but may want to make changes. More so when risks involve property damage, injury or death. I don't know what the driving ideas and discussions about implementing this or that were at each company but i can tell that accessing variable by the string in another variable is not common or seen as essential. And every added feature, big or small, carries a cost of long term support and reliability.

Display More

Problem is there's a lot of grey and subjectivity in it. But also none at all. I hear what you're saying and agree, there are of course subtle differences. But i do genuinely believe even as you go more complicated the underlying sequences and events will be largely the same, almost to the point i would say yes there is "almost" a universal programming model. You have a main , some initialisation sequences and positional checks, a program number, some handshakes with ancillary equipment (or other robots) and an end of cycle. That accounts for probably 90% of any system. How you approach that within code is the subjective part, you still need to fire outputs for things, you still need to wait for inputs. So whether via strings or just $OUT, the end result is the same.

I would say accessing variables by strings is fairly common practise in ABB's, certainly from a systems module point of view where the average user won't/shouldn't be tinkering. The only reason it doesn't seem as prevalent in Kuka's (Apart from elements in the MsgLib) is clearly because Kuka's aren't as advanced in this area. Which is fine, but that doesn't mean Kuka shouldn't develop this further because it is very useful if handled correctly in a proper sequence.

Quote from Fubini

No its not. First of all in KUKA there are two program pointers (advance run and main run) that come from the architecture underneath and requires some understanding of the underneath concepts. I am not talking about implementing features into the real-time controller kind of know how.

Maybe this helps understanding my view: English and German can express totally the same information but use totally different rules on grammar. If what you are saying would be the case every language in the world would have the same grammar. Would ease things definetly but will never happen.

Basically the same in ABB's then, naturally they have an advance run also as they have to. So what you're saying is the syntax has a few quirks in the way its structured that means you have to code in a certain way? So with previous examples, ok in a Kuka you have STRUCS, In an ABB you have RECORD, In Kukas you have $ERR, In ABB's you have ERROR_RAISE, You have a motion pointer and and an advance run pointer. You move into routines and functions and shuffle bits around. If i am building a system in an ABB i will do it almost in the exact same way in a Kuka or fanuc only you have to alter minor details to accommodate for slight syntax differences (More so in fanucs i would say). Do the systems then communicate and operate the same?

Quote from Fubini

But not the underlying real-time controller archicture which will be totally different and this to some degree also must reflects on the programming language.

But who really needs to use or understand the real time controller, apart from nerds ? What relevance does it have to how you build an automation system? Does the robot have a program pointer that moves through various sequences and functions? That is common in all robots is it not? So how the code is structured or built is irrelevant because you have to fundamentally build the logic the same?

Quote from Fubini

Well this is as always a very personal view. Its whatever you are more used to is always the best one. Its the same as C/C++ is not Java and is not C# although they all serve similar purposes.

Fubini

Well sort of agree to disagree there, i think control logic and how you handle it will be the same for any robot? Nothing changes in how they physically perform, operate, or the kinds of things you need to handle. Its just you say tomayto, i say tomato.

Quote from SkyeFire

At the end of the day, programming in robots and PLCs is halfway between CNC machine G-Code, and 1970's-era pre-PC computer programming. Sadly, one must adjust one's standards of code snobbery to fit the programming environment.

See you say that, but I stand by the fact that half of the mystery with kuka's just doesn't exist in ABB's because of how user friendly and well documented the code is. Plus you mentioned about complexity, I've been around far more complex stuff in ABB's because, for example how you can build strings and jump the program pointer around in error handlers. Kuka's i can more believe are 1970s era/machine code, than ABB's. Fanuc's well i think they are a pascal derivative aren't they, depending on which of the languages you use there, TP, Karel?

Quote from SkyeFire

You could literally simply create an array of STRUCs, like so:

Code

STRUC MyStruc CHAR String[], INT InterrupNumber

DECL MyStruc MyArray[10]
MyArray[1] = {String[] "IntNum1", InterruptNumber 1}
MyArray[2] = {String[] "IntNum2", InterruptNumber 2}

And so on. Then, you could FOR loop through the array, using STRCOMP to compare MyArray[Counter].String[] to your desired string, then DO INTERRUPT ON MyArray[Counter].InterruptNumber when STRCOMP returns a TRUE.

Although, honestly, I'm not sure why your program is so complex. You could literally write an entire subroutine that was just:

Code

DEF InterruptSet(InterruptNumber :IN)
    INTERRUPT ON InterrupNumber
END

Just what are you trying to accomplish with all that program complexity?

Oh and just to add i actually did initially write the routine as suggested with a huge long switch case. But hey I'm a code snob. Shoot me

Quote from panic mode

; define some nice names for your interrupts so you don't have to hardcode them

; this is easier to remap and makes code more readable

DECL INT isrCheckForHeight = 13

DECL INT isrUpdateSomething = 87

DECL INT isrReceiveData = 120

; same goes for I/O, use signals rather than hardcoded IO addresses

SIGNAL HeightSensor $IN[27]

; then program can look like

INTERRUPT DECL isrCheckForHeight HeightSensor DO StackHeightMeasure()

INTERRUPT DECL isrReciveData ....

;....

InterruptSet(#ON,isrCheckForHeight ,isrReceiveData,,isrUpdateSomething )

but using arrays this line would look more like

DECL INT MyIsr[10]

MyIsr[1]=isrUpdateSomething

MyIsr[9]=isrReceiveData

MyIsr[3]=isrCheckForHeight

InterruptSet(#ON,MyIsr[])

The key difference is that you can use index to access each value inside your sub, rather than using FOR loop and all the string circus only to activate/deactivate one ( first) interrupt 10 times.

using structures... well SkyFire beat me to it

Display More

Ok nice, some interesting things for me to look at for sure Cheers buddy.

Quote from SkyeFire

You could literally simply create an array of STRUCs, like so:

Code

STRUC MyStruc CHAR String[], INT InterrupNumber

DECL MyStruc MyArray[10]
MyArray[1] = {String[] "IntNum1", InterruptNumber 1}
MyArray[2] = {String[] "IntNum2", InterruptNumber 2}

And so on. Then, you could FOR loop through the array, using STRCOMP to compare MyArray[Counter].String[] to your desired string, then DO INTERRUPT ON MyArray[Counter].InterruptNumber when STRCOMP returns a TRUE.

Although, honestly, I'm not sure why your program is so complex. You could literally write an entire subroutine that was just:

Code

DEF InterruptSet(InterruptNumber :IN)
    INTERRUPT ON InterrupNumber
END

Just what are you trying to accomplish with all that program complexity?

Ok fair doos and i get where you're coming from, does make sense. Although i didn't really think its that complex. Your method sounds as complex comparatively. Again, more so it wasn't strictly just about the setting interrupts it was the process of using string variables to structure things. Maybe its somewhat of my bias since i come from ABB's originally and their String handling is definitely a lot more on point.

Quote from hermann

Did you read my post complete?

It is not possible to read the value of an integer via the name of it during runtime.

You should use arrays.

Oh sorry yes i understand you now. Yes i had to find out the hard way about GET_SIG_INF (Which does work really nice). But its kind of frustrating, there must be a way somehow to read it?

I wonder if it would be possible to have a dummy SIGNAL then using GET_SIG_INF you input the string, Output the value and then read it back again? Sounds feasible haha

How did you mean use arrays?

Quote from panic mode

well, if it works for you then all is good.

but KUKA does not have normal string type, char arrays are used a substitute and there are various limitations with the data type itself and with associated functions. those tings are usually not mentioned or documented anywhere, or some of documentation is not even right, so it it a lot of trial and error involved...

haha Don't i know it

There are other ways to achieve this by the way, i am aware, BUT its more the principle I'm trying to establish as doing this stuff via string arrays is bloody useful.