Workvisual -- "smart" file merge on system files?

  • Something I just ran into. It might be in the WV docs already, but I admit I haven't gone digging. (This was observed using WV 5.05, on KSS 8.3.39)


    I had a large mass of files from a previous robot I wanted to dump into a new robot whose hardware and software setup is going to be identical. My "classical" approach to doing this is just to copy&paste the files from USB or a network share, but this time I decided to try doing it through WV.


    I connected to the robot, Browesed up the active project, activated the controller, and moved to the Files tab in the config tree. Then, right-clicking on the "Programs" directory, I used the "Add Existing Folder" option, and selected the Program directory on an Archive of the older robot. Everything went swimmingly.


    Then I did the same with the System folder. And that's where things went... odd.


    I didn't get any alerts, but when I opened up $CONFIG.DAT on the pendant, all of the Tool and Base data were still Nullframe'd. OTOH, the (very many) application-specific variables that had been added to $CONFIG.DAT on the older robot had been added to the new robot's $CONFIG.DAT.


    After poking at it a bit, my working hypothesis is that WV, when copying in a new $CONFIG.DAT file, is doing a "smart" merge of the new and pre-existing files. It looks like it only copies in the User Variables section of $CONFIG.DAT, and leaves the other Folds untouched.


    Now, if this is what WV is doing, that's a nice feature, but I really wish WV would have thrown a warning or reminder at me when it did this.


    As it turns out, I wanted all the Tool, Base, and other settings copied in, so I ended up deleting $CONFIG.DAT in the file tree, and then importing the older $CONFIG.DAT. That got me what I wanted.


    But now I'm curious: what other files does WV do this with? I assume the SPS would be one, as that also has a "KUKA" section and a "User" section pre-defined. But are there other files (or sections of files) where someone unaware could trip over this? I've been avoiding copying any of the MADA files this way, even though it would be convenient for my Auto-Extern signals, for example.

  • Addendum: I spoke too soon.


    Sooo... deleting $CONFIG.DAT in WV, and importing the $CONFIG.DAT I wanted, only seemed to work. Opening the file in WV showed me what I wanted to see. But the moment I Deployed the project to the robot... $CONFIG.DAT in both WV and the robot went back to the previous settings -- but only in the "KUKA" Folds (AUTOEXEC, BASISTECH, etc).


    Even hand-editing $CONFIG.DAT in WV, then deploying, gave the same result -- any changes I'd made inside the "KUKA" Folds got reverted back to what the robot already contained.


    In the end, I had to go back to my old brute-force method: de-select the SPS, and (on the pendant) copy-paste my System directory files from a USB stick, and overwriting all the existing files. Only after doing that did I get my Tool, Base, Load, and other data that I wanted.


    Which wouldn't be so bad, except that at no point did WV ever tell me that this was happening! There were no errors, no warnings, no reminder popups, it just... silently un-did all my changes. This is not cool, Augsburg.

  • Although I have my own list of WoV "unfeatures", I never stumbled on this particular condition.


    But it is good to know.


    I'm on a side project where I'm developing all KRL code, signal mapping, signal naming and so on inside WoV.


    The idea is send this WoV project to be deployed by a colleague who is on the field, so he, in theory, should only touch up the points and make some minor debugging.


    If something go strange after the deploy, I know what we can try.

Advertising from our partners