Tips and tricks

I prefer using "Wait for True", that way it's easier (for me) to distinguish that stopping advance pointer is the only reason that line is there.

Writing functions to iterate over commonly used structures like pos, frame, axis and the like was game changing. Highly recommend.

Use ptp $Axis_act for quick BCO instead of $pos_act- unlike the latter it works predictably in singularities.

Assigning pos to frame to remove status and turn is obvious, but still useful.

Something that I use quite a lot:

IF _DebugMode then
    Halt
ENDIF

Very easy to remove after debugging, as opposed to just Halt.

Use VarState function to write functions with default parameters or to turn structures with missing elements into strings.

Geometric operator can be used to avoid stopping advance pointer when there is a need to change $tool and or $base.

Don't do complex things like trajectory planing or collision avoidance in KRL.

Don't use literals for inputs, outputs, timers, interrupt priorities and the like- name them all in one .dat file. $In[_IDTableVacOk] is a lot easier to read than $in[15]. Then, when changing, you have to change number in one place only, instead of combing through the code and hoping you didn't miss anything.

Similarly, using functions to return base or tool frame is better, since it's easier to remember and impossible to accidentally change them.

TIMER_LIMIT(Time) is great when you need a simple timer in combination with other things that run in main.

E.g. while not $in[_DI_PressOk] or TimerLimit(3)

Another obvious thing, but you can modify workspaces programmatically.

Quote from Mentat

_DebugMode,

_IDTableVacOk

Why for heavens sake do you use an underscore at beginning of a name? My tipp is: don't do this.

i could see that it could be handy to tell if variables are declared by Mentat or Hermann

Quote from hermann

Why for heavens sake do you use an underscore at beginning of a name? My tipp is: don't do this.

Speaking purely for myself, I use it as a naming convention. Variables declared in the subroutine start with an underscore, while variables declared in .DATs are not. I also have a set of standard prefixes for specific variable types, and function arguments (by-value or by-ref).

For me it is too easy to overlook the underscore. Had a colleague who also used this method, and sometimes there where variables with same name but one with, and one without an underscore. In my opinion that is the worst case. Can remember one day I wasted at least an hour until I detected the difference.

Edit: That was is a very very long time ago. The screens in that times where monochrome with low resolution, since that time I hate those underscores at beginning and ending of a name. May be I should rethink my opinion.

Hi,

there is also another option:

user lower or upper CamelCase

regards

MOM

Hi,

this actually is something which has to defined in a "STYLE GUIDE"!

Some one likes to do it with an underscore

Someone likes to do it with lower or uppercase CamelCase

Someone likes to do it with hungarion notation

As long as it is defined in a style guide and all the others follows it is Ok

regards

MOM

As a tip for all using KSS 1.x thru 7.x to address i/o's

IO.pdf

regards

MOM

MOD() is one function that comes in handy

DEFFCT INT MOD(x1:in, x2:in )
   DECL INT x1,x2
   RETURN  x1-x2*(x1/x2)
ENDFCT

Love your robs.he will work good

What is the difference between wait sec 0 and wait for true and why the second one is better?

Quote from Dzonzi

What is the difference between wait sec 0 and wait for true and why the second one is better?

There might not be any discernible difference in KRL code execution, but at least for me personally, it's very easy to remember that "Wait for True" has only one purpose- to stop the advance pointer. "Wait sec 0" might have been "Wait sec 0.3" before, it's now not needed there at all, but I forgot to remove it. So it's not better somehow, just easier to recognize.

This is probably known by some people here, but since I didn't found any mention on manuals, I would leave the tip.

This week I accidentally discovered that WorkVisual KRL editor also has a column selection mode, and it is triggered by the same shortcut used in Notepad++ (Ctrl + Alt + Left mouse button) Alt + Left mouse button (thanks Mentat ).

The funny part is that this feature is present since WoV 3.0.10 2.2.2, older version I've tested here.

Quote from massula

This is probably known by some people here, but since I didn't found any mention on manuals, I would leave the tip.

This week I accidentally discovered that WorkVisual KRL editor also has a column selection mode, and it is triggered by the same shortcut used in Notepad++ (Ctrl + Alt + Left mouse button).

The funny part is that this feature is present since WoV 3.0.10, older version I've tested here.

Use this quite often, works with just alt+leftmouse.

Nice to know that Alt + Left mouse button do the job.

At first, I was thinking on N++ shortcut because I stumbled on this while switching between N++ and WoV, and did the shortcut at the wrong window.

And I went back a little bit more in time and tested with older WoV versions. This works since 2.2.2.

In the newer (8.5 +) KSS versions I have not found a file to permanently disable the 6D mouse, but there is now a Rights management in StartUp section. That's where you can set Jogging using the 6D mouse to Deactivated, so no one has to suffer anymore

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.

one can edit

C:\KRC\User\ProjectExternalFileList.xml

then when WoV project is transferred from KRC to your computer, it includes also few other files of interest like ConfigMon.INI or UserTech files. Do not forget to include the ProjectExternalFileList.xml itself. I became interested in this because of UserTech since some of final touches would be likely done on the controller. Sometimes i would make a mistake and overwrite already made changes on the controller by deploying WoV project that was not updated. I did not want to make edits in two places or deploy project for every change. I wanted to always work on the most recent version and this solves it. But for me it is more than just that. I am usually one preparing but not the one actually deploying projects. So instructions to techs what to do and in what order are now much shorter: "...just deploy the project"

an example:

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.