Posts by SkyeFire
-
-
Hm... the most recent time I had this error was when I had to change the kinematics of a SafeOp robot mounted on top of a KL external axis (the robot was mounted 90deg different than the config). But as soon as I opened the Safety Config, I got the same type of pop-up alert you normally get after making a change to the safety configuration, with a demand to approve or revert the new configuration.
My best guess is that something about the bad powerdown may have affected your kinematic configuration between the robots. But I'm not sure how RoboTeam handles SafeOp -- does the Master monitor itself and the slaves?
-
OUTB3 in IOSYS.INI is $OUT[25] through $OUT[32].
-
It definitely does matter which serial port. One is COM3 and belongs to KSS, the other is COM2(?) and belongs to Windows.
Those settings look reasonably correct, off the top of my head. But I don't have my references immediately available.
Are you trying to Telnet on the robot? That Telnet command only works on the robot's internal network -- you can't do it remotely from a laptop (well, not without some special routing tricks).
It should be impossible for that Telnet to fail, however -- if it didn't work, the robot should be nonfunctional. How are you starting the Telnet session, exactly? You generally have to jump to the Windows menu on the pendant, open a command prompt window, then use the Telnet command. It got a bit weird over the years -- some revision levels used just "Telnet", some used "TelnetK," and others used "Telnet95", IIRC. -
-
The KRC serial port is also picky about having the "control" pins wired up (covered in depth in previous forum postings), and some cheaper USB/RS232 converters, cables, and loopback testers will leave those out. Regular PCs will often be able to overcome this, but the KSS serial driver is more particular.
-
A typical FIFO buffer would have to be shifted every time a new element was added or removed. So a ten-deep FIFO would take 11 read/write cycles every time you did anything with it. You appear to be achieving a FIFO-type functionality without that burden by using a circular buffer and merely indexing the read/write indices around the ring.
Mostly a difference in semantics, really.
If you have a programmed robot motion that only takes a few milliseconds, that's a badly programmed motion. You end up getting lots of tiny stop&go motions, or lots of speed variance, b/c the points are too close together for the path planning to work optimally. It's a bit like the CAM Smoothing option in Fusion 360: https://www.youtube.com/watch?v=5PKR5ansIPo
Except in this case, you have to take care of handling the minimal spacing between points yourself. Robots are less amenable to "lots of tightly-spaced points" than CNC machines -- they're much more optimized towards a smaller number of points, spaced well apart.With DeviceNet polled I/O, the values are "static" until a refresh happens. That is, if you read the inputs 5 times in between refreshes, you'll simply see the same values 5 times. You can actually do this yourself by setting up a simple .DAT file array and running a loop to record to it:
If you feed the robot a sine wave on that 32-bit input, the values in the LogArray, plotted graphically over time, will show flat plateaus where your read loop is happening faster than the I/O refresh. Comparing the sine wave the robot records vs the reference sine wave you know you're sending will tell you a lot about your total system I/O refresh, between the robot, the DeviceNet driver, bus propagation, and input device update rate.Parallel-processing motion can be tricky. To avoid any stop&go, your buffer has to stay ahead of the Advance pointer. So when using $ADVANCE=1, if the robot is moving from P1 to P2, you already have to have valid data for P2 and P3, and you have to have valid data for P4 before the robot reaches the mid-point of the approximation path through P1.
-
The USB is on your laptop, not the robot, correct? In that case, the USB converter should not be the problem. However, I have encountered some cheap USB-RS232 converters that can be... unreliable.
Still, if you've used it before successfully on other machines, I would rate it unlikely to be the issue.
Have you tried putting a serial loopback connector on the robot to see if Tx/Rx works? Or on the laptop side? It's a good test on both ends.
I'm puzzled about the Telnet failing. What exactly is happening there?
-
No, it works fine -- I've done it many times. It simply depends on the relationships between the pre-shift Robot Base, Vision Base, and Pickup Position being set up properly at the beginning.
Hm... I don't have any graphics handy, but imagine it like this:
1. The original, un-shifted Robot Base and Vision Base are taught to be co-located and aligned at one corner of the pallet
2. The un-shifted Pickup Position is taught to the center of the workpiece, with one corner of the workpiece touching the Origin of the Bases, and with X&Y aligned with the Bases' X&Y.
3. A workpiece is then placed on the pallet at X 100, Y 200, A 45deg, relative to the original un-shifted position. The vision measures this 3-DOF offset
4. The robot receives this offset from the vision system, and applies it to the Base using the Geometric Operator. The Base is shifted relative to it's original, un-shifted position by X, then Y, then A
5. After the shift, the robot Base will be co-located and aligned with the corner of the shifted workpiece, just like it was during setup, and the Pickup Position will be above the center of the workpiece, and aligned with it, b/c it was "carried" by the Base -- the relationhip between the Pickup Position and the Base never changes. The Base simply gets shifted to follow the workpiece, as measured relative to the original un-shifted position by the Vision system. -
You have multiple different issues here.
1. MACHINE.OLD is reporting a compilation error. If you find it, it should definitely have a red X through the icon
2. The A20 module is reporting a header error. This is pretty unusual, unless someone has been tampering with the module via a text editor. Pull the A20.SRC and A20.DAT files and post them.
3. Your RDW and controller data do not match. This should not be a fatal error, but should be corrected.
-
Any module whose icon has a red X.
-
I don't think I've ever seen a point shift used with a stationary vision system -- only with vision systems carried on the end effector. It can be made to work mathematically, but I don't know why anyone would bother.
For a Base shift, the key is to create your original Base (with 0 offsets), and align it to the vision system frame of reference (or vice versa -- it doesn't matter who gets changed, but they have to match). Put your work piece in a position where you want the vision system to produce 0 offsets, tell the vision system to use that as its zero reference, and teach your Pickup point there. Then, whenever the vision system finds the workpiece at some other location, it feeds an offset relative to the zero-reference position to the robot, and the robot shifts the Base to match. Having the Base origin centered doesn't matter -- the saved value of the Base simply has to agree with the vision system's base when all offsets are zero.
With a starting A6 value of 20, there should not be any issues -- A6 can rotate by +/- 350 degrees. As long as the A correction from the vision system doesn't exceed +/-180....
Wait... I meant to limit the vision system's rotation to +/- 179.999 -- did you do that, or did you limit A6? Because the latter definitely won't work.
-
but inputs are read only...True enough. I was mainly thinking of the outputs. Unfortunately, we know nothing about what is controlling the inputs....
-
Do any of your modules show compilation errors?
-
-
Your description makes no sense. You say that adding "KUKA I/O modules" under Profinet works, but they communicate using EtherCat? Those are completely different busses.
"Network Adapter" is actually for the network port on your computer, not on the robot. It's to enable online diagnostics of Profinet connections, although frankly I've generally found WorkVisual useless for this.
Once you have added a Device to the ProfiNet tree, you need to open the I/O-Mapping window. In the top-right window, open the FieldBusses tab and select the Device. In the bottom-right window, the I/O on the device will appear.
In the top-left window, select Digital Inputs or Digital Outputs. This will cause the bytes of the robot's internal I/O table to appear in the bottom-left window.
Hilighting an equal number of bytes in both the bottom-left and bottom-right windows (must be Input-to-Input, or Output-to-Output, don't cross them) will cause the "Connect" icon (located below the boundary between the lower-left and lower-right windows) to illuminate. When the Connect Icon is not grey, your mapping selection is valid. Pressing the Connect icon will create a connection between the selected bytes, which will be displayed in the middle window.
-
That depends on what interface options your KRC has. If your KRC has EIP installed, for example, suggesting a ProfiNet HMI would be worse than useless.
-
All right...
1. Why are you performing a shift on the Pick position, instead of on the Base?
2. Is your vision system carried on the robot end effector, or stationary above the pick area?
3. When your Offset.A value is 0, what is the value of A6? Ideally, your "neutral" pick position should be programmed as close to A6=0 as possible, in order to maximize the available rotattion envelope.Normally, performing simple addition on the A value of a Cartesian coordinate will not work properly -- a Palletizing robot is a rather special case where this can work, at least part of the time. But to perform the Euler rotation properly, the Geometric Operator should be used. However, neither of these options provides control over the S or T values.
One issue here is that when the Offset.A value exceeds +/-180deg, the "shortest path" in Axis space from where the robot begins, to the Offset position, is to "shortcut" around the other way. So achieving an offset of +190deg is easier to reach by rotating -170deg, and the robot will do that naturally. The end result is the same position in Cartesian space, simply with a different A6 value.
In this case, making your motion LIN, or reducing your Pick position to a FRAME variable rather than a POS type, should allow the robot to work out its own path to the offset pickup without exceeding any axis limits.
-
When the robot program is reset, the input and output sets are inactive. What is the reason of thisMost likely, someone added a condition to the SPS to cause this to happen.
-
Windows "folder" -- what? In order to re-install Windows on a KRC2, you need the bootable installation CD, a keyboard, and a mouse (probably PS/2, for a KRC2 that old).
If the BIOS is not set to boot from the CD first, you'll need to interrupt the start-up test (instructions on what key to hit will show up briefly in between the power-up and the first appearance of the Windows logo), go into the BIOS setup, and change the boot order to prioritize the CD over the HD.