Posts by BOTTECH

    NTE84-11 its hard to give you a good answer to that question because it solely depends on your part and or parts. In summary if you have a good surface and enough suction you shouldn't have a problem with vacuum but there are quite a few factors to consider to ensure it actually fits. I actually always try to replace grippers with vacuum if its possible for many applications.

    You will need to do an evaluation on your parts an test various cups to see what fits best i.e. shape, material, bellows. And test on the bench with a set of vacuum generators and parts to make sure that the application works first. Also since its in a mill you will likely have swarf around the machined part so this can easily damage or block a cup depending on the size so put some consideration in to when to engage the vacuum and if you need some screening behind the cup, you could also use a blow off function to first blow the area clear if you have decent pressure and volume and then engage vacuum. Make sure that your air supply is good and also consider if you need to put some compensation in the tool as you may need to press on the part slightly if you don't allow for any compensation in the cups themselves.

    You can use the clock speed to record in milliseconds, just take the value after the decimal point or you can convert directly to milliseconds if you do a conversion in the code. So if your move only takes milliseconds your timer variable looking at the clock will return 0.500 seconds and you can multiply by 1000 to output your result in ms. Your resolution is in 1ms increments

    Your velocity value will be defined in the descriptor of the move you want to do, mdesc. In that datatype you will have acceleration values, decelerating values, velocity etc and the robot will be moving at the maximum capacity of those constraints so if you set it to 100% it will try move at 100%.

    getSpeed will return you the translation speed of the tool but this is only calculated based on the velocity commands of the move so will be based on what values you have in the mdesc for that move.

    It just takes your current tool as an argument and returns a num value so:

    toolCartSpeed = getSpeed(tGripper)


    toolCartSpeed is defined as a num datatype

    tGripper is defined as a tool datatype

    Hi Rahulsajeev0909,
    Yes you can get the monitor speed of the robot by using the function getMonitorSpeed() and also set the speed by using the setMonitorSpeed() function.
    For the speed monitoring of the move instruction you can use the internal clock to start a timer before the move and then stop it after the move has completed by using waitEndMove() after the move instruction. For Example:

    MoveTimer = clock()
    Movej(Pick, tTool1, mPick)
    MoveTimer = (clock()-MoveTimer)

    Shouldn't be a problem, I have the same myself but I just have the inputs first in the bus normally.
    Do you have the topology reconfigured for the additional cards? Double click on SYS-X44 in the project structure and it will bring you to the menu.
    If not then there are rivets on the backplane that if the card is on one of the rivets it will not make proper contact, it looks like it is but it not making full contact and you will need to either move the cards or drill out the backplane.
    Otherwise there are 2A and 0.5A versions of the Ek1100 and some of the output cards, make sure that you have the correct version in the topology.

    First read this and provide some information on the system: Read First

    You can reverse the program while manually jogging but if you want to do this programmatically then it depends what you want to do, if you just want to run a direct reverse of the sequence then write another program with the sequence inverted and call that as needed but unless its just a simple move to end of sequence and then invert the sequence then you need to be able to take account of other factors such if you want to include recovery in this if the robot stops mid path/sequence.

    If its in relation to homing the robot then there have been quite a few homing discussions on the forum already so I would recommend searching for those.

    I want to know if it is possible, I was referred to robot forums by a dear friend

    Everything is possible, its just a case of whether we have figured out a way to get there or not.

    Even though technology is moving forward, humanity seems to digress. I was not teaching I was asking, calling my question technobabble sounds like you're familiar with a virus.

    And I agree with hermann and Nation here. From the way you are posing your questions it sounds like you have just grabbed some technical words and put them together in a sentence expecting us to draw some meaning from that. Everybody is happy to help on this forum but we are not here to try and draw the question out of you. I would recommend if you want further input to have a more detailed problem statement in what you are trying to do i.e. what is your end goal and what direction you want to go to get there in some more detail.

    Or if you want to have a philosophical conversation on the topic then post the question in that way.

    Also if multiple independent people are saying the same thing about the way you have posted something I wouldn't recommend getting defensive and going on the attack

    Yes of course. You could design a robot to operate in any way, with any language or input you could possibly want. Strings, numeric characters, binary, images, sounds, physical movement, anything at all. But you need to write a way for these inputs to be translated to electrical signals to drive the motors to the desired position.

    You need to provide some more information because from what you have posted we have no idea what you are looking at trying to do other than maybe use STM32F407.
    Are you just trying to model the robot? And if you are then what type of robot? 6 axis industrial arm, 3 axis gantry, mobile robot etc?

    Is it a fully custom robot? Then what are the defined motion ranges you are looking for it to have? Are you planning on direct drive or using gearboxes?

    Are you looking to end up with a static or dynamic model?
    Are you going to try and eventually make the robot, is that why you are looking at hardware already?

    These are just a few of the many questions.

    If you can give some more context then we should be able to help you out. But as a starting point I would recommend getting answers to the above questions and defining the requirements of what you are trying to achieve and doing a search online as there are already a lot of resources out there that walk you down through creating a mathematical model of a robot from the simplest approach to the most complex.

    Mathworks will have a lot of information that will be available to you and there will also be many academic papers online that you can reach to get a handle on some of the equations, matrices, transformations etc you will need to use.
    I think that would be your best place to start, for example below is a link to an example on Mathworks:…industrial-robot-arm.html

    And a quick google of "Mathematical model of an X Robot" where X represents the type of robot you are looking to model will give you a myriad of resources that will provide you with information.

    Then you know its a problem with the new project you have created.
    Do a compare between the functioning project and the new one you created, especially with the stationsetup and see where your differences are and it will point you in the direction of your error.

    Do you have an archive from the controller or an image of the controller available to restore from before the problem happened?
    Also do you have the batteries connected on the robot? These will function as a UPS for the robot in the event of a temp power outage.

    Rateup its likely that since your robot was straight out of the box that the batteries were either not connected because they are disconnected during shipping or that they were not charged so they would not have been there to act as a buffer and the robot would have been killed directly, thus having a negative effect.
    It has happened on a system I looked at before that there was an unexpected power outage on a robot that did not have the batteries connected and that actually ended up causing a hard drive failure.

    So there are multiple outcomes that can happen, 90% of the time it will just be that the robot is fine or needs a restore.
    What was the solution that Kuka gave you because since it already happened then you may be able to provide an answer for danmoran

    The robot runtime is stored in the variable $ROBRUNTIME i.e. the same as viewing the run time hours on the info screen on the pendant. I don't believe that you have access to this variable in a standard archive unless you have copied it to a different variable in your code so for your situation it may be best to just look at the logs and work out the time between but depends on your situation because if the robot was operated in a start and stop manner then this will be tedious.

    mtcooler is there a reason to delete the jobs i.e. that those parts are no longer running? Just that if you are unfamiliar with the code and don't want to get into it but you are familiar with teaching the points the best thing for you to do may be to just teach all the points in the jobs that you don't want anymore as the same point and have them clear and away from any obstacle, that way they won't actually run the process and will be clear of any collision. Then if you want to move forward and edit the code either start to get familiar yourself in the meantime or send to someone to modify for you

    I would recommend re activating the base project so you don't have any of the custom project configuration specifics and then then going from there. Then it looks like you are looking for the motion enable. Look for $MOVE_ENABLE and see what this is linked to. You can map this to always on $IN[1025] to remove the need for having a physical connection for now.

    Did you upgrade the Ram in the PC? I believe that the star* specifies a minimum of 3GB of Ram required for the MCC-10

    But here is like noted that i could use MCC-10 PC from KSS8.2(I cannot read what is written under star*) for KSS 8.5. In my case I got BSOD when trying to run image with KSS 8.5.6 on MCC-10 while image with KSS 8.3.14 did run, but any later version of KSS 8.3 again with BSOD screen.

    MCC-10 PC with KSS 8.2 didn't even had graphics port on motherboard.

    And i also got email from KUKA that i have to use MCC-30 in order to run KSS 8.5.6.

    Yes I thought the same, very handy graphic. I have it in my own notes but don't remember exactly where I got it from, I think it was a screengrab from a webinar because I haven't seen it in any documentation yet.

    this is useful, i saw it at German forum but not in documentation. maybe it is part of newer electrical servicing manual...

    Dzonzi I would recommend changing the title back to what you had it. The purpose of the forum is to discuss topics and aid people in similar circumstances so this thread may be useful to someone else in the future if they have the same problem