normally case like this is related to RDC or data cable X21-X31 (for example many people loose rubber O-ring at one of the connectors, pushed or bent contacts etc). But it may also be due to connection problem or faulty device elsewhere on KCB
Posts by panic mode
-
-
No...
replace person that did sizing and selection
-
[size=1em]"Everything is connected" is NO guarantee that all connections are really correct and that they match work visual project.
Ever seen idiocracy movie?[/size]External Content www.youtube.comContent embedded from external sources will not be displayed without your consent.Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.[size=1em]Just like in a plc - you CAN assemble valid unit from mix of parts (different processor, variety of communication and IO modules). But if your plc project (software configuration) does [/size]
[size=1em]not EXACTLY match your hardware selection (uses same components, and in same ORDER), your Plc will have NO chance of working correctly....[/size][size=1em]Same applies to robots and WorkVisual configuration. Your project must contain [/size][size=1em]right [/size][size=1em]hardware, [/size][size=1em]right [/size][size=1em]topology for each bus etc. Simply "connecting things" is not enough.[/size]
[size=1em]One Rdc can be used for up to 8 resolvers. This is not enough to connect 6-axis robot and 3-axis positioned (6+3 > so you [/size][size=1em]must [/size][size=1em]in this case have second RDC. There are different ways to connect RDCs and they must each have valid FSoE address.[/size]
[size=1em]Next all axes must be connected to CORRECT ports of RDC. If they get mixed up, all incorrectly connected axes WILL loose mastering. This happens easily on external axes since resolver cables are individual and most people assume it is all plug and play and doing so without training is somehow supposed to still be ok. I would recommend to check motor connections are really correct and once they are - label everything. Swapped axis cables will also cause runaway axis problem and robot will fault after "buzz" or "kick" of all axes.[/size]
-
[size=1em]
I really need your help with this.
...
I would really really appreciate your help!!!P.S: I attach the picture.
[/size][size=1em]
i tried but advice had little effect...
[/size]
for the safety configuration, i dont get any notification that there are diferences. The machine data is up to date.i will keep trying to solve the problem
what do you mean you got no notification? did you READ message KSS12032 in your own screenshot?oh well... just keep trying and tell us what you think may fix it...
elevation can be easily measured by tape and entered as $ET1_TA1KR.Z (in example posted by DannyJR, mounting robot on a rail, raised it by 450mm).rotation angle values in transform are more important and - they depend on particular mounting orientation of the robot on a carriage. Kuka rails have carriage that allow up to 8 different mounting orientations, each with own transform. example shared by Danny is just one of those cases.
-
Your second issue is MADA mismatch. Login as safety maintenance and go to Safety Configuration ....
-
Axis will work correctly but it need to be comissioned fully and correctly...
Reason tcp is not staying is that transform is not correct or that scaling for your linear axis is not correct. First make sure scaling is correct ( if you jog E1 1500mm for example, smartPad shows that it moved 1500mm.
Next use correct transform for E1. This will depend on way robot is mounted onto carriage. -
if TCP of robot guided tool is closer to robot flange, and robot is commanded to go to same fixed point, robot will move closer to that point to compensate for shorter tool (programmed point will bring any TCP to same point). by feeding new TCP data and sending robot to same point, robot will do all the work of "threading the needle".
-
here is some code to read, writing is very much the same...
https://www.robot-forum.com/robotforum/kuk…88863/#msg88863 -
-
X12 comes in different versions (Beckhoff IO or IOB-16-16B)
X41 is not on controller, it is on Agilus robot arm.either way, check documentation. topic READ FIRST explains where to find it.
-
Note, when buying ProfiNet for KRC4, you need to pick either device only (slave only), or controller+device (master or slave or both). first one is cheaper but it cannot ast as master. KLI port is used for ProfiNet.
IF you are planning to use ProfiBus on KRC4, you still need to chose if KRC4 is going to be master or slave or both:
EK1100 = EtherCat Bus coupler (conects to EKB, that is either X44 on CCU or X65 if external)
EL6731 = Profibus master (if robot is to work as Profibus master)
EL6731-0010 = Profibus slave (if robot is to work as Profibus slave)case A:
ProfiNet with three nodes (PLC, KRC and ET200S), one connection is PLC to KRC and PLC is master. second connection os KRC to ET200S and KRC is master. requires profinet version that is both master and slave. ET200S requires ProfiNet bus coupler.case B:
ProfiNet with three nodes (PLC, KRC and ET200S), PLC is master, both EK200S and KRC4 are slaves to PLC. this can work with ether ProfiNet version (KRC is slave only). however in this case robot does not have direct control of ET200S I/O (PLC must be powered and working as transfering data between ET200S and KRC). ET200S requires ProfiNet bus coupler.case C:
one network is ProfiNet (PLC is master, KRC4 is slave), can use either ProfiNet version (KRC is slave only). second network if profibus (KRC4 is master, ET200S is slave). ET200S requires ProfiBus (DP) bus coupler. KRC4 requires EK1100+EL6731 (master).case D:
ProfiBus network PLC-KRC (KRC requires EK1100+EL6731-0010)
ProfiNet network KRC-ET200S (KRC4 is master and needs ProfNet version that is master, ET200S needs ProfiNet bus coupler)case E:
ProfiNet network, KRC4 is master, PLC and ET200S are slaves (KRC4 is master and needs ProfNet version that is master, ET200S needs ProfiNet bus coupler)case F,G, H.....
basically you can mix and match whatever you like...
Note DP coupler is needed if bus segment is too long for selected baud rate or when there are more nodes than one segment can handle (32).
-
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.
how about keeping things as they are (stationaty base and tcp is on product) but keep recalculating TCP using model data for product?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.
-
ok so diameter is more or less constant but you have part that is irregular and you need to thread it though the braiding point.
not sure how many revolutions part needs to make from begin to end of the braiding but it looks like A6 may need to be endless. -
picture or sketch would be appreciated... is this base moving (rotating?) is mandrel rotating? do you know the radius of mandrel at any time?
-
there is no folder "KRC\MADA" or "KRC:\MADA"
-
are all axes connected?
are they connected correctly (no mixup)?
is second RDC connected?
is deployed project correct (matching current hardware, topology) -
To display KUKA messages, you need to be able to extract them (using KRmsgNet). But that may not be needed...
To simply show that robot could use a BCO, there is a system variable for that $MOVE_BCO. Read system variable manual...Also handy - get messages manual from the download section of the forum (it is for KRC2 but that does not matter)
-
The only "$custom.dat" file is in folder "KRC:\STEU\MADA"
-
you cannot have two $CUSTOM.DAT files, correct one is in KRC:\STEU\Mada\ folder
-