Posts by SkyeFire

    Hey, all, got another one. I'm trying to debug a SafeMove configuration that isn't behaving the way I expect, and could use some help. Unfortunately, I have very little background with SafeMove, though I've done Fanuc DCS and KUKA SafeOperation, so I understand the principles in general.

    This is SafeMove Pro, with a CIP-Safe interface, on an IRC5 running RW 6.09. I have CIP inputs and outputs mapped, and no Pre- or Post-Logic.

    In the SafeMove Function Mapping that I inherited, the safe input SafetyEnablePLC (from my cell PLC) is mapped to the function SafetyEnable. By using the pendant I/O monitor, I've confirmed that when I hit a perimeter E-Stop, or open the perimeter gate, the DI SafetyEnablePLC goes False. But the DO SafetyEnable does not -- it stays True.

    Now, when I break the perimeter safeties, the robot throws a SafetyEnable fault message, but the robot (in Auto) does not stop running. The motors stay on, and the robot keeps moving.

    However, if I stop the robot first, then break the perimeter safeties, I can still turn the motors on (in Auto), but the robot will refuse to start, until I close the safeties and get DI SafetyEnablePLC to be True again.

    Now, according to the manual, the SafetyEnable function should, when the input signal is False, kill DriveEnable and stop the robot from moving. This does not seem to be happening.

    I'm a bit stumped here. SafetyEnable is the only input safety function (aside from ExtComShutdownAck, which I don't think is relevant here).

    So, in PFBMS.INI, this line:


    Defines the scanlist file that tells the PB card what Slave devices are connected, and what their addresses and parameters are. This is a binary file generated by Siemens NCM, so we can't examine its contents, but you should ensure that file is also in place, located in the INI directory.

    These lines:




    Show that PB logging is enabled, and to which file, but the language is set to German. I recommend changing the language to English, reboot the robot, then examine the contents of the log file. That should provide more detail regarding what's failing.

    Your IOSYS.INI also has at least one obvious bug. INB12 is assigned twice -- once to the PB Slave, and once to the PB Master.

    I'm an idiot, these wago IO modules need an additional power supply card. I thought the 750-354 would provide power through the spring connection, but that is not the case.

    Ah, yes, that's a standard thing with most of the "sliced" I/O setups. The bus coupler's power is isolated from the power to the I/O slices.

    You also have to watch your I/O slices -- most of the mainstream I/O cards will pass power "downstream" to their neighbors, but there are some slices that don't. And adding another power slice will "break" the power bus on the backplane, to allow things like having a section for 24VDC I/O, and another with, say, 120VAC I/O, sharing the communications backplane but with completely isolated power busses.

    EDIT: just checked, and I noticed that whether I plug the ethernet cable from the KUKA to the IN or the OUT port of the 750-354, I have no errors. That seems strange to me.

    That doesn't matter -- both ports on the Wago module are "equal" -- it's basically a two-port ethernet switch built into the module.

    Now, if you unplug the cable entirely, does that create a fault?

    Do you need to measure the speed of the turntable accurately, or just confirm that it is moving? How accurately do you need to measure the speed?

    Simplest method I can think of is to remove the four pins, and mount an "arc" of metal that spans two of the pin locations. That will extend the pulse duration a great deal (how much depends on the radius of curvature -- you might need a 90deg arc, or a 180deg arc). Alternatively, look at the radius between the axis center and the "ring" of the pins, and replace the pins with blocks/arcs large enough to guarantee that the pulse stays on for at least 24ms even at 500RPM. Adding the Fast Input option would tighten the "noise band".

    Then have your SPS track the time between pulse-on and pulse-off, or even just from pluse-on to pulse-on. Accept that your speed measurement will have a fair amount of "noise" due to the "beat frequency" between the turntable speed and the IPO cycle, and alter the SPS program to record several rotation's worth of pulse times and generate a running average. This should get you a decent measure of the speed.

    However, any step taken to improve RPM measurement at high speed is going to have a penalty at lower speeds.

    Every KRC1 and KRC2 has an MFC card. Without an MFC card, the robot doesn't work. The MFC has, among other things, the X801 connector for the KRC's built-in DeviceNet port.

    The DSE is a smaller card that "piggybacks" on the MFC. It occupies the space for one of the motherboard expansion slots, but does not plug into the motherboard itself.

    Hello—You may wish to look in the Operating manual IRC5 Integrator's guide, (3HAC050940-001) through section 10.5.3 ABB Robotics IRC5 product specific requirements to see if your PC permissions are inline with what is needed.

    Hmmm... Section 2.2.3, "set up the network connection", seems to imply that for robots set up the way these are (with "Use no IP address" selected), it won't be possible to connect to the robot over the network.

    So, it seems I have three different places to set the robot IP: on that pendant menu, in RobotStudio under Configuration>Communication>IP Setting, and the third for the CIP-Safe module in the SafeMove configuration.

    Now, the robot Ethernet/IP and CIP-Safe work right now, using these settings:

    I can ping the robot at that IP, but RS can't find it.

    Does this mean that the LAN3 setting, and the IP address set from the pendant menu, are separate things? I never tried setting the IP under the Pendant menu (Controller Settings>Network), b/c EIP and CIP were working. If I do set a static IP in the settings menu, does it need to be the same as the LAN3 and CIP IP, or would that cause a conflict?

    System.xml, in the backup folder

    Okay, here's what it lists for controller options:


    997-3 CIP Safety Adapter

    613-1 Collision Detection

    841-1 EtherNet/IP Scanner/Adapter

    1125-2 SafeMove Pro

    996-1 Safety Module

    608-1 World Zones

    RobotWare Base

    And Robot options (probably not relevant):

    Axis Calibration

    Pendelum Calibration

    Motor Commutation

    Service Info System

    Drive System IRB 460/640/660/760/4600/66xx/6700

    So, another IRC5 (RW v6.01) question:

    I inherited these robots in a mostly completed state, and production has already started on some units. But I'm running into some odd differences between the different robots.

    The robots all have a routine that sets up the Home position output on reboot:

    PROC PowerOn()

    This works on the production robots -- whenever the robots are rebooted, the WZs get set up, and the signals work. On the robots that aren't yet in production, I have to run the PowerOn routine by hand.

    Obviously, this is just a config setting. I compared SYS.CFG between backups, and found that the POWER_ON section was missing from the pre-production robots. No problem, I made the setting change via RobotStudio, rebooted the controller, and... nada. Even though the robot was physically at Home position, do75 didn't turn on.

    I pulled a backup from the robot I made the change on, and compared SYS.CFG to the "good" robot again. 100% identical, down to the last character.

    I rebooted the robot again, just for kicks... still no do75. I hand-selected PowerOn and ran it... and got a "World Zone Already In Use" error. But do75 did turn on. I should note that the robot was physically at Home during all these reboots, and did not move.

    So, the error message tells me that the PowerOn routine is getting called on boot, but do75 doesn't turn on until I run PowerOn by hand. What am I missing here?

    ADDENDUM: while typing this out, I rebooted the robot a couple more times (never moving the robot), and suddenly do75 came on at the end of the boot. I rebooted the robot again, and... do75 stayed off. Now I'm even more confused. I doubt the customer will take "reboot the robots 5 times" as a standard operating procedure to resolve this issue. Why would it be so inconsistent? Is it possibly my DeltaPos range setting is too narrow? It's set to [1,1,1,1,1,1], which seems like it should be generous enough.

    Controller Model? KSS version? Those matter much more than the robot model, in cases like this.

    This suggests a hardware issue. If the DSE has already been replaced, then my next thought would be the MFC card. The RDC, or the DSE/RDC cable, might be another possibility, but I would expect a more RDC-specific error message in that case.

    Something like one of these:…kb05vdExvZ0NsaWNrPXRydWU=

    NOTE: Not an endorsement! I just grabbed an example at random. It's been so long since I needed one, what I used to use isn't on the market anymore.

    As for software: I always had good luck with CloneZilla, although some people caution against using that with KRCs. Norton Ghost always worked well on KRC1s, but I'm not sure they sell that anymore. I've heard good things about Acronis, but haven't used it myself.

    Whatever you use, you want to ensure you make a complete hard drive image, not just copy the files. A full image will be the only way to completely recover the KRC's Windows installation.

    4 pulses/rotation, at 500RPM, means your pulses happen every 30ms. Which means each pulse is much less than 30ms in duration. And reliably detecting anything less than 12ms in duration with a KRC is basically not possible -- ideally, you should never try to detect anything of less than 24ms duration.

    If you get the Fast Input option, and wire the sensor directly to the Fast Inputs, and detect each pulse using Interrupts monitoring the Fast Inputs, that might work.

    RSI, in IPO_FAST mode, can cycle every 4ms instead of every 12ms, but I would still have concerns about reliably detecting these incoming pulses without the Fast Inputs.

    There's also the I/O refresh rate -- you might have to use an input device set for Interrupt updating, instead of Polled/Cyclic. And that can have complexities of its own.

    What drives this turntable? Is it connected to the KRC as an external axis? If so, then you don't need to monitor pulses, you can read the axis angle directly in realtime.

    If the axis is driven independently, I think your best bet would be to add Conveyor Tracking to the robot, and install a resolver on the turntable axis wired directly to the KRC. Or, if you have a good, high-speed communication channel between the turntable controller and the KRC, you could have the turntable pass the realtime value of the servo resolver(s) to the KRC via whatever FieldBus option connects them.

    Is there anyone interested in testing it?

    The odds of anyone having the right KSS version and HMIEasy installed, combined with availability and free time on the robot, is rather low. I know I don't have any KUKAs available with HMIEasy installed.

    Why can you not just program the paths with a slower velocity?

    A combination of ongoing testing/debug, and amateur operators -- this is a whole new production line, and the facility has no previous experience with robots. So programming all the points with low speeds would just mean having to go back and re-program them all every time we made another change.

    It looks like adding a temporary velset or speedrefresh is my only real option.