the "Thinking ahead" only happens if you have C_Dis or similar behind Your movement because You don't want that the robot is stopping there
Not to be snarky but this is not accurate. In KRL even if you do not approximate a point the advance run pointer will move ahead if there is no arp breaking instruction. E.g. wait sec 0, wait for true or similar.
This is diffrent between brands, e.g. abb "fine" points stop the arp whereas z0 does not. In KRL no approximation does not stop the arp.
Set a message after each loop is one option.
Display variable either single or overview would also work just fine. You most likely want to declare the variable as global and change the name to something that will not be as generic and prone to namespace collisions or overlap.
If you only want to do a certain number of loops just use either for, repeat until or a while loop instead of an endless loop-endloop
if you want current tcp velocity lookup $VEL_ACT
if this is safety related use workspaces in safeoperation. I am assuming to some degree it is as you want to modify them on the fly. Modifying soft limits is not a good practice if this is at all safety related. Even if you choose to do it with soft limits you will have to handle what to do if the axis is over the limit and how to get out of it. And it will not fulfill requirements of any safety function as they can be modified with ease. If this is not safety related workspaces as suggested by fubini is a far superior solution
this seems odd. Robot cannot be profisafe master so it would need something else to act as safety master if you are using profisafe. Also robot requires exactly one safety interface so either cip, profisafe, fsoe or parallel safety (x11, x13) to my knowledge you cannot chop and mix these together..
Maybe the "safety module for smartpad" is a safety plc acting as master on profisafe?
no idea where those interrupts are declared, but e.g. calling moiton_XYZ() in succession will most likely fail as it only has one motion in it. And if you want to not stop the ARP it will at the very least complain when it loops back on the main run pointer
CodeBAS(#init) PTP p1 VEL= 100 % PDAT1 Tool [1] : FF2022 Base [0] LIN_REl { y 50}You always should post your real code, don't write him in the post manually. Copy the code 1:1.
Ehm.. BAS(#INITMOV)
also worth mentioning, if status changes you are moving through a singularity. And cp motions would generally be a bad idea for that 
Ptp will always beat Lin or atleast be equally fast in my experience. 2m/s is no where near max. Whereas 100% on ptp is max.
I usually put the speed by setting the speed from what is defined in $VEL_MA. As those are the maximum values. If you absolutely need the last squeeze of speed your robot can muster.
To set max linear speed (.CP) and orientation (.ORI1 and .ORI2)
Local variables i am less strict with. Especially when i use some sort of generic loop counter
The best loopcounter variable name, that would be a good topic also 
i usually name "burner" ints i1, i2, i3... never tried if a single _ works. Python atleast uses a single _ as a variable to dump this kind of not important or unneeded stuff into. Would be kind of obvious that an unnamed variable is ok to overwrite whenever 
I´m sure this is both well known and very well documented somewhere but I actually noticed it by accident. Previously I´ve been using variable -> overview or right mouse button in WV and monitor. Nice but what if I want to see any variable at any point in time and not just fill up the monitor window?
When using the debugging in WV (F5 hotkey) you can actually mouse over the variables when the program is run and they will read out their current value.
I really dislike _REL commands as they start over if you block select them, and just use the current position as the source. Calculating/offsetting the moves with the geometric operator is far more robust. Also using $OV_PRO to adjust the speed is not a very good solution for atleast 2 reasons, 1. the user can change it. 2. It happens when the advance run pointer runs over the command, not in between the moves where you put it unless you really force the ARP to stop.
$VEL.CP = .1
$ACC.CP = .1
SLIN XNoNamePoint1
;Move Z +1000mm according to used base
SLIN {X 0,Y 0,Z 1000,A 0,B 0,C 0}:XNoNamePoint1
;Move X +1000 & Z +1000mm according to used base
SLIN {X 1000,Y 0,Z 1000,A 0,B 0,C 0}:XNoNamePoint1
$OV_PRO = 30 ;<- This is a really crappy way of setting the speed.
;Flip A -90deg in tool coordinate system
SLIN {X 1000,Y 0,Z 1000,A 0,B 0,C 0}:XNoNamePoint1:{X 0,Y 0,Z 0,A -90,B 0,C 0}
;Flip A & B -90deg in tool coordinate system
SLIN {X 1000,Y 0,Z 1000,A 0,B 0,C 0}:XNoNamePoint1:{X 0,Y 0,Z 0,A -90,B -90,C 0}If you want the actual edge of the sheet to stand in place while flipping you just make/calculate a tool that has its coordinate system aligned and on the edge of the sheet. And use that tool while making those moves.
another tip would be using SPTP and SLIN instead of the old motions, you get access to $DIST_NEXT with SPTP moves (that may come in handy), TRIGGER WHEN PATH works on SPTP and also WITH statements can shorten your code a bit. Disregarding all the fancy stuff that the newer motion types actually bring.
hmmm... sounds like you've been down the KUEWEG path
as a matter of fact I have but KUEWEG is still quite good in that manner that there is actually very decent comments in it.
having been is similar situation many times, i think it would be a great idea to have such thread... a place where users can contribute list commonly used names and more importantly abbreviations in their native language. This would be very helpful to many, not just to robot programmers (PLC programmers, maintenance workers, users etc.)
Sure why not
I was hoping for a lot of response to this thread. As I believe it is in the programmers/developers nature to be picky about this stuff. Maybe I´m wrong and the rest slams their head on the keyboard and rolls an arbitrary number of times back and forth 
Please prove me wrong 
Thanks for the interesting response. I am a sinner in that way I was thought to gather as much of the global variables as possible and dump them in config.dat. But I´ve noticed this easily is error prone when reusing code (copy/pasting). I´m leaning more and more into modularizing code for easier reuse. One thing that goes against this is when you put your variables in several places and you e.g. have the same variable by accident declared both global and local. The local one will take precedence. And debugging this simple issue may give you some gray hairs in the process..
Regarding 24 character limitation imposes abbreviations, I´ve been thinking of a standard abbreviation list for the common stuff just to keep codebase similar. Like index=idx, number=no, tool=t, base=b, result=ret, response=res, location=loc, measurement=meas, available=avail, current=cur, pallet=pal, status=stat, message=msg, etc. But the real fun begins when even abbreviations is not enough and everything looks like you smacked your head on the keyboard 
Something I´ve seen others do often but haven´t really decided myself if I like it or not is datatype prefixes on variables.
Sometimes it feels like it would be good idea, but giving up the chars for this seems expensive at times. I have not seen any datatype prefixing system that really impressed and stuck with me. The example below breaks if one thinks to prefix e.g. Signals, bases...
b=BOOL
i=INT
r=REAL
c=CHAR
e=ENUM
s=STRUC
XP=POS, E6POS <-X purely for ilf compatibility
XJ or XA= AXIS, E6AXIS <-X purely for ilf compatibility
F=FRAME
PostPrefixes => Arr=Array => example: bArrAvailPal[iCurPal]=TRUE
Sometimes this would be clear but as you cannot possibly cover everything. Like I cannot imagine anyone wanting to conjure a prefix for the datatype KrlMsgPar_T 
Then it would be a mix of systems depending on the situation.
But on the other hand sometimes it would be nice to have this implemented on functions like if a function name was bMachineReady, it would be easy to know it returns a bool. Then again how often do you actually mismatch the type of the variable, not that often so point may be moot.
Prefixing local variables with underscore or making globals in caps. Does not seem very good as you can have different levels of scope with local variables. Or perhaps this would be good? Module local = __ and local = _ but I´m sure that would be mistyped more than once. Signs other than $ and _ is to my knowledge not allowed in variable names and one would ofc not like to use $ for user declared stuff.
One thing that is for sure, is that code and comments should be written in english. There is nothing worse than debugging or maintaining someone elses code that has abbreviations in a foreign language. That could be the topic of a pinned horror thread in this forum.
to revive an old thread in the hopes it might gain some traction again. One of the things i do regularly is place ilf's after a return in normal subroutines. That way you can use the generated points in raw krl, code looks clean, you dont get massive comment blocks in the middle of your code explaining what they represent. But the ilfs are never run. And all thought points are bunched up in one place.
Hi,
As there does not seem to be anything official on the subject I figured why not try to standardize this at the very least for myself. So i figured where better to gather intel than here.
1. Do you utilize any styleguide in KRL? Is it of your own making or a company standard? What does it look like?
2. Do you have "per customer" specific features?
3. Pascalcase, camelcase, snakecase, all caps?
4. Your own list of reserved keywords?
5. Suffixes and prefixes?
6. Pros/cons?
7. If you modularize your code with alot of global stuff how do you try to prevent namespacecollisions?
8. Where do you put your programs/libraries?
9. Have you found any exempts to your guide that it just does not seem to be able to cover?
10. Do you chokehold everyone that does not follow or do you accept some artistery? Is your styleguide meant to be a loose leash or an unquestionable set of rules?
also check available space if something is taking up too much space in R1 folder
where about in finland is this?
As the icons shown is notepad icons that hints at something. Have you tried restoring an old archive? Reboot with reload all files?
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.
Kuka nordic had some campaign a while ago offering upgrades at a discount. I'm not at liberty to disclose the prices but i recieved the cost for a upgrading a 8.3 to a 8.6 (without asking for it) for in my opinion a "decent" but not hefty amount.
Ask kuka and you will get an offer to consider at least.
I do not know of any restrictions in using wv 6 with a kss 8.3 robot. One thing i know for sure if you want to work using the programming&diagnosis tab in workvisual and not deploy a complete project everytime you change something kss 8.3.14 is reuired at a minimum. Or you will get the attached popup. If this is what you are after you could ask for a kss update within the same major version, to my understanding at no charge as long as you do the install yourself.
