Posts by wes_mcgee

Hmm,
I took a look at the post in notepad for fun...it actually looks like E1 is meant to be a rotary axis, as it is set to -C internally. So if tool were tangent to path, rotary would rotate to compensate. Which is making a lot of assumptions about the user, but with a little math you might be able to make that function for a linear gantry (remap the axis to the centroid of points for example). Moving it all the time wouldn't be very smooth in my experience.

Another old thread comes back around....function generator in KSS 5.x

I have the manual, which is quite helpful relative to any documentation on the newer KSS versions. But still missing a few pieces.

Currently trying two approaches, one being to use $DIGIN1 , since I am not using analog. My sensor data is mapped in via devicenet as a 32 bit signal. Also using KukaVarProxy (works quite well for some things actually).

My current issue with the digin, is that it has a scaling issue. I am baffled by this, but there is a lot of code on this old robot. I am pretty sure my bytes are mapped correct, and currently I am trying a DWORD on my PLC to 32 bit INDW in the IOSYS, with the DIGINCODE set to #UNSIGNED. But the signal has a nonlinear scaling ? PLC=500, DIGIN = 1000; PLC = 1000, DIGIN = 1250. Is the tech function persistent? I even rebooted.

Alternate method, the #DATALINK class. Writing a correction frame would be ideal, I have multiple ways to accomplish that. But how do I link the FRAME, I assume its not linked the same way as TECHIN normally is linked to the analog or digital? Why they completely omit that from the manual is a bit surprising.

Working on a project where we are looking at acquiring the KMP1500. As this is a research application, and we will likely do most everything in ROS or custom, I am trying to research the kuka navigation suite (especially to determine if we need/want).

Any chance the manuals are available?

I think you mean the EL6601. EL6692 bridges two ethercat strands. I have used EL6601 to tunnel ethernet over ethercat, and while it works, it is low priority. For example I was getting pings in the neighborhood of 60ms, whereas usually would see <1ms on dedicated wires. So don't try to use it for vision or something...

ah OK , yes am familiar with that package....just making sure there wasn't another way.

we do this, and we use stepper (and its also for a camera, ironically). Back when we had KRC2 we used a WAGO stepper drive directly in the field bus. This would require some extensive SPS programming though. Now with KRC4 we find it much easier to use virtual axis and drive the motor with PLC communicating to robot.

I haven't found any good small servo motors. Maxon seems promising. But stepper is so much easier, and pretty good power density (we use an encoder on the motor too, so its not completely open loop).

not trying to hijack this thread(some interesting stuff in here) but you mentioned feeding those points from an external PC. We have done work where we read from an external text file, but I am wondering if there are other ways you would write those points? I can imagine if it was just a few points, you could map I/O but I am assuming that is not what you are doing. Is there another way to change those points remotely?

I use BAS(#TOOL, 6) since this sets the load. I got lost though where you say that a lighter tool is causing an overload. My guess was the tool load is specified higher than 120, and its just complaining about that?

2: yeah I have worked on this for a while; and it is hard. some of the driver files on the controller declare public methods that you can use....and it works quite well. I think these are there so app developers who write plugins for the pendant can use them. Or maybe app developers like myself, show write software to interface with tools that can't be easily taught....like profile scanners...

Quote from panic mode

external TCP just swaps tool and base so part carried by robot becomes workpiece and external TCP is a base.
TCP allows for convenient rotation about point. i dont see how this would change things as you still need to move workpiece relative to it.

Wouldn't the difference be that the speed (in #TOOL mode) will be calculated at that (fixed) tcp point in the center of the braider? My understanding was that was the whole problem/goal. Otherwise in Base mode, reorientations will cause the actual mandrel speed going through the braider to get larger as the actual TCP gets farther from the center of the braider (not to mention the complexity of programming that motion). When you jog in #TOOL mode everything looks similar but the reorientations always pivot around the external tcp (which seems like it would make this easy).

I suppose it would also be worth asking whether this is being programmed offline or teach based.

how about keeping things as they are (stationaty base and tcp is on product) but keep recalculating TCP using model data for product?

I agree this would work but changing the TCP will cause advance run stop correct? I assume the braider is constant speed (not synchronous to the robot)...

since the part is not straight rod you need to know the shape in one way or another (cad, polynomial expression, learned, manually taught or whatever). since all parts seem to be same (at least in one batch) and they in one plane, learning could be a good way to get the shape profile fairly quickly (much faster than any other method) - only need a sensor and few lines of code.

Display More

what $IPOMODE are you using? If #BASE, then this would be very hard, as of course the tcp is not always at the center of braid ring. In #TOOL, this sounds pretty easy to do.

I don't have an iiwa, so I don't know if the FRI lets you do something special. On KRC4, I would then map those to the robot outputs(by grouping the bits to match the 32 bit int), and then map these to an ethercat bridge (hardware device installed on the X44 bus) to a PLC. The PLC would then have an API you can access via the PC. Given you are on sunrise, probably there is a more direct way to access the robot outputs, via some other communication?

Obviously, this is a lot of components you may not have yet. If you had a PLC with ethercat, you could also just connect the ATI directly to it(thats what I do with my KRC4). In that config, I simply pass the robot position via the bridge, and assemble the data on the PLC end. You may get better sync doing it on the sunrise end though, as with my method the ATI data is 4 ms "fresher" than the position data. What protocol does FRI use? TCP/IP I assume?

You can definitely use SLIN outside a spline block. Sucessive SLIN blocks stops at the end of the move in my experience(SLIN-SPL-SLIN will move continuous though); the C_DIS command is only relevant when the next move after SLIN is LIN/CIRC such that it will approximate the last SLIN. But to be honest, I am not sure if I ever tried two successive SLIN moves with C_DIS set on both, so maybe I will need to give that a try.

This might work with SLIN but SLIN stops the motion at the end of move anyway. And its not going to work with a spline block, as that has to be preplanned completely(and in my experience maximum 800-1000 points or crashes entire controller). Interesting ideas though, would love to hear if they work.

You mentioned EIP, I always thought of this as simply a communication protocol, versus say the native ethercat. Would the same approach be possible with ethercat, or does the EIP option package have some other advantages? If FeedRate can be declared in the Config.Dat, maybe there is a way to simply update that variable via Submit. For example we have a FRAME mapped where we can change the base via PLC (you could do this with RSI). Of course to make it active it has to be assigned in the SRC, but you are already doing that in the WITH $VEL.CP = FEEDRATEARRAY. The key would be making sure its updated fast enough in the SPS. Not to mention syncing with the PLC to make sure its on the right feed value.

there are a few research papers around that deal with this; its a fairly hard problem. Most approaches take advantage of moving very slowly, so that there is no need to account for dynamics, and the net values can be estimated(by looking at the steady state before contact). Even then you have to deal with the kinematics. I think this involves solving the jacobian, basically the derivative of the IK matrix....but I can't tell you much more than that, or how to do it.

as far as the values you mentioned, I assume this is KRC2? I never did much with torque on KRC2. KRC4 has $TORQUE_AXIS_ACT. It seems there is also a $HOLDING_TORQUE value calculated by the dynamic model. I haven't tried it, but apparently it takes into account the payload and current pose to provide values for "holding position". The net torque "might" be as simple as comparing the actual to the holding. Once you have the net torques, then you can get on with the linear algebra...

I think for this you need the special variant of the EL6695 that is sold by Kuka to support FSOE(maybe you have this?)

if the focus is dynamic, then it needs to be a controlled axis. Then you can solve the path/tcp problem via offline programming(or online via RSI I suppose). Also a possibility would be if you could compute the dynamic TCP externally, and then read it via submit interpreter. We have implemented this for modifying the BASE. But changing the TOOL this way will stop the advance run pointer. Also you mentioned smoothness, of course the approximation parameters and TCP accelerations need to be adjusted.

you don't need EK1100 in the krc4 if you don't want it....you can connect the KRC X44 bus directly to the(X1 port of) bridge installed on the external CX.

we have observed the same issue, on tightly curved paths at velocities of .05 - .1 TBH what you are seeing is not "that bad". I have seen it shake much worse... usually if you loosen the approximation distance values it will smooth out. But I have also noticed this seems to happen in certain "areas" of the work envelope. Of course if you are reaching a long way that makes it worse, but not always... and you aren't reaching that far. Also FWIW, I use the LDD software, and have a tool about 50% of max payload. Doesn't seem to affect things like this, though it certainly affects the robots ability to "maintain" accuracy as it reaches farther out. I tend to lean towards the "its not a CNC machine" explanation. You are weaving the TCP pretty quick. Also, how smooth is the path? That has a huge effect. If possible, use splines, they can definitely be smoother at higher speeds. Unfortunately, I can rarely use them, as you can't really go over 800-1000 positions in a block. If I had to bet on the way to fix it, check your $APO.CDIS....

Thanks!