Back to the ol' drawing board...

    I was trying to eliminate the issue of the "Download" bar filling up, emptying, filling up, etc. over and over for nearly 15 minutes. When the control screen finally comes up, a message says that the download timed out. Is that a setting I can change & make super-short (even if it's in the registry)? ***NOTE***After typing all of this, I have deduced that my attempt to use different SDRAM is at least partially responsible. I have the original RAM back in the cabinet, and the lengthy "Download" has disappeared, but it's too late, hence the rest of this lengthy posting. :icon_rolleyes:

    I decided to try with a completely clean slate, so I re-installed the system software, which is V3.2.6 SP03. Unfortunately, now I have a robot that says "no axes need mastering" when the control screen comes up, and if I choose the "GM" option at install, I have the dreaded "general motion enable" message. Also, no matter which option I choose, the "S&I" icons immediately come up green...why is the "I" icon green, (I know it means the motors are already on..but WHY) ?? :hmmm:

    Pushing any of the deadman switches does not change the color of the "S" or "I" icon. I do hear relays clicking...

    I'm also getting these silly messages:
    -"BOF Statuskeys refer to a technology not loaded"
    -"UserStatuskeys refer to a technology not loaded"
    -"UserStatKeyBarOCX Unknown Module "KUKATPGRP at Statkeybar request"

    I went back through my entire message history on this forum, and those messages didn't come up when we first tried running this thing back in August.

    I have looked inside at the control PC. There are several boards (this info may be important later):
    -X834 (green connector)
    -X801 on left side (green connector) and X802 on right side
    -X821 (monitor is plugged into this one)
    -COM2

    I proceeded with the re-install. My first attempt is with the following selections :
    -Office PC
    -Kuka Standard
    -No folders chosen for use of existing installation

    I chose KR30_2 Floor for robot type.

    The next screen is particularly frustrating, as I don't know exactly which options to check, and if any of these options are affecting the overal problem of the robot not budging an inch right at startup. Even with my limited knowledge, I'm almsot sure a few of these should be checked, based on the info I mentioned earlier about what's physically in the computer.
    -Interbus
    -DeviceNet
    -Bosch
    -Perceptron
    -Sbip
    -Fipio
    -Profibus-Slave
    -Profibus-Master
    -RIO
    -LIBO
    -Profibus Master-Slave
    -LPDeviceNet-Scanner (Channel 1)
    -LPDeviceNet-Scanner (Channel 2)
    -DSEIODRV
    -LPDeviceNet-Scanner (Channel 3)
    -LPDeviceNet-Scanner (Channel 4)
    -LPDeviceNet-Scanner (Channel 5)
    -LPDeviceNet-Scanner (Channel 6)

    I have also tried searching the forum extensively for the whole "$MOVE_ENABLE to 1025" issue, but that is frustrating me. Why are there TWO locations (R1 and STEU) that have a file called machine.dat??? I've attached a screenshot of what the applicable settings are right after installation.

    I didn't realize it at the time back in August, but I guess we shoulda made a backup image of the hard drive IMMEDIATELY after getting the whole setup to work. I myself was not the one who initially looked at the machine.dat, etc files for configuration issues.

    I think my only option at this immediate point is to recheck the X11 plug my friend made, but that hasn't changed, been moved, etc....GRRRR! :wallbash:

    I promise to keep excellent records, make backups, etc. this time if y'all can graciously help me regain control of my robot. :angel: Thanks!

    Quote from neeboy74

    I have looked inside at the control PC. There are several boards (this info may be important later):
    -X834 (green connector)
    -X801 on left side (green connector) and X802 on right side
    -X821 (monitor is plugged into this one)
    -COM2

    X801/X802 are on the MFC, X801 is DeviceNet, X802 Ethernet. The others are probably bus systems, but I've only ever used DeviceNet and ProfiBus so not sure what X834 is

    Well the only Devicenet one you need is [DeviceNet], and none of the Profibus drivers, although I'd disable all of these until you get the controller booting OK.

    Quote from neeboy74


    I have also tried searching the forum extensively for the whole "$MOVE_ENABLE to 1025" issue, but that is frustrating me. Why are there TWO locations (R1 and STEU) that have a file called machine.dat??? I've attached a screenshot of what the applicable settings are right after installation.

    No idea why there are two $machine.dat files, it has always been like this in my experience, my guess it might be compatibility with older versions of the software.
    Change it using Configure>I/O>Automatic External :top:

    Never use 'Office PC' on a real Robot ! There will be no drives available, the robot won't move a millimeter.

    The message about OCX-Controls: After reinstalling the System You should also reinstall GripperTech, and other techpacks which where installed before. By the way, it seems that You didn't make a real clean installation because there are some old references to Grippertech. For real clean installation You also have to reinstall Windows.

    The 'S' should be already green (Submit Interpreter is running) but for the first test in manual mode it's no problem.

    The driver selection also is uncritical. This selection only uncomments the driver in ioconfig.ini, this can be done later manually.

    The Input 1025 for $move_enable also is uncritical for the first test's. The other way round: it's essential for the first test in manual mode, otherwise it's possible that the configured input is low, and You can't move the robot. You get the silly message only in autoext mode.

    Maybe You have a serious hardware problem on your controller.

    You should post all errormessages on the lower side of the panel.

    Quote from eusty


    No idea why there are two $machine.dat files, it has always been like this in my experience, my guess it might be compatibility with older versions of the software.

    You're right, it's mostly a compatibility barnacle.

    Quick history lesson: R1 is the robot. STEU is apparently some sort of German acronym(?) for the controller. Once, there was an intention that the KRC1 controller might be expanded to control multiple robots. This intent never came to fruition, and instead we got RobotTeam (much much later). So, there might have been /R1, /R2, /R3, etc.
    So, each robot would have its own /MADA folder and $MACHINE.DAT file. This file contains robot-specific information, like axis configuration and servo parameters. /R1 keeps this pattern, even though there never was any /R2, /R3, etc.
    STEU has its own /MADA directory, with its own $MACHINE.DAT. This file contains information specific to the controller, mostly system-level I/O signals (like $MOVE_ENABLE, $DRIVES_ON, etc).

Advertising from our partners