KRL Styleguide

    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?

    1. yes mainly to help with deploying and customizing functionality. it is mostly code and data structure, with few strategic comments. almost always packed into libraries, but sometimes stripped down or parts even moved into main program (special case). all IO are defined as signals allowing for easy remapping or substitution when needed. I do not like the idea of placing own declarations in $CONFIG.DAT. it is not just more dangerous due mistakes of copy/paste but it is slower to deploy and slower to lookup. i consider that a system file and do not want to touch it unless i really have to.

    2. no... unless there is no choice (for example adding something to a system with existing programs). but that is quite rare, vast number of systems are using new robots and most clients have next to no robot experience anyway.

    3. personally i prefer Camel case. don't really use constants since one cannot use them in declarations of arrays for example (which would be nice). i would be ok with all caps for constants - but that's about it.

    4. we have preferred way of naming things, names are usually composition of location+device+function+action. i really and absolutely hate names that are not explicit, choosing good name is important and requires some planning. for example input name AirPressure is absolutely terrible (or CncChuck or RobotGripper etc.) because it is not obvious what it really means. AirPressureLow, AirPressureOk, AirPressureIsLow,AirPressureIsOk etc are better choices - names need to include action or status in the name unless type is ENUM. Signal of function name is not supposed to be ambiguous or open to interpretation or guessing. Btw. I also really dislike some of the names used by KSS. the most obvious examples are some of signal names that come up in AutoExternal configuration - as emergency stops or anything with inverted logic. $ALARM_STOP, $ALARM_STOP_INTERNAL, $DrivesOff. First two do not even resemble emergency stop. worse - the meaning is inverted (negative logic) - they are TRUE when no EStop is active and FALSE when EStop is pressed. I would have been so much better if the signal was called something like $ESTOP_OK.

    5. why not... i see no problem with outCncChuckClose or inCncChuckClosed or similar. KSS also uses $ as prefix for system variables. i just do not like ambiguous and inconsistent names.

    6. Descriptive names are in general longer. This makes them harder to type when making changes on the teach pendant, also user may change the way name appears by altering the case. it would be nice if KSS would automatically convert the case to match the declaration. we can dream...

    7. very good question, more so since there are challenges given KRL naming convention limitations. This means that names have to stay within 24 characters, one cannot declare own types using words that are used by KSS etc. So when there is a lot of things to declare, things quickly get ugly. one way out it is to make use of complex variables like arrays and custom types then each part of the structure can be 24chars and that helps improve program readability. Something like

    Pallet[ActivePal].Location = #CNC1

    Pallet[ActivePal].Status = #MachiningInProgress

    etc.

    And if same or similar names already exist, add prefix or sufix to differentiate them. Sooner or later 24char limit will pose a problem and in that case one may not have choice but to use abreviations. In this case one should always also provide comment with format description so that code remains maintainable.

    8. I tend to keep all files we create in suitable folder, normally with company name. Any libraries are placed inside it into a subfolder. Normally all of our roobts run in EXT mode so main program is confirmed and if needed selected automatically. In some cases it may be needed for user to select and run certain program. in that case i still prefer to display dialog and ask what is they need to do to (bring robot home or run some other program, etc.).

    9. No because guide is just a guide. it is not something strict that cannot be changed or adapted when need arises. Ultimately goal is to have machine perform some job, not compete in how strict set of rules shall be.

    10. Absolutely not, we communicate with everyone involved (team and clients), explain what is planned how we think it should work or be used etc. This is not a one way street, we also carefully listen to all feedback, specially process flow and any user interactions, concerns or anything they may not like. As stated we are in business of making things work, not making things frozen in time and showing the same product down everyones throat. Libraries can have revisions too if we have learned something new or need to improve something. But we all try to provide common look and feel so that users are not thinking that there are dofferent versions, also documentation can be more or less the same. For example library function may be adapted of have completely different inner working but for user or one of our techs, it is a black box, they just use it - they do not need to understand how that functionality is accomplished internally. The sideeffect and advantage here is that they actually try to stay out of it. Librarires are there to provide blocks that can be used and reused on many projects. I have no intention of altering MsgLib etc to make messages logged to DB or change order of buttons for dialog etc. I just make my own function that has desired properties and behavior.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

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

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

    Quote from Hes

    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.

    hmmm... sounds like you've been down the KUEWEG path :winking_face:

    i have been working on code that was written in French, Spanish, German and few in Japanese, Chinese etc.

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

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Quote from panic mode

    hmmm... sounds like you've been down the KUEWEG path :winking_face:

    as a matter of fact I have :grinning_face_with_smiling_eyes: but KUEWEG is still quite good in that manner that there is actually very decent comments in it.

    Quote from panic mode

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

    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 :fearful_face: Please prove me wrong :smiling_face_with_halo:

    Interesting topic, I don't consider myself a real software engineer (it is only a small part of my resposibilty's). So for me this topic is more of a learning experience then that i can contribute something substantial.

    I don't have specific rules/guides in need to follow. i am the only software engineer in the company so i can decide for myself what i do or don't do. all the software stays internal so i also don't have to worry

    about customers or external engineers.

    Generally speaking for naming signals i will use a prefix like: IN_Spindle_chuck_open or OUT_Spindle_chuck_open. Local variables i am less strict with. Especially when i use some sort of generic loop counter, where i have a variable that literally is called counter. I know it is not the best practice but most of the time i can't think of anything else.

    I do program everything in English even though it is not my native language. Using my own language feels wrong somehow. perhaps because every code i have seen has been in English.

    Every problem has a solution, that isn't the problem. The problem is the solution.

    Quote from Leon

    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 :grinning_face_with_smiling_eyes: 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 :thinking_face:

Advertising from our partners