I also heard this Java hegemony in KRC controllers some times, but I think KUKA wouldn't simply throw away decades of KRL accumulated knowledge.
I think a bigger hurdle is real time execution vs Java's garbage collection. Now that's a can of worms I wouldn't like to open.
Yes exactly realtime capable interpreters are rare and that is why usually robot manufacturers have to write them themselves. The difficulty in providing a language like KRL or Rapid is not the language itself but keeping everything deterministic and realtime. A simple problem in this context is for example dynamic memory allocation. Anyone used to programming in non realtime environments is surprised to find out about memory limitations of KRL. But dynamic memory allocation is a non deterministic operation. Hence in a realtime system most of the memory is allocated at boot time. Also this makes object oriented programming difficult.
Determinism also is one of the difficulties of the iiwa sunrise controllers where java runs only in the non-realtime. This is for example a reason why triggers or interrupts are slow in Sunrise and not deterministic as on a KRC with KRL.
how about some thing really simple - why not display in plain language how soon each type of maintenance will be needed?
intervals are mentioned in the log but they are not displayed in "maintenance handbook".
even if they were, it is unclear what to expect if no inspection entry is logged yet or when did the interval start.
I agree with everything in the thread - I think it's a brilliant idea. As a matter of interest, has KUKA been formally asked to comment on these suggestions so far?
I remember on the RCM that had editions of KRL after KUKA took over SIRL from Siemens, there was a COMMAND mode, where a movement could be executed before being input. It was of great benefit to augment jogging in a particular direction. One could type in PTP {X 30, A 90} for example, then press Ausführen and that's where it would go with the active $TOOL and $BASE, without having to input it in the program. It's a shame we can't have that back.
QuoteOne could type in PTP {X 30, A 90} for example, then press Ausführen and that's where it would go with the active $TOOL and $BASE, without having to input it in the program. It's a shame we can't have that back.
I am pretty sure this was at least possible some time ago with older releases using the Display > Variable > Single Window. You can enter fairly complex instructions here. Just have to remember in older releases you had to start the complex command with a = at the beginning if not simply trying to evaluate a system variable. For example entering = 3 * 5 would result in 15. Up to date controllers do not need the = anymore.
Having no access to any controllers anymore I can not try motion commands myself and check if it is still possible.
ABC 2-point should let you pick which axis and plane the points represent instead of forcing X axis and XY plane.
ABC 2-point should let you pick which axis and plane the points represent instead of forcing X axis and XY plane.
you mean you want to change tool axis from X to Z perhaps?
That could be a use case. In-fact I always end up using Z as my working direction. But it would also be helpful in cases where your tool's geometry just makes it easier to translate along certain axis.
Safe-Op to include the robot arm per robot, much more like DCS in Fanuc. I think newer versions of Safe-op includes more spheres, but it would be nice to have pre determined bubbles around the arm you can disable or enable.
And just to add it to the list.
While using Work visual 6 on the KSS 8.6.6 does not give the Profinet IO option for 64 safe io and xxx non safe io.
Just says Profinet io xxx.
Had to go through the pain to refer to the manual for a simple task to not include the 64 bits anymore and just use the non safe bits for Profisafe robots.
KSS03104 is an example of message that is not detailed enough.
It does not tell which workspace is tripped and no follow-up message to shed some light...
I recall seeing some others too, like program selection notification without name of selected program.
Same things goes for Program selected.... why not include name of the program that was selected?
Same goes for KSS02135, message "Name not declared" should include actual name that is the problem:
70. WoV Bug:
Using WorkVisual V6.0.16_Build0705
Using code completion (I have Smart filtering off) causes the program to crash when accidentally typing the dot before the array brackets of a structure array. Attached screenshot shows an example. PLACE_DIR is an array of FRAMEs in this case.
71. WoV Bug:
Using WorkVisual V6.0.16_Build0705
Copying a $WORKSTATE# causes a crash as well.
^ Guess this one is just me
72. Option to clear all instances in the Find usages and Search results zones of Work Visual
73. In the Programing and diagnosis tab of Work Visual, the option to hide or suppress the parts of the display file name & Search results / Find usages instances. The highlighted sections in the attached screenshots are what I'm talking about. It would be awesome if we could tie these parts to a check box in the options menu so you can tailor what you see to what you need at any given time.
74. Welding application KUKA.TouchSense related:
Reference points of touch sensing are currently expressed in World Base and not in the working base.
If for some reason it is necessary to physically move the fixture of the workpiece then when offsetting the working base to reflect that physical displacement, all touch sensing points have to be re-taught which is very very tedious and labour intensive when talking about large parts.
Why not having those touch sensing reference points expressed into the working base instead?
75. There should be an easy way to check (by KRL code) if some action was being performed by user. for example if touchup is requested.
76. Just tried new system with KSS8.7.2HF3 and UserTech 4.0.17. Several problems.
a) Conversion utility does not do the job satisfactory, XML format is not fun, just adds complexity, it is much more verbose and does not execute correctly. so i had to create my own KFDX templates manually... 
b) there is no simple and convenient way to edit KFDX on SmartPad. Not that drilling through lengthy paths was ever fun but now HMI editor does not even allow opening of the KFDX files - even for Admin.
c) Custom ILFs cannot be surrounded by FOLD/ENDFOLD. They work fine when placed in open block of code. For decades this was working as expected and now it is broken...
actually part-c is working. turns out that program contained incomplete FOLD/ENDFOLD and that was the reason for the message. this part works again 
NB
The templates catalog seem to be broken for quite some time and across several WoV versions. Currently using version 6.0.23 and this is still broken. Names are messed up too.
Using WoV 6.0.23 for some time now. While editing project offline, and making changes to one of Submit files, WoV crashed. This seemed to be pretty stable WoV version so far. And the curious thing it that always crashed when trying to copy variable name at specific line of code. So i renamed variable but that made no difference. Looked at crash reports and it is bunch of gibberish about null point exceptions.
The offending line triggering exception was always
KRC_Collision_Detected = $COLL_ALARMand it turns out that WoV really did not like the default:
SIGNAL $COLL_ALARM FALSEIt also did not matter that the signal variable was declared in own DAT file was clear enough
GLOBAL SIGNAL KRC_Collision_Detected $OUT[45]So modifying MADA to
SIGNAL $COLL_ALARM $OUT[45]fixed it and WoV did not crash any more. Even after changing the MADA back to default "FALSE", there was no more crashes.
Sigh...
The only reason was to use more descriptive names than some of KSS defaults.
Also it would be nicer to make all changes in one of own files than having to edit different MADA files in bunch of places...
For example KRC_EStop_OK is much better than completely meaningless $ALARM_STOP, $ALARM_STOP_INTERN etc. In fact those are inverted and that confuses hell out of people.
Pretty sure if this change was done on the KRC, it would take it, but WoV apparently cannot handle things like this. I am actually glad that i found it offline. I would be less happy that backup of a working project already running on a robot would contain something that can crash WoV.
As a foreword this may sound like someone poisoned my coffee but I do actually like KRL.
77. Upload without resetting program pointer would be nice every now and then.
78. WV´s intellisense is sometimes utter garbage, if you start writing an IF statement it won´t suggest any variable names until you have completed the IF statement correctly, which means jumping back and forth if you don´t remember your variables by heart.
79. Better overview of variables in the smart pad. Many times you need to take a peek at a variable you almost remember but do not get quite right. You will end up running to your computer, opening workvisual and looking up the variable name from there only to run back and check it. I imagine this as somekind of view where you could lookup user/system variables by e.g. declared type in alphabetical order. I do still want both the variables -> single and overview window. But I also want more.
80. This might have been mentioned before but block selection is a bit tricky when you cannot block select anymore after the arp has escaped the program you are in currently. Sometimes if the programs have few motions you have to put in a WAIT SEC 0 or a WAIT FOR TRUE to just be able to touch up the 1 or 2 points you have in there. Or why not make it possible to jump/block select whatever you want.
81. Visual guide to "alleviate" the estimation of how far the arp will escape from the currently selected line in WV. Would require an on/off setting as it would be annoying also at times, I imagine this would vaguely highlight code up until either the ARP has passed the number of motions currently set in $ADVANCE or it hits something breaking it.
82. if using quick messages available thru msglib.src there are several places where swrite is used which breaks arp. Regardless if you set VL_STOP=FALSE in message options.
83. more standard functions and operators, I do not mind coding but not having modulo, exp, log, floor division, etc. As STANDARD BUILT IN FUNCTIONS seems a little cheap at times.
84. Clean up time? I know compatibility is a big deal but ILF´s have changed between KSS versions. WHY do we still encounter poorly documented variables kept for "compatibility"? EXT declarations of programs, $APO_FAC, etc. every new programmer will start by looking at the latest SI and System variables manual and many times come up empty. Same with language, although I do like the exercise when I have the time. But I would like to be able to decrypt kue_weg.src without having a translator. Maybe the german comments are supposed to serve as cheap code obfuscators? 
85. ILF code is HORRIBLE to look at. 
Indentation is no fun with ILF´s either. Commenting out eg. a motion ILF in WV will trick you to believe the robot is actually running to that point when looking at the smart pad. I know it is more of a feature not a bug but anyway. My current workaround for this is to sweep it under the mat, I put a RETURN in every *.src that contains motions and hide the ILF´s there below where you can still block select them and use touch up if required, and then only program them in raw KRL in the real program.
86. Getting archives automatically with robotname and date. Without some intricate macguyver homebrew solution. I want this functionality out of the box.
87. Updating manuals when KSS updates. I would like to have manuals that are up to date when a new KSS is released. Currently latest System variables is 8.5 while KSS is 8.7. If nothing has changed why not publish it with a new sticker? Some manuals are not up to date with KRC5. eg. if you are configuring an external axis the KukaDriveKinematics catalog items are set to controller version=KRC4 and you will not be able to deploy the project to a KRC5. You have to build your own catalog item. And the manual is missing a few parameters as there are more parameters on KRC5 than a KRC4 but you have no where to look for them.
88. Stuff is spread out and stored a bit here and there and if you are new and do not know where to look, you are bound to screw up. A good example is interrupts from manual stated "priorities 1-39 and 81-128 are available.." Take a look at SPS.SUB on any new robot and holy cow priorities 91 & 92 are used. Same goes when assigning signals, I would like to get a good overview of this in an easy way.
