Expert mode in vkrc2 Xp

    Quote from javaman

    I got a used vkrc2 and i found on kuka_data partition 5.4.7 HF5 software.
    Can this software can be installed to windows embedded standard or posready 2009 (based on win xp sp3)?

    Yes, it can.

    Quote from javaman

    Also can this software installed on other vkrc2 i have with windows 95 (after upgrade to xp)?
    I mean if can be installed because of license reasons.

    So, the hardware for VKRC2 (Win95/VSS 3.x) and VKRC2 ed05 (WinXP/VSS 5.x) is way different.

    But...

    I heard stories about people installing VSS 5.x on old VKRC2. You will probably stumble on some problems, but if You have time and a spare robot, why not try?

    Quote from javaman

    Where is located the key for expert mode?

    It isn't bundled inside the robot. Look at Your inbox.

    PIII-1.4S has the same stages pipeline as celeron is more fast in clock and has more cache.

    I don't see any reason to fail. Jitter can not increased by this change only can reduced so real time performance will be better.

    I agree that if you put other mobo or enable features in bios like usb/sound or add another gpu jitter can increased dramatically and have serious impact in real time performance.

    Kuka in SY-7VBA133U has upopulated the audio function chips and i think the reason is the real time performance.

    The only case i see that PIII-1.4S will not work is if kuka software has checks inside that stop function if detect another cpu than celeron733mhz

    You're replacing only the CPU? Not the rest of the motherboard? That might work, but the difference in performance might also throw off the internal hard-realtime clock. KSS runs on a hard 12ms clock cycle, but I honestly don't know how tightly coupled that is to a specific processor. However, KSS/VxWorks runs much closer to the metal than consumer OSs, which makes it much more stringent about minor hardware details.

    That's one of the reasons that using desktop RAM is a crapshoot -- KUKA's RAM is technically the same hardware, but KSS/VxWorks is so much less tolerant of minor timing issues that desktop OSs can normally tolerate, that even fully "compatible" commodity RAM isn't guaranteed to work. KUKA's spare-parts RAM is so much more expensive in part b/c it's been certified and guaranteed to work with the hard-realtime tolerance requirements of the realtime OS. Commodity off-the-shelf RAM can work, but only with some luck.

    For that matter, why replace the CPU at all? Even if it works, you will see no real performance improvement -- the 12ms internal cycle is fixed. At most, the execution speed of non-motion KRL code might improve slightly

    If you used a non-KUKA motherboard, that would almost certainly fail -- the BIOS at minimum would conflict.

    Getting a boot improvement from an SSD makes sense -- KUKA moved to SSDs with the KRC4s, and I think the last generation of KRC2s.

    But that works for two reasons: One, the drive is only really used during boot -- everything is loaded into a RAM drive, and executes from there, with only periodic writes to update the HDD/SSD. This massive load is also why the boot process takes so long.

    Two, the mobo and OS generally can't see the difference between an SSD and an HDD, as long as the drive uses the correct IDE or SATA. Although the SSD would need to be completely self-contained on write balancing, b/c the OS won't have any support for that.

    But KSS is designed to that 12ms internal clock, regardless of the processor it's running on. That hasn't changed for 25 years -- the processors keep getting faster, but the IPO cycle remains fixed. The one side benefit is that, b/c each interpreter is free-running during it's "slice" of the IPO "pie", non-motion code execution can actually get faster. But the vast majority of the time, this doesn't make any practical difference, because very few people are going massive calculations on the fly between points.

    12ms servo thread i think is to big..

    And the problem for this is that windows kernel jitter is big because is not a real time kernel.

    For example other cnc controllers(linux preempt-rt kernel/embedded arm with some RTOS) have < 1ms servo thread.

    The design of real time controller based on windows OS is a fail because windows is not real time.

    Except that your assumption of Kuka controller architecture is wrong.

    Of course Windows is not a real time OS, and this is why KUKA uses vxWorks for control or anything time critical.

    Windows is only used as front end (HMI etc.) - tasks that are not time critical.

    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

    That's why none of the realtime system of a KRC is running in Windows. It's all running in VxWorks, which is a dedicated scheduled realtime OS. On a KRC, Windows only serves the user interface.

    Windows and VxWorks run in parallel, and communicate through a virtual TCP/IP network interface -- they're not actually aware that they're running on the same hardware. It's essentially similar to a Virtual Machine setup, with the KUKA CROSS program acting as the hypervisor equivalent (at least, as I understand it). VxWorks has absolute priority on all hardware resources, which can have some interesting effects on Windows.

    The 12ms cycle has served KUKAbots perfectly well for more than 25 years. I agree that it's getting to be rather slow compared to some of the competition (Fanucs run on a 4ms cycle now, I think), but honestly, speaking as someone who's done a fair amount of RSI on KRCs, the vast majority of the market simply doesn't need a faster IPO cycle. Still, KUKA has been moving in the direction of accelerating the IPO -- IPO-FAST mode runs at 4ms, and from the rumors I've heard, the next-gen KRC will probably run on a 4ms IPO overall.

    OK i got it that makes sense.

    But the cheap and easy way is linux preempt-rt kernel & linux.

    With this kernel a motherboard that costs 100eur for example intel atom with some configuration can give servo thread jitter < 50uS .

    So for only 200eur you can get a full generic pc that is real time with servo thread < 50uS.

    Also keep in mind that the cheap and easy way usually translates in to unreliability. I for one don't mind spending some more, but having the guarantee of a low down time, if there is any.

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

    I have a system with atom J4150 with linux preempt-rt kernel that has uptime more than 6 months without reboot without shutdown.

    linux is far more reliable and stable and needs less resources than windows for this reason is the first choice in servers, supercomputers and embedded systems. For embedded systems there is special preempt-rt kernel that makes a typical general pc real time.

    When kuka started producing robots before 20+ years ago preempt-rt does not exist but today many things have changed..

    Iam sure if they started to develop a robot controller today first choice will be linux with preempt-rt kernel.

    Not necessarily. Again, because you're moving big heavy machinery that can be very hazardous, predictability is much, much more vital that performance. And the fixed-time-cycle, rigid timeshare task switching provides that. Because these are safety-critical systems, their behavior must be 99.99999% predictable across any conceivable situation, ranging from stupid operator button pushes to badly-written program code to bizarre hardware or power issues.

    By way of example: VxWorks, which is the realtime portion of KSS, is also what NASA uses as the underlying OS on the Mars rovers. Reading the NASA documents on their programming requirements is extremely enlightening, if one wants to study the subject of high-reliability software.

    Also, the 'uptime' numbers on a Linux dekstop have very little bearing on the reliability of a complex automated system. I've seen well-constructed Windows NT servers that have years of nonstop uptime on the clock -- that doesn't mean I want to entrust my automation to one. I use CNC machines powered by Linux and Windows both, and the difference is usually irrelevant (aside from the more recent issue of Microsoft remotely forcing updates and reboots).

    Picking a "hot new OS" for automation is the least part of the problem. The big hurdle to get over is the testing and certification, which requires massive amounts of time. And that's before considering the even higher bar of RIA safety certification

    Generally, if the RAM presents issues, it will usually prevent the robot from booting, or will crash VxWorks in some manner soon after boot. Windows will usually keep running.

    The BIOS settings I can't speak to specifically. But generally the BIOS on a KRC has been modified by KUKA to some degree (how much depends on the controller model and sub-type).

    The bios has been modified in a manner that has functions disabled because specific

    interrupts to cpu kill real time performance.

    For example the custom bios has sound/usb/power managment functions disabled.

    The custom bios does not have altered functionality only certain function & peripherals disabled.

    "custom" has to do with configuration only.

    In preempt-rt linux kernel with power managment/cpu throttling functions enabled in bios real time performance drops significantly so the best jitter is with these function/peripherals disabled.

    Also when you isolate real time functions to specific cpu core (with configuration of kernel)

    and all other general pc functions to other cores jitter is very low.

Advertising from our partners