Well, you could try using the Forum's search tool....
Posts by SkyeFire
-
-
Maybe? I haven't used the EtherCat bus very much, but from what I understand, it only works with a relatively small number of "whitelisted" components (last time I checked). The ProfiNet and EIP implementations appear to be much more thorough, in that you can connect nearly anything that has a valid definition files.
-
So... at the very end of the "error" plot, is that the robot catching up with the commanded position, or did it just stop 0.1mm from the final commanded position?
I'll admit, I've never tried having the robot chase a position in RSI -- rather, I had a sensor input that, through various PID gains, drove the motion correction until the sensor input was within tolerance for a given amount of time. It honestly may be that 0.1mm is under the robot's own correction threshold -- I've never dug into that with RSI. Hm... I don't know if $IN_POS_CAR has any effect on RSI or not, but the defaults on my robots appear to be 0.1mm -- you could try reducing that. But be aware, reducing it may cause the robot to start "jittering" due to the inherent noise in the arm's kinematic feedback, so there's a point of diminishing returns there.
-
What are the four empty terminals on the second green terminal block for? Going by the labelling, you might be able to terminate power there, assuming those terminals are linked to the V+ and V- on the 5-pin connector.
Aside from that, usually the quick test for I/O is to wright a program that will "sweep" all the output bits and turn them on, then off, about 1/sec. You run it while watching the output LEDs on the slave module, and confirm that the bits line up.
-
Okay, you need to install the correct KUKA driver for the add-in ethernet card. This card cannot be configured from Windows -- in fact, the KUKA driver will make it invisible to Windows, placing it purely under control from the VxWorks side of the robot's brain. The IP address of the realtime ethernet card is controlled from the "e=" settin in VxWin.INI.
-
Well, have you confirmed that any traffic is getting in or out through the COM port? Have you put a loopback tester on the COM port at either end and confirmed that what you transmit is echoed back? Have you opened a Telnet window on the robot to 192.0.1.1 and monitored it while the CRWRITE/CREAD is carried out, to see the raw COM-port buffer values?
-
Yeah, that second socket can't be empty -- that's half your servo drives, right there. There should be a matching socket on the KRC2.
Basically, where most KRs only need two cables from the cabinet to the robot (one motor power, one resolver), the big ones require three cables -- two motor power cables, to reduce the current load per cable, and one resolver cable.
-
No, you don't -- the encoder values are irrelevant. The Mastering process is dynamic -- when the Mastering process is completed, the RDC card records the encoder value at that position and treats that as 0 forever, or until something changes/erases it.
-
It's been a long time since I used a KR350, but I believe it may have required a "double" motor cable, due to the large servos it used (I know the KR500 did). Is there a large Harting rectangular connector left empty at the base of the robot?
-
1) After one day of milling and tuning my CAM to get hi precision details I still cannot get sprutcam to do not break big arcs in tiny segments and get the robot slowing down to much. The problem is important as you calibrate spindle speed according to feed speed as well and I'm noticing that tool is overeating when the robot slows down, but I cannot slow spindle speed down otherwise, on fast paths, spreed would be too low... The geometries I export to sprutcam are arcs, so there must be something in sprutcam to control this.2)I guess I cannot use $APO.CDIS as I understand (maybe I'm wrong) that it approximates corners by a certain distance, which means that I'm gonna loose precision in details.
3) I checked the $filter variable and I guess that for milling operations it could be very important to reduce vibrations due to speed and direction change. How doe it works? The highest the value the smoothest? Where I should place this variable?
1. Any chance you could control the spindle speed dynamically, so that it speed up and slows down along with the robot's linear speed?
2. I don't know enough about SprutCAM, but you might be able to use Spline motions?
3. See my other post. Normally, this variable is set at the factory and never altered except by very high-end users with very exotic requirements. I only toyed with it briefly on one project years ago. In your case, I don't think you want to tamper with it. It's just a matter of being aware that programming a series of very small, tightly-packed motions might behave other than expected, in part due to $FILTER (and other motion-filtering safeties in the robot). -
SkyeFire:I looked up the $FILTER system variable. Would you be able to elaborate a bit on the effect of choosing a certain value from the range of integers 0-16, and how the magnitude of that value would affect acceleration versus some other smaller or larger value?
Many thanks in advance.
It's been a while, and the documentaiton I recall was a bit contradictory, but the basic idea of $FILTER is that it established a minimum amount of time (in IPO cycles, IIRC) any motion command must be spread across. The idea is to force a certain minimum degree of motion smoothing, even under RSI. Think of it as a small low-pass filter on the motion planner.
In effect, if a sequence of three motions (A->B, B->A, A->B) is programmed such that the motion between the points takes less time than $FILTER dictates, the motion planner will slow the motion down so that it is "stretched" out enough to take as long as $FILTER requires. Reducing $FILTER can allow the robot to jerk hard enough on closely-spaced motions that it can damage itself, especially under RSI control.
-
Is the robot configured to require a separate safety-reset button, or to auto-recover from a safety fault when the PLC asserts the signals?
Is this robot using SafeOp?
-
Check the Robot Data values from the hard drive against the RDC.
Check the KRC2-RDC cable.
Past a certain age, the batteries may stop holding a charge.
Error 21 is odd -- is this robot set up for external axes?
Comment out the Interbus driver in IOSYS.INI -
And/or plug in an external monitor.
-
-
There is an emergency, field-expedient method, but it's not as accurate as using an EMT/EMD.
You use the Dial Mastering menu, but instead of attaching a dial indicator to the mastering gage, you press in the mastering gage pin (with the tip of a pen, for example -- DO NOT USE ANYTHING THAT WOULD MAR THE METAL SURFACE), and feel the transition while someone jogs the axis, Very Slowly (1-3%), in the negative direction, across the V-notch in the top of the mastering feature. The axis is at Master position when you feel the very bottom of the V-notch. Getting it dialed in may take several tries.
-
Well, that looks like a fairly normal acceleration curve. Projecting the robot position curve further, it looks like the robot is on its way to catch up with the commanded position. What happens if you run that longer? Alternatively, what happens if you run the commanded position to a certain level and stop, and then watch how the robot catches up? My gut feeling is that the robot position plot would look like an S-curve that merges to parallelism with the commanded position, after sufficient time to overcome the acceleration lag and play catch-up.
Looking at this, it looks like you're using the "dangling the carrot in front of the donkey" method. Are you implementing a PID anywhere to manage the delta between the current and commanded position?
-
Well, I would never depend on the 'default' Tool and/or Base values. Also, exactly what variable in $CONFIG.DAT did you change?
If your Tool and Base values are both 0,0,0,0,0,0, then moving to a position with ABC=0,0,0 should have the A6 faceplate pointing straight up. Is this what's happening?
...if you're not running to a programmed position, how can you say that the ABC angles "don't work"? What are your test criteria?
-
Have you tried it without FAST mode? I thought FAST was supposed to change to a 4ms cycle, but it could only work for certain types of actions, not across RSI entire.
Another thing: 12ms is the entire normal IPO cycle -- it's not 12ms to receive a command, then 12ms to execute. Rather, every 12ms cycle represents one entire I/O refresh, RSI communication exchange, and one entire motion step.
That said, the delay is odd. Do you have any low-pass filtering active in your RSI container? How large are the motion command increments you send every 12ms? If you plot the RSI inputs and the inputs to the POSCORR object using RSIMon, what does the lag look like there? RSIMon is the best tool for troubleshooting RSI behavior -- I would connect RSIMon "taps" at multiple points along a signal path through the RSI container and see if the lag becomes obvious at any particular point.
-
It sounds like your CIP master is not sending the safety signals when you switch to T1. Who's programming that PLC?