correct. this also begs the question how the LDD is obtained. KUKA would not offer it with robot that is not yet supported. if mistake was made, ask for refund or software update. normally this is easily fixed by newer software release as more robots are added all the time.
Posts by panic mode
-
-
Normally robots have no I)O at all, this is something users need to add. Different fieldbus options exist. Your search should start with IOSYS.INI
-
Small test program to convert points of measured bases into more friendly format so they could be easier processed by CWRITE for example.
it writes target file on startup, or whenever the XML file is modified or also if target file is missing (deleted by CWRITE perhaps).
as always use at own risk...
-
you can just declare your own signal to look at the range you are interested in. for example
SIGNAL TPSI_CH8 $OUT[2256] TO $OUT[2271]
then you can monitor it like any other variable using name TPSI_CH8
-
How are you trying to add three axes?
What wiring changes we are talking about exactly? What configuration changes, exactly?
Why do you suspect problem is with KPP if the system works without external axes?
-
ok, just to be sure i do not state anything incorrectly, i did a test with KVP, KVP4C4 and C3B.
all of them will write outputs... unless program is running. KVP4C4 also requires controller to be in automatic mode.
it does not matter if the drives are enabled - that restriction is something only KSS HMI does.
tested versions
C3B = C3Bridge 1.4
KVP = KukaVarProxy 6.1.101
KVP4C4 - KukaVarProxy for KRC4 server 1.0.0.0
-
that looks good. this hood is top entry which should not matter but i think the hood used by kuka had side entry
-
don't see why this should be hard. post #2 shows that this is DD series and inserts are 12-pos.
09 14 012 3101 Han DD module, crimp female
09 14 012 3001 Han DD module, crimp male
check this out
-
and you are free to ask...
one can do this on their own ...or ... let the supplier come up with something. when i am pressed with time, i ask suppliers or manufacturers for help. they want your business and this is why they have product specialists. part of their job is exactly this. why are you not willing to pickup the phone?
If you call your local electrical distributor, they may bring their kits and test it on the spot. if you tell them that you are expecting large volume of those, they are likely to send you free samples. btw. you can order free samples directly from Harting website, without ever talking to someone....
-
you should take KUKA training.
some variables are read only some are not. and just because variable is read/write type, it does not mean that it can be modified any time and by anyone.
also read pinned topic READ FIRST. when asking software related questions state software versions. you only mentioned KSS8.3 but not KVP version.
inputs and outputs are treated differently than any other variable since they are meant for interfacing with outside world. for example they can be used for handshaking with other equipment and timing is important so default is that access to I/O variables triggers advance run stop.
also toggling outputs is meant to work only when robot program is not running. also it may need drives to be on.
so why not let the IO be IO. if you need to read/write some variable, create own variable and do whatever you want with it.
also if you have specific case in mind, state the details. for example which KVP you are using? the classic one or the newer one called "KVP for KRC4"? they do not work the same way....
the new one has ability to access robot without being itself installed on the robot or have anything modified on the robot (open port or whatever). but it has limitations too, it can write variables only if controller is in automatic mode.
-
then stop trying to get them from KUKA. KUKA support for this ended 10 years after these robot systems were discontinued. but...
those are just standard Harting parts and should be readily available. just call your Harting connector supplier and show him the picture. also other manufactures make the same things as well ("passt-genau" / " exact-fit") so may want to check them too (Weidmuller, ILME, etc.)
-
; declare signals... they are integers.
SIGNAL ROBOT_A1 $OUT[1] TO $OUT[32]
SIGNAL ROBOT_A2 $OUT[33] TO $OUT[64]
SIGNAL ROBOT_A3 $OUT[65] TO $OUT[96]
SIGNAL ROBOT_A4 $OUT[97] TO $OUT[128]
SIGNAL ROBOT_A5 $OUT[129] TO $OUT[162]
SIGNAL ROBOT_A6 $OUT[163] TO $OUT[196]
; multiply by 1000 to get three decimal places
ROBOT_A1=$AXIS_ACT_MEAS.A1*1000
ROBOT_A2=$AXIS_ACT_MEAS.A2*1000
ROBOT_A3=$AXIS_ACT_MEAS.A3*1000
ROBOT_A4=$AXIS_ACT_MEAS.A4*1000
ROBOT_A5=$AXIS_ACT_MEAS.A5*1000
ROBOT_A6=$AXIS_ACT_MEAS.A6*1000; on the PLC side multiply by 0.001 to scale the received values back.
-
the post #1 shows they are defined after DEF line so it must be SRC file.
WoV may complain but the code in that post will be fine on the robot.
line 9 could be
Holder_HSK1000.Compensation = {X 0.0,Y 0.0,Z 0}Holder_HSK1000.Compensation = {X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
Holder_HSK1000.Compensation = {X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}, S 0, T 0, E1 0, E2 0, E3 0, E4 0, E5 0, E6 0}
or
Holder_HSK1000 = {Compensation {X 0.0,Y 0.0,Z 0}, Position {X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}, S 0, T 0}, Validity TRUE }
-
my boss has asked me to look at running the robot 24/7. My gut says the robot should not be running unsupervised ...
sounds like you are having confidence problem with the current setup.
but take a look at all the industry - how many robots are supervised? so many plants are packed with robots that do their job 24/7, doing all king of work - spot and arc welding, palletizing/depalletizing, machine tending (cnc load/unload, press transfer...). 99% of the processes are too fast for some observer to react. EStop is there to disable system manually which is very subjective and not very timely. after all it relies on someone to pay attention, notice and react. suppose you have someone with gamer reflexes diligently watching the robot operation and keeping hand near button. suppose that person is really fast and could press the button in decisive moment. how long would production run before this guys gets bored and looses focus?
the idea with automation is not to have someone babysit ,machine but to have machine sense abnormal situations and stop on its own. then maybe some day that happens and you loose productivity for several hours - until morning when humans arrive. but that is few hours lost, versus MANY nights that process keeps running (something that it is not doe now). i think the benefit is clear.
-
cant argue with that. i always take full image of the HDD first (as soon as possible) - even on a brand new system that is still on a shipping skid. its the best spent 10 minutes that can save you tons of grief. and on older system, HDDs tend to fail. they are literally ticking time bomb.
-
that is top of the list... you should check the oldest messages first, they may have additional clues. also check logbook (menu Diagnosis > Logbook) as some may already be cleared.
MD5 check is used to evaluate file integrity. messages complaining about MD5 suggest that there is a corruption or failure to transfer files (on powerup programs are loaded from HDD to RAM drive).
first thing to try is to make fresh backup (just in case) then restore HDD using known good image
-
why greater than zero? that is excluding cases where tool or base number are zero...
btw (just a general note) one should also be mindful of using VarState() on structures....
structures are complex data types and this function will return true even if initialization is only partial.
example:
CodeDECL FRAME F DECL BOOL b1,b2,b3 b1= VARSTATE("F")==#INITIALIZED ; false, F is not initialized F={X 0} b2= VARSTATE("F")==#INITIALIZED ; true although only F.X is initialized b3= VARSTATE("F.B")==#INITIALIZED ; false BASE_DATA[1]=BASE_DATA[14]:F ; err since F is not fully initialized
one can letting code run in Submit and after while compare how robust solutions are.
and the safest way is to use ON_ERR_PROCEED.
-
if you are climbing, you need to overcome couple of things:
1. gravity
2. friction
3. air resistance etc.
the air resistance is not going to be the problem due to (assumed) low velocity.
friction if a function of contact force and friction coefficient.
the gravity is by far the largest component (if this are done correctly).
this can be done differently with varying degrees of complexity. the quickest and simplest way is to use energy.... height is a factor in potential energy. speed is a factor in kinetic energy. mass is a factor in both of them. energies add up. power is a rate at which energy changes. so knowing how fast the climb need to be along with how much energy is needed you can calculate power.
from there you can get torque. you can use mechanical advantage (gearbox, pulleys, wheel size...) to get more torque. tradeoff is the speed.
-
at around 1:30 voice is justifying -1kg in load settings as a cure for everything even though the load changes from 0 to couple of hundred of kg. this is not a good idea. use correct load all the time or as close as possible. 0kg and 200kg are very close if the robot was rated for 20000kg but - it is not.
if only using ILF motions, define two (or more) tools with same TCP and orientation but with different load. then use them accordingly. for example tool1 could be gripper empty, while tool2 is gripper with large load.
-
the video is quite blurry at first.. but after 13sec or so, it clears up significantly.
around 37 seconds one can see as expected that B=90deg
voice in the video ask repeatedly if the issue is mastering. no, it is not. issue is gimbal lock.
avoid CP motions when A5 axis is close to 0deg. this is something one need to consider in early stages of design, before robot is permanently mounted. it is a common problem as most people consider "reach check" to see if arm can stretch far enough. but singularities are common.
on a 6 axis robot there are 3 singularities, two of them are not much of a problem as the space they appear in is very limited:
alpha1 - singularity when wrist root point (intersection of A4,A5,A6 axes) is directly on rotating column axis. this is not single point it is a vertical line (column) about which A1 rotates.
alpha2 - when linkages of A2 and a3 are in a straight line (stretched in any direction). this is a thin onion shell near axis maximum reach so also not a problem in most cases. in other words, also easily avoided in most cases.
alpha5 - when A5 is close to 0. this one IS a problem... because this can happen practically anywhere inside robot working envelope.
avoiding singularity means designing cell so that robot does not move with CP motions near those points. also this only affects CP motion so workaround is to use PTP motion to pass through. while PTP motions are not a straight line, it is a pretty close (nearly linear) when points are not too far.
a common place for this is default HOME position. in this configuration, robot is in Cannon pose and A5 is at zero. so trying to move robot using any Cartesian motion will lead to difficulties. and for people unfamiliar with robots, it is rather common that they do everything in WORLD. So to help them avoid calls from clients i usually move the robot slightly off and then teach home.