Multiple instances of same OfficeLite?

what you ask is different from linked topic.

in linked topic, question was how to have installed side by side different versions of OfficeLite, each using their own valid license.

but you are asking how to run different instances of same OfficeLite using single license.

normally what you want is accomplished by simply deploying another WoV project. But... this is not always practical or may not even work since WoV project does not contain everything it should. and even worse, KSS does not wipe the slate clean before activating new project so things can get ugly and frustrating very fast...

for example, MY idea of deploying new project is that EVERYTHING old is removed and then EVERYTHING new is installed. nothing old shall remain. everything that certain project needs (configuration files, user programs etc.) could and should reside in one folder - with as many subfolders as needed. then creating clean slate is easy - delete the folder with anything in it... or rename it... or ZIP it if you want to store it. and easy to compare with others... Any KSS plugin or feature only would need to know which folder contains active project instance and work with that.

but... that is not what KSS does...

When KSS is activating WoV project, files are extracted from WoV project and then sprinkled all over the C:\ in what is essentially a big mess:

C:\KRC\ROBOTER\KRC - contains things that go to RAM drive such as MADA and user programs

C:\KRC\ROBOTER\Config\User\Common\EthernetKRL - is where EKI configuration files are placed

C:\KRC\USER - is where ConfigMon.INI etc are

C:\KRC\TP\UserTech\TEMPLATE - is folder where most of UserTech files are

C:\KRC\SmartHMI - is folder where menus are (including UserTech)

etc.

List is very long but it is obvious that some of the folders that contain brake test info, motor gains, IO configuration etc are literally all over the place.

And to make matters worse, some of those folders are actually places where many system files are including binaries. To me that is a huge no-no. User/application files should never share location with system files. This explains why installing and activating new WoV project simple does not wipe the slate clean. The way the files are organized is just way too complicated. One cannot simply create new folder in a suitable place, dump WoV project content into it and point KSS to use that place as a working folder.

Even things that go to a RAM drive (KRC:\) are not properly cleaned when deploying new project as one can see by clutter of old folders. Yes, KSS will remove files but .... not the folders . And things that are not mapped to RAM drive are only going to be overwritten if the new project contains file with same name and path. but if the new project does NOT contain that same files and folders (for example because it does not need them) there is nothing to overwrite previously used ones. In other words they remain in place and and get loaded anyway... or if incorrect or incomplete or if referring to something not installed, they will still trigger giant red frame popup unhandled exception telling that something is not right and system will stop for safety reasons. Once you click OK it will shut down and now you are stuck in a death trap (a loop), all because of something that is not even used or needed, something that is not even part of the clean and good WoV project you just activated. IF that happens read message carefully, try to locate file and remove it manually... or delete OL VM, get factory copy, activate it... lots of fun.

The result is that simply deploying and activating new WoV project is often not enough to really switch from one project to another. While that is a needed step, it is often not sufficient to quickly and productively switch over to another configuration. And i have wasted my own time on this plenty of times. This is not an issue when projects are sufficiently similar but reality is that one may need to use same OL for different projects.

And if you really need to work on considerably different projects every day, this is just not good. It is one of the problems i have faced and I am waiting for KUKA to come up with a better solution. The fact is we just don't see things the same way.

Until then one can try some of workarounds. Some things that i have tried include:

1. Adapt C:\KRC\USER\ProjectExternalFileList.xml more about this below.

2. Try to simply ignore the parts you do not really need right now (if possible).

3. Clone VM. As long as you run only one of them at a time on a same computer for which they are licensed, they will work and each can be configured differently. The major downside is that this takes lots of storage (my OL is huge).

I adapt ProjectExternalFileList.xml for each project deployed to actual robot. Doing this made huge difference for me in terms of supporting and troubleshooting. Originally i did this to get more comfortable handling of UserTech files but it more than that now. It also allows faster and simpler deployment. When working with OL, it can be also used to neutralize files that are not needed by overwriting them with dummies.

so yeah... OL is a great tool but some of design choices about KSS and VoW project deployment are less than ideal. Some of the common problems are direct result of this and unfortunately it will take forever to fix...