Hi
I would like to make some function or procedure which will contain :IN and :OUT parameters.
And I want to make motions as parameters.
I imagine how to make it with PTP and LIN, for example
DEF myProc (fdata:IN, pdata:IN, point:IN)
FDAT fdata
PDAT pdata
E6POS point
END
but how it works with SPL and SPTP SLIN
Do you know?
Or what is the best practice to reduce your code with repeating modules and objects. which are similar or identic and are needed only to get various parameters.
It is strange, but it does not look like other programming languages, not comfortable and, for example, in ABB robots it is solved very easily.
Motion as IN OUT parameter
-
pavlan1 -
March 26, 2021 at 8:22 AM -
Thread is Unresolved
-
-
I would lookup $bas.src which does this already for inline forms.
Fubini
-
I would lookup $bas.src which does this already for inline forms.
Fubini
Hi, thanks for the tip.
Did BAS.src have whenever a docu or everybody must investigate this .src himself how does it work?
-
Since its plain KRL everybody is expected by KUKA to understand it on its own. But it helps probably to study system integrators and system variables documentation.
Fubini
-
SRC file is a readable, plain text program file using KRL syntax. try it...
-
Thanks
I have made so, but my opinionKRL is a very strange language, I have ever used. Seems it from 80th
It was made very a long time ago, has an old basis, and guys who maintenance it seems old guys who do not want to build a new basis and they are waiting to go to retire,
No so big changes from KRC1 KSS1DEF MoveP(point:IN,vel:IN, fdat:IN, pdat:IN, cont:IN)
DECL E6POS point
DECL REAL vel
DECL FDAT fdat
DECL PDAT pdat
DECL BOOL cont
IF (cont) THEN
SPTP point WITH $VEL_AXIS[1] = SVEL_JOINT(vel),
$TOOL = STOOL2(fdat),
$BASE = SBASE(fdat.BASE_NO),
$IPO_MODE = SIPO_MODE(fdat.IPO_FRAME),
$LOAD = SLOAD(fdat.TOOL_NO),
$ACC_AXIS[1] = SACC_JOINT(pdat),
$APO = SAPO_PTP(pdat),
$GEAR_JERK[1] = SGEAR_JERK(pdat),
$COLLMON_TOL_PRO[1] = USE_CM_PRO_VALUES(0) C_Spl
ELSE
SPTP point WITH $VEL_AXIS[1] = SVEL_JOINT(vel),
$TOOL = STOOL2(fdat),
$BASE = SBASE(fdat.BASE_NO),
$IPO_MODE = SIPO_MODE(fdat.IPO_FRAME),
$LOAD = SLOAD(fdat.TOOL_NO),
$ACC_AXIS[1] = SACC_JOINT(pdat),
$APO = SAPO_PTP(pdat),
$GEAR_JERK[1] = SGEAR_JERK(pdat),
$COLLMON_TOL_PRO[1] = USE_CM_PRO_VALUES(0)
ENDIF
END
DEF MoveL(point:IN,vel:IN, ldat:IN, fdat:IN, cont:IN )
DECL E6POS point
DECL REAL vel
DECL FDAT fdat
DECL LDAT ldat
DECL BOOL cont
IF (cont) THEN
SLIN point WITH $VEL = SVEL_CP(vel, , ldat),
$TOOL = STOOL2(fdat),
$BASE = SBASE(fdat.BASE_NO),
$IPO_MODE = SIPO_MODE(fdat.IPO_FRAME),
$LOAD = SLOAD(fdat.TOOL_NO),
$ACC = SACC_CP(ldat),
$ORI_TYPE = SORI_TYP(ldat),
$APO = SAPO(ldat),
$JERK = SJERK(ldat),
$COLLMON_TOL_PRO[1] = USE_CM_PRO_VALUES(0) C_Spl
else
SLIN point WITH $VEL = SVEL_CP(vel, , ldat),
$TOOL = STOOL2(fdat),
$BASE = SBASE(fdat.BASE_NO),
$IPO_MODE = SIPO_MODE(fdat.IPO_FRAME),
$LOAD = SLOAD(fdat.TOOL_NO),
$ACC = SACC_CP(ldat),
$ORI_TYPE = SORI_TYP(ldat),
$APO = SAPO(ldat),
$JERK = SJERK(ldat),
$COLLMON_TOL_PRO[1] = USE_CM_PRO_VALUES(0)
ENDIF
END
-
KRL is a very strange language, I have ever used. Seems it from 80thIt was made very a long time ago, has an old basis, and guys who maintenance it seems old guys who do not want to build a new basis and they are waiting to go to retire,
No so big changes from KRC1 KSS1
When you have to maintain safety-critical systems that have to maintain backwards compatibility going back 40+ years, that happens. It's a feature, not a bug. And if you think KRL is old, don't look at Fanuc TP or Nachi programming. Or CNC G-Code, for that matter.
The vast bulk of the heavy development in any robot system is hidden in the deep infrastructure -- the path planner, motion control, safety interlocking, I/O handling, etc. It probably represents more man-hours of development and testing than the entire Linux kernel. The programming language is little more than a thin UI layer on top of that, effectively.
The language also needs to be easy to learn and use for end users who don't have the time to specialize in Just Programming. Unlike languages like Java, C#, VB, or even Python (all of which I have autodidactic experience in to varying degrees). KRL is a lot easier to learn -- the important parts are in how the robot responds to the language, which is where the hands-on experience becomes critical.
-
actually KRC1 is 1/4 of a century old. KRL is twice as old. yes, it was created at the time when predominant memory type was core memory and 1k costed $1000. personally i cannot think of any computing product from that era that is not just 'still in use' but actually a workhorse on one of the biggest and most capable robot platforms in existence. yet it is backwards compatible, friendly, easy to learn and you just created something using latest crop of instructions that were only introduced recently.
and i see that only couple of hours after suggestion was made to simply read BAS.SRC you created your own functionality.
and if you take your code, swap those parameter declarations into parameters list, replace IN with BYVAL, and replace OUT with BYREF, this will look no different than anything in most recent version of most capable programming software such as Visual Studio.
so what is it specifically that you find so strange or inconvenient?
-
And there are examples that modernizing the language was not accepted at all by the majority of customers. E.g. Sunrise used Java as programming interface and always got complaints about being non intuitive by the old guys. Also you where not able to reuse all vast program databases developed by customers over 20+ years.
Personally I think KRL is not to far from any other procedural languages like C/Pascal which is still is heavily used in for example safety applications. But I agree those languages are no longer taught much at universities and elsewhere. Unfortunately there is still is a wide variety of applications where all modern object oriented languages will fail. Sadly it is getting more and more difficult to hire good developers for such applications because its not as fancy.
Just a little remark from a 47 year old outdated "old guy"
Fubini
-
From KRL side of things, I suggest looking up structs (and using them to group parameters), enums instead of booleans (because you will want more than two values) and switch cases instead of If sequences ( because I lose a bit of sanity every time I have to fix someone else's code and see those existing for no good reason).
But if you want to save your sanity, don't try to do anything, but the most basic stuff with KRL. It's not a good tool for complex things. If you must have dynamically created code, create it externally and use something like Directory loader.
-
Wow, guys, thanks for this nice discussion
Maybe this discussion not for this topic. let moderator move it to another, but I have prepared my point of view.
I do not beg OOP in a robot, and I even think this would be superfluous.
I would like to see robots be more in line with standards PLCopen. PLCmotion IEC 63133, something like this.
You may not even consider examples with desktop languages here like C# Java or Python
For example, we can take PLC, like Siemens, Beckhoff, etc, the development of which should also take into account all these maintain safety-critical systems, the path planner, motion control, safety interlocking. cycle time. These all very difficult to implement, but it is done and it is done very well.
This is still accompanied by powerful software, in comparison with which WorkVisual is just a text editor, in which, for example, you can visually create Tool and Base that are synchronized with the config.dat file, but for some reason, the IO mapping names are still not synchronized in the same config.dat file with type SIGNAL
If you take Beckhoff for consideration, then it also has all the servos and all the difficulties of programming the controllers, but at the same time, they still manage to stick OOP there.
How many Linux kernels does the elapsed time in these companies correspond to then? 😊
It seems that the idea behind KRL was originally like you do not use system functions at all, but simply change system variables. that in the background react with appropriate actions.
I don’t believe that today a robot programming language is to be simple as only changing system variables and direct line-by-line programming to give access to plant personnel.
I don’t believe what buying a robot for 50-75k euro is for using 10 inline forms and a few inputs outputs.
A robot is still a piece of relatively complex and dangerous machinery. The software architecture, just written by the system integrator, usually is complex code that should be so beautiful and graceful to quickly navigate in it and be able to scale. KRL is definitely not about that.
I program mainly Siemens PLC and I started when the TIA portal was not there.
When in recent years, I began to implement robots in projects with a PLC, in general, working with robots turned out to be a pleasant topic for me, since I can say that the robot is already a half-finished product, which cannot be said about the rest of the PLC-controlled line. PLC has to manage security systems, handshaking with other devices, do stop-start, tracking all errors, move some servos of another supplier.
This means that it is very difficult to create a PLC but PLC is created.
So. why not take the time to improve the software shell of the robot or its core.
Now technologies are very much improved, we must keep up with this.
It seems KUKA developers do not want to do this, but simply continue to make money on what they have.
They have enough money to rewrite all the components. To spent many man-hours, many Linux-cores
Why they have money is a good example of the price of everything at KUKA.
Profinet option or EthernetIP option costs around 2000 euros. And that's just an option. which works over Ethernet. Just a protocol, just a program.
The Siemens advanced PLC is even cheaper, but it is hardware with PCBs and it is worth it in terms of production.
Why "40 years of backward compatibility" is needed for 😊
I don’t think it is necessary to satisfy people who don’t want to learn and grow up. It seems to me that these are only elderly people. which are much more than 47 years old. 😊 Others should be interested in evolution or this work is not suitable for them at all.
I always say a good example. If such people had worked at Microsoft, Apple or Google, we wouldn't have got so many quality products, many of which are generally free.
It just so happened that the first robot I began to use was ABB and it really liked me in terms of the programming language.
Using the MoveL example, roughly the way I implement it here, it is much more encapsulated there in RAPID. And it is already done as a system function or procedure, you just only call.
I started to read the BAS.src but I abandoned and simply expanded the Inline form instruction and replaced the parameters with input-outputs.
There are a lot of scattered files, variables, functions, that have formed from the fact that additions were simply imposed on the KRL core. As on old asphalt, a new one is put or on old wallpaper, a new wallpaper is glued. From here it turned out what happened. You can change something only by completely redoing it.
If you know Solidworks, then there are absolutely the same problems. The engine is very old, there are a lot of bugs and no one wants to stir up the kernel. But this is of course a different topic, but a similar example.
Why don't I do ABB robots, if I liked it so much?
The company where I work is KUKA partners, and therefore ABB will cost more, and ABB is mainly engaged in the work of ABB, and they, of course, benefit from prices. Therefore, I cannot convince us that we need to use ABB by default. Only if there is a direct request from the client to use an ABB robot.
ABB is a good example of what they did cool programming language and the software "all in one". KUKA is all separately and it is very inconvenient to have a separate CAD simulator that does not synchronize the program in both directions and the latest version does not normally load the config into the controller simulator at all. A controller simulator works in a virtual machine, which is not convenient for good and you also need a virtual machine license for your company.
The code editor is separate. All this is not convenient to configure and install.
What about licensing there.
This is a painful process that takes a very long time for the 20's. The license is confirmed by the person who needs to write by email. You also need to install license servers on your computer. Confirmations take from several days to 2 weeks. They have a few days to generate a license, like calculate bitcoin hashThis is some kind of bureaucracy, based on old stereotypes of doing business.
I have ordered a KUKA.xpert account and about a month still cannot get it.
You know, at some point I even started looking for where the KUKA developers are located, because I imagined that this was East Germany and that these were echoes of the USSR and Russia with its bureaucracy, where just such a method of paper licensing would be suitable.
But in general, this only applies to the software part and in no case other aspects of KUKA. Rather, everything KUKA has awesome design and awesome mechanics and kinematics, servo. In general, hardware. This means that they can do very cool if they invest in it.
-
i am sorry but that makes no sense.
you criticized KRL as a language, but never made a point what is it specifically in that language that you find inconvenient. then you try to make case that language should not be backwards compatible, it should be changed frequently. complete baloney...
purpose of language is to communicate something in a precise way. learning language takes time. there is a very practical reason to retain language as is and only make small and incremental changes that take long time.creating new language takes time.
this why English for example does not change over night. you don't wake up and suddenly everyone is speaking Swahili... and the next day, everyone is speaking Hungarian, then day after that it is Korean, Klingon etc...
and it is not just spoken language, it is all the literature, street names, monument inscriptions, product labels etc.
you never offered anything to support claim that KRL is a difficult or inconvenient language.
instead of that, your comments drifted away into another topics, like OOP, offline development tools, programming environment etc. even contradicting what was just stated.
"I do not beg OOP in a robot, and I even think this would be superfluous."
"take Beckhoff for consideration, ... they still manage to stick OOP there."
"I program mainly Siemens PLC and I started when the TIA portal was not there."
that seem to be the problem. you are in minority. most people dislike Siemens programming and will rather use anything else.
"Profinet option or EthernetIP option costs around 2000 euros. And that's just an option. which works over Ethernet. Just a protocol, just a program."
because you don't care to thing about what is involved. that those are not open, they are proprietary so you have to join the club, do significant investment, and pay royalties. but if you think this should and can be offered cheaper, go ahead, just make it yourself, sell it and offer support for 200 euros and everyone will buy your version (assuming it does not keep on changing overnight).
" and therefore ABB will cost (us) more..."
wait, what... ? aren't you all about free or lower cost things and kumbaya? i cannot believe that someone would spend time to make things the way you like and then charge you for it.
"ABB is a good example of what they did cool programming language and the software all in one.""KUKA is all separately and it is very inconvenient. A controller simulator (OfficeLite) works in a virtual machine, which is not convenient for good and you also need a virtual machine license for your company."
Again, this has nothing to do with KRL language. it is about offline programming tools and i agree that this could be more convenient.. a lot. But i did not know that ABB RobotStudio is free.
"This means that they (Kuka) can do very cool if they invest in it."
not just Kuka, same is for everyone (including me and you).
"I have ordered a KUKA.xpert account and about a month still cannot get it."
you don't need to order anything, subscription is automated and takes seconds to complete. there is no delays or human involvement. you just need to follow instructions and use "proper" email address, not gmail, hotmail, yahoo mail... if you use email from your work or school, subscription is instant, you get access right away.
-
Also as per your profinet example, kuka has to pay fees to the suppliers of these protocols, many of the tech packages licence 3rd party development, they are options, so it's optional if you want it or not.
For example fast send driver, I argued till I was blue in the face that it was far too expensive and I just wanted to play with it, sales guy told me just how much they had to pay per sale in license. Aka a lot. £10k might seem like a lot for a 32mb kop file but, that's what it is.
-
Sorry for a lot of text and a variety of topics in one post. I just shared my thoughts and experience of use and my vision of the situation
I guess I meant KRL not only as its syntax, writing, and use but also as an organization, structure, and architecture in general. How everything is broken down into components, how they are scattered throughout files. I probably don't know what to call it correctly 😊
A made example how MoveL. MoveP work in RAPID and how SPTP SLIN realized in KRL with inline form, you cannot use it indirectly easy
I didn’t say what RobotStudio is free 😊 . But for a lower price, it is all-in-one and works much better. Who uses, can confirm 😊 but the free version also can work well at least as a code editor, like free WV.
Being a partner makes it possible to get KUKA robot products with the best discount.
I wrote about paid access to KUKA.xpert. 😊
Of course, Siemens is not a God of PLC, but this is a giant in this sphere, together with Beckhoff, B&R. ABB
If people didn't use Siemens or Beckhoff or BR, what do they use? -
Also as per your profinet example, kuka has to pay fees to the suppliers of these protocols, many of the tech packages licence 3rd party development, they are options, so it's optional if you want it or not.
For example fast send driver, I argued till I was blue in the face that it was far too expensive and I just wanted to play with it, sales guy told me just how much they had to pay per sale in license. Aka a lot. £10k might seem like a lot for a 32mb kop file but, that's what it is.
I agree on what they of course pay fees for profinet. ethernetIP. ethercat. But it was an example of how they collect money, and they have a possibility to pay for development quality updates. One cannot say they have no money to improve something very well
-
Of course, Siemens is not a God of PLC, but this is a giant in this sphere, together with Beckhoff, B&R. ABB
If people didn't use Siemens or Beckhoff or BR, what do they use?Beckhoff and B&R are not very big players. Companies like Allen Bradley (Rockerll), Mitsubishi, Omron or Schneider have much larger market share. in fact Beckhoff is small enough that it is usually lumped under "Others"...
-
Oh,Ok. I always think about the European market where we work
-
well, it is a small world but it does stretch beyond borders of Germany
btw KUKA does check this forum. any wishes and improvement suggestions should be mentioned in pinned thread:
Software Request to KUKA - the robot forum bugs and wish list
while i was working at KUKA, there was mention of plan to streamline some of the things you mentioned. not sure how far they got or if it is something on a back burner. one of them was about integrating SimPro and OfficeLite into one product.
-
while i was working at KUKA, there was mention of plan to streamline some of the things you mentioned. not sure how far they got or if it is something on a back burner. one of them was about integrating SimPro and OfficeLite into one product.
Don't know how long ago you worked there. but at the beginning of 2020 one salеsmanager promised me in Oktober 2020 SimPro v4 might come. It might be an all-in-one cloud version with a year subscription. But something went wrong and they couldn't release it.
-
About the all in one solution for KRL/KUKA development, In the KRC2 ed05 days, there was another WorkVisual, called WorkVisual Process, that I never seen personally, but have a 3D environment in it.
And I remember seeing a thing called Visual Process in the first KRC4 brochures, from 2010/2011.
Basically, a 3D environment inside WorkVisual (the KRC4 WoV).
I always wondered why this didn't succeed further.
But, to be fair, RobotStudio is still light-years ahead of any other industrial robotics IDE/Simulator.