Thanks, that sounds great
Have a nice day!
/RoboticsMan
Thanks, that sounds great
Have a nice day!
/RoboticsMan
Hello Jeremy
It did help! Thanks a lot. But consider adding an option for attaching things to the links of the robot. I can't be the only one who needs to check whether the dresspack will hit something
/RoboticsMan
Hi all!
Does anyone know whether it is possible to mount a "dresspack" or something else on the shoulder of a robot in RoboDK? And if it is possible, how does one go about doing it?
Thanks in advance!
/RoboticsMan
My question was more about the record type itself. Is there any way around having to define the same type in both tasks? As far as I know, a record type that has been defined in one task can only be seen in that task. So if I want to use the same type in another task, I will have to define it again, right? I would like to avoid that.
/RoboticsMan
Hi!
I have defined a record type with some values that I will need in both the foreground task and the background task. I want to have a shared instance of this record type that can be seen by both tasks. What is the best way to do this? I want to avoid duplicating code if it is in any way possible, so I don't want do define the same record type in both tasks.
Thanks in advance!
/RoboticsMan
Thanks for your answer! That is about the same way I was planning to do it. I had just hoped that the robot would have some built-in way of seeing which signal we are waiting for, but I guess this will have to do.
/RoboticsMan
Use the Function ArgName(signalname) if you have it available. If fetches the original data object's name.
Thanks, but that is not quite what I want. In Kuka KRL, if I write something like this
then the robot will show a message about which signal we are waiting for (input 501). And if the user has added a description for that input, then the description will be part of that message. Lets say that the description for the signal is "in_gripper_close". Then the message will be something like "waiting for in_gripper_close == true". This message will automatically be shown when we are waiting, and will automatically disappear when the condition is met. Is there a way to get a similar behavior on ABB?
Im guessing I could add a message in the log window every time we are waiting, and another message when we are no longer waiting, but I don't think that is a pretty solution.
/RoboticsMan
Hello
I am working on a robot program where we create a signal from a string (name) and afterwards wait for a high input on that signal. Something like this:
So now my question is the following: Lets assume that the input does not go high. Will it in any way be possible for the user to see which signal we are waiting on (via the robot menus), or will I have to make some code for that myself? It is not very helpful for the user to know that we are waiting for temp_signal, he will want to know the original name of the signal.
Thanks in advance!
/RoboticsMan
Hi
I'm pretty new to ABB programming, so this might be a silly question.
Our robot program has two tasks. A foreground task and a background task. The foreground task takes care of moving the robot, and the background task takes care of controlling some external unit via I/Os. Now, my problem is that I sometimes want to control the external unit from the foreground task. So the code for controlling the unit must be available to the foreground task. I want to avoid code duplication at all costs. Is there a way to share FUNCs and PROCs between tasks?
Thanks in advance!
/RoboticsMan
1. How does the picking system avoid collisions between the EOAT and the bin wall, the EOAT and other parts, and between parts of the robot and other obstacles in the area?2. How many different part "poses" can the system locate and handle?
3. How well can the system predict and avoid overlapping/interlocking parts?
4. When the bin inevitably reaches a condition where there are parts left, but none of them are reachable, how does the system handle that?
5. How quickly can the system scan a bin and determine Pick and Pre-Pick positions? For how many candidates?
I would like to add a few more:
6. Does the system take the robot kinematics into account, in order to avoid joint limits and singularities?
7. How much robot programming is involved? Does the system only return a pick pose, or does the software control the robot?
8. How easy is it to calibrate the system?
9. Does the system have diagnosis functions that can help locate the cause of problems that may occur?
/RoboticsMan
On a KRC4, in C\KRC\Roboter\Config\System\Common\Mada\NGAxis\A1.xml I found the following:
<?xml version="1.0" encoding="utf-8"?>
<Axis xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="/Roboter/Config/System/Common/Schemes/NGAxis.xsd">
<Version Label="">
<Info Version="KUKA V8.3"/>
<Schema Version="100"/>
</Version>
<Machine Name="#KR16_3_TS C4 FLR ZH16_2"/>
<AxisData MessageDisable="0" Mode="StandAlone" Simulation="Off" SingleMotorCoupling="Off" Type="Rotator"/>
<ToolMotor AdditionalFunctionFile="Mada/NGAxis/CtrlA1AddFct.xml" ExtTorqueOfInertia="0.0002584" MaximalEnergy="920.83" MotorFile="Motor/M_H_KSP40_400V_V1.xml" ParameterFile="Mada/NGAxis/CtrlA1.xml" RampStopTime="215.8" RampUpTimeUnderLoad="410" ServoFile="Servofile/S_H_KSP40_400V_V1.xml">
<Monitoring PositionLag="250" PositionLagSoft="1000" Speed="5576" SpeedLag="0"/>
<Limit Current="0" Speed="0"/>
</ToolMotor>
<Inversion Position="false" Torque="false" Velocity="false"/>
<Delay ActValue="2" CmdValue="24"/>
<Mastering ChannelName="EMD-Data" Type="EMD"/>
</Axis>
Display More
I guess RampUpTimeUnderLoad can give me an idea about what acceleration to expect for axis 1 (ballpark figure) in this case?
By the way: $RAISE_TIME seems to only exist on the KRC2, not in KRC4 - even though I found a mention of it in the system variables manual for KRC4. Very strange...
Once again, thanks for the answer! It will be very interesting to see how close I can get to the actual performance of the robot.
A follow up question to this:
For example, in a KUKA controller, I can look at the maximum acceleration limit for each axis.
Where would you find these values on the Kuka robot? I looked in the $machine.dat, but I didn't find anything that looked like the joint accelerations. At least not in the archive from a KRC2 robot. The maximum accelerations might be good enough for me, as a ball-park figure would be very usable too. We don't need an absolutely accurate cycletime estimate. I'll also have to figure out something with regards to the blends, and that will not be 100% accurate either. But disregarding the acceleration completely would make the estimate too unrealistic after all.
Thanks for you answer! I can see it is not going to be easy - but we will find a way somehow.
/RoboticsMan
Hello
I want to make a tool for simulating robot movements, so that I can get a rough estimate of the cycle times in the cells we build. Using an existing commercial solution is not an option for various reasons. Right now my problem is that I know the maximum joint speeds of various robots, but not their maximum joint accelerations. I need those values. I realize that it depends on load etc, but a worst case number (lowest acceleration) would also be fine. Where to get those values? It's not in the data sheets. I asked one of the big manufacturers, and they won't give me the data. How would you proceed? I need the data for as many robots and brands as possible.
/RoboticsMan
Sendt fra min G8441 med Tapatalk
Thanks! I'll try that!
Sendt fra min G8441 med Tapatalk
Hello!
Lets assume we have the following code:
Now I want to copy the string from STRINGS_1[1] to STRINGS_2[5]. How do I do this? I can't make StrLen(STRINGS_1[1,]) work, so I don't know how long the string is. (In this example I do, but otherwise not). This means that I cant iterate like this:
because I dont know how far to iterate, and trying to copy uninitialized characters will give an error. Also, StrCopy() I also couldn't make work on these two-dimensional arrays.
Any ideas?
Software version is KSS 5.5.10.
Thanks in advance!
/RoboticsMan
Hi
A couple of my colleagues are working on a project where the robot is a Kuka KR10 agilus R900 C (C for ceiling mount), but the robot is mounted in the floor as a normal robot. Will this give us any problems, because the gravity is coming from the "wrong" direction? Could any such problems be solved by loading other machine data, or are there also hardware differences between the floor mounted and ceiling mounted robots? (other than the stickers that are mounted upside down)
Thanks in advance!
/RoboticsMan
Sendt fra min G8441 med Tapatalk