Are you attempting to perform realtime control with EKI? EKI is explicitly not designed for this. This is what RSI is for. EKI is not realtime -- it is intended for non-realtime, non-time-critical communications. With EKI, the robot cannot respond to a new force until after the current active motion is complete. As such, any "realtime" attempt using EKI is going to be very "chunky" in dV/dT, at best.
Posts by SkyeFire
-
-
Without details, I can only shoot in the dark. But my first though is to make a Global interrupt, or declare the Interrupt in your highest-level routine, and only turn the Interrupt on/off in your lower-level routines.
-
Too many potential options to say with certainty, but my bet would be that there's a missing input from either the wire feeder or the welder, one that indicates that the welder or feeder is ready. This is probably an input signal whose assignment needs to be changed in the ArcTec configuration.
-
Define "switching of the controller". Do you mean a reboot, or a complete power off/on cycle?
The mastering error occurred only for E1-E3? That is unusual. Is the KP3 an old unit? Possibly recycled from a KRC2? Where is the secondary RDC card for the KP3 located? I would check that first.
It might simply be a one-time fluke -- you can re-master the KP3 axes easily enough. However, if it keeps happening every time the KRC4 is rebooted, then the secondary RDC is definitely in doubt.
-
The "Position cannot be approximated" error is generally a "nuisance" fault -- it should not stop the program. It simply indicates that you gave ordered the robot to make an approximated motion (C_PTP or C_DIS), followed by an instruction(s) that break the look-ahead of the Advance Run Pointer. EKI commands generally fall into this category, along with $OUT settings, WAITs of any kind, and many others.
The problem is, EKI is really intended for a single-step execution scenario -- Move, stop, communicate, move, stop, communicate, etc. It sounds like you're trying to use it as a "realtime" motion control, similar to if you were jogging the robot with the pendant, and it's not really intended for that kind of operation. RSI is the package to use for realtime remote control. EKI is intended more for scenarios like you might have with a "snapshot" vision system -- move into position, take an image, get the results, move to correct for the vision results, come to a complete halt, take another shot, and repeat that until the vision measurements are close enough to "zero" to stop correcting and move on to the next process step.That EKI error I've never run into before, but I suspect you're hitting some kind of memory limit for a single connection. How many loops of your comm/move cycle occur before this error trips? Is it a consistent number?
Trying to use EKI the way you appear to be attempting to may not be impossible, but it would be tricky even for an experienced KRL expert. What exactly are you trying to accomplish?
-
Details? You haven't mentioned your MFC version, controller model, history of this particular controller, hardware options....
-
You say you're trying to "connect to a KR6," but you don't say anything about the controller . Different generations of KRC2s have some differences in how the COM ports are assigned. Telling us the robot model tells us nothing of use.
Assuming this is a different KRC2 generation, you may need to try COM2 rather than COM3. COM1 is very unlikely, but worth a try if trying COM2 does not work.
-
As Fubini says, do to rounding error, the differences between any two FRAME (or POS, or any REAL-type value) variables in KRL is likely to never be exactly 0 -- you're more likely to to 0.00001 or something. Insignificant for what you're trying to check, but enough to fail a simple "==" test. So you probably want something like:
CodeDECL FRAME _fDeltaFrame DECL BOOL _bSuccess _bSuccess = TRUE _fDeltaFrame = (INV_POS(BASE_DATA[1]) : BASE_DATA[2]) _bSuccess = _bSuccess AND (ABS(_fDeltaFrame.X) < 0.001) _bSuccess = _bSuccess AND (ABS(_fDeltaFrame.Y) < 0.001) _bSuccess = _bSuccess AND (ABS(_fDeltaFrame.Z) < 0.001) _bSuccess = _bSuccess AND (ABS(_fDeltaFrame.A) < 0.001) _bSuccess = _bSuccess AND (ABS(_fDeltaFrame.B) < 0.001) _bSuccess = _bSuccess AND (ABS(_fDeltaFrame.C) < 0.001)
The ABSs are important to cover the possibility that the delta value might be positive or negative. For this check, you're only interested in the scalar value, not the vector.
-
Do the names vanish after a reboot, or after you deploy a project from WorkVisual? If the latter, then it's probably b/c you're changing the names on the robot and not pushing those changes back up into your WV project.
If the former... well, that's quite odd. Is this robot having failures, or rebooting without proper power-down, or anything else odd? That should be about the only way that those names could be lost just from a reboot. -
So, this robot was running properly for ~3 months, and only started having this issue now? Then the voltage is NOT the issue - you need to have the A3 motor checked. I would recommend running an O-Scope diagnostic on the A3 traces while the robot moves.
-
When does it throw this error? At the beginning? End? Middle? What line of the program?
-
Controller model? Arm model? KSS version?
Is this a new robot? What's its history?
Also, if this wasn't happening on all six axes, the voltage settings are unlikely to be the root cause. You may also cause damage to the servos by tampering with this setting.
What supply voltage are you providing to the controller? What transformer configuration are you using? -
coin cell battery is standard CR2032SLA batteries are 12V each, connected in series they provide 24V.
ARGH! Can't believe I did that. Yes, Panic is correct.
-
The motherboard CMOS battery should be a completely ordinary coin cell, available almost anywhere, although you'll probably have to pull the original and read it's model number to find an exact match.
The big batteries are essentially high-end motorcycle(?) batteries, 6V each, wired in series to achieve 12VDC. You can buy them from KUKA, but IIRC they're just a major-brand battery with KUKA re-labelling. Somewhere in the forum archives, there's a post where someone details the original manufacturer and model numbers, and I think you could save a fair amount of money by buying them directly.
You IOSYS.INI edits look correct. If it turns out that the robot still has some of the support hardware for some of those I/O devices, you might be able to restore those interfaces later. But it all depends on how "stripped" that robot was of any optional hardware.
-
$TIMERs can be set to negative values, and $TIMER_FLAGs become true when the $TIMER value crosses from negative to positive.
Also, keep in mind that $TIMERs work in 12ms increments. -
I take it this is a used robot that you are just powering up for the firs time?
1. The coin-cell battery on the motherboard is dead and needs to be replaced.
2. All the lines in the DRIVERS section of c:\krc\roboter\ini\IOSYS.INI need to be commented out
3. The main batteries are dead and need to be replaced (and then charged for 12 hours minimum before the controller is powered off again). -
Does the motion of the robot need to halt for every sample? If not, the easiest way to handle this might be to simply rotate at a fixed velocity, starting from a known "zero angle" position, and generate a regularly-timed pulse train. There would need to be some "padding" on either end to account for the accel/decel ramps, but that should work as long as the motion is well characterized.
-
The biggest issue I ran into, that seemed to be intractable, was that the "warning" from the Brake Test would still halt the robot with a minor error if the robot was running in Auto. It was really annoying. We did find a way to access the remaining time to the Brake test, and used it to preempt the system-level warning message by running BrakeTest internally before the warning message popped up.
CodeDECL INT _nIntArray[5] DECL REAL _rRealArray[5] DECL REAL _rTimeToBrakeTest nRet=MD_CMD(brakeTestDevName[], "GET_CYCLE_TIME", _nIntarray[], _rRealArray[]) rTimeToBrakeTest = (_rRealArray[1] - _rRealArray[2])
BrakeTestDevName[] is a global variable declared in the BrakeTestReq module, so you won't need to declare it. The result of the subtraction is the remaining time to the brake test, in hours. Whenever it got below 5hrs or so, we would set a signal to our cell PLC that would cause it to send over the external Brake Test Request input the next time the robot was at Home in CELL.SRC, waiting for a PGNO. That way, we could insert a Brake Test as needed into our process well before there was any risk of the system-level Warning signal tripping us up.
-
Is there a Gripper Open status input?
One way to capture the root cause would be to over-constrain the handshake:
Code
Display MorePTP PrePickPosition CloseGripper = FALSE OpenGripper = TRUE WAIT FOR GripperOpen WAIT FOR NOT GripperClosed LIN PickPosition OpenGripper = FALSE CloseGripper = TRUE WAIT FOR NOT GripperOpen WAIT FOR GripperClosed LIN PostPickPosition
I wouldn't want to use that code in production as-is, but for testing, it can help narrow things down, like eliminating the possibility that GripperClosed is already True before CloseGripper output is set. If you get all the way to PickPosition and the robot still moves without waiting for the gripper to be closed, then you are definitely receiving the input prematurely -- either the sensor is incorrect, or the PLC is reporting falsely. You could also add a WAIT SEC 5 (or some more reasonable number) after the WAIT FOR GripperClosed and see if that fixes the issue -- if it does, that's more proof that the GripperClosed signal is coming through prematurely.
-
Torque Monitoring and "collision detection" are the same thing.
You can't really get the torque values set wrong, b/c you have to "train" the TorqMon for each move in each program (by running the program several times without any collisions). Once it's been trained, the tolerance values for each motion are set and used for the monitoring limits.