Bit of a coding Conundrum

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

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 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.

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 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...

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 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 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 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 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.