You can change it by minimizing the HMI and changing the host name on the windows side.
Startup->Service->Minimize HMI
Then going to Control Panel -> System
You then get the option to change the settings under Computer name
Posts by BOTTECH
-
-
Easiest thing to quickly check is to reference this graphic. You can check your MCC from your robot order
-
-
If you already have your program selected you can just map your start button directly to $EXT_START, done in KRC\STEU\MADA\$machine.dat. That will then start the program if you are in EXT and the safety system of the cell is up with no faults present.
Of course with that you will need the drives to be enabled so you can always set some conditions around enabling them using $DRIVES_ENABLE and write to that in the SPS without issue.
If you don't have the program already selected then you will need to look at using CWRITE but what I take from your message I don't believe that is what you need for the application since you just want to start the program and you already have a physical button connected to the robot.
-
Hi All,
I have had quite a substantial problem on many of my robots regarding oil leaks throughout my career so far and I wanted to see if this issue is as prominent for others on this forum as it is for me and I am interested to find out from all units across the industry.
If so has it been a common occurrence? How has the support been for you from the robot manufacturer?
Have they solved the actual problem or just kicked it down the road? How demanding was the application you had the robot in?
Did you need to step in and provide your own fix e.g. pressure release etc?
I understand that they are mechanical systems and oil leaks are not something that can necessarily be 100% prevented in all applications but I am interested to see how certain brands weigh up against each other in that regard.
-
Thanks Schnautz for the highly in depth reply. I recognize some of the issues you mentioned above also from other people that have been involved with the platform.
Would you mind elaborating a bit more for me on how the platform is not safe?
-
We bought a MiR for a customer last year, and I spent some time integrating it. I also met another engineer that integrated one in his plant.
Before I spill all my thoughts out in the open, has anyone else had experience with these?
Any thoughts to still share on this Schnautz? I know that MiR have performed a firmware update on some of their systems that is meant to have solved quite a few issues that they were having previously but I would be interested to hear the status first hand from an integrator on their current state
-
In Windows,Open “C:\KUKA\REGISTRY\KukaUserSettings.reg” Reset KRC with reload file
Thanks Styx, I'll check it out when I get back at the robot in question
-
screenshot?
I don't have one I'm afraid. The only difference is that it is the standard scrollbar but at about 2mm thickness.
in general or just on a few pages?
Its across all pages
-
Hi All,
KRC4 KSS 8.6.5
Anyone know the controlling file for the scroll bar width on the pendant?
Scroll bar is really narrow on some of my robots and it is bugging me because I can't move it accurately with my sausage fingers.
I have done a compare with a correct pendant configuration and can't seem to find anything and don't have a robot in front of me right now to test various changes.
Thanks
-
You can use any available 3D modelling package. Solidworks is probably the most common and what we use for designing EOAT's as standard but there is also AutoDesk inventor and Creo. It all depends on your price range and what your experience is, some are more focused toward experienced designers where others are better suited to beginners. If it is just for broadening your own experience I would start with one of the free options
-
There is typically only one processor in a CS controller so it can only run one task at a time so can't do asynchronous but since it can do synchronous tasks with a very low cycle time it can be estimated to perform the same function over a longer period.
What I have done in the past for a situation like this is to create a form of Background task that is created on startup before the other application programs with the highest priority of all of the tasks. Then have that control the specific IO you want to monitor or information that you want to monitor and use FLAG based communication between the other programs in the application and this "Background task".
You shouldn't run into issues then unless the time requirement of the data you need to monitor is sub 10ms
-
I have no clue what the part # is for the cable I need, that was the whole point of the initial question.
1. Call Fanuc and explain what you have, you won't need to re licence or do anything, just give someone a call in service or support
2. Get them to give you the part number for the cable you need
3. Go and search ebay or wherever for that part number
4. You will have the correct part number faster than it would take you to reply to this post
Otherwise,
1. Take some pictures of the connectors you have either end, sensor end and robot end or give a description of the connection points like mentioned above by Skooter and Fabian Munoz
-
Still call them and they will tell you the part number for what you need, if you didn't get documentation that you can check like diey recommended then you will need to get documentation off them anyway.
-
If you bought the robot from Fanuc then call them and they should get you the correct cable, if not then at least the correct part number. Simplest option for you to get the issue resolved
-
Hi All,
R-30iB Mate controller V8.30P/54
I ran into an issue here lately where there was a failure of what I believe to be the FROM/SRAM on a mate controller (needs to still be confirmed on swap out).
Does anyone know what could lead to the possible failure, the robot had new IO mapped for the purposes of testing and then got reflashed with its original image and after that then bricked, not able to go any further than the boot screen without getting stuck, checking parity and everything seemed to still be fine but I can't imagine it being a different component. The robot had been flashed many times throughout its lifetime and I couldn't imagine it would cause a problem. So I am curious to find the actual cause and if it was the reflash then what could have happened during the process to cause a component failure especially since it was the original working image, pulled into another robot also and the image was fine. Anyone have any insight into a possible cause?
Thanks
-
Is the robot already connected to the automation and you want to add more signals or are you looking to interface for the first time?
Your best bet is to get copies of the electrical drawings for the robot and the automation and take a look at the IO interface on each. If there is no hardwired IO available you need to make sure that the systems will use the same communication protocol e.g. Ethernet/IP, Profinet, Ethercat otherwise you will need to add in a gateway
-
Did you look at the video in the link that I sent you? it has everything that you need and even has the files to download to do it
-
Check out the manuals and tools section of the forum and get an "Operating and programming integrators manual" and have a read, should give you more than enough to get started. You should have also got a usb with a set of documents with the robot. These manuals will be linked to the KSS version of the robot controller which is the "Kuka System Software", you can check which version your robot is currently running by going to the robot pendant and going to the "Help -> Info" screen so make sure you get the corresponding manual.
It will of course be useful to have some sample KRL (Kuka robot language) programs to look at also while going through the manual so do a search on the forum for some. There is already a wealth of code samples and snippets here that you could reference.
-
So you now have an inverse kinematics solver for your robot but the trajectory planning depends on how you want to do it because it can be as complicated or as simple as you want to make it, it just depends on what you are trying to achieve.
You could define a path in point space and then use your IK solver to get the joint angles at that target point and then compute the difference between your current position and your target location on the path, then step through the robot joint angles until you reach that point, putting certain constraints around them so you define the direction the axis is to move +/- and so you don't have two axis' come into contact with each other or don't rotate past the limits of the simulated motors.
With a multi DoF robot you will also have the possibility of reaching a point in various different ways so you will need to consider adding in parameters to define the way in which you want the robot to reach the point e.g. imagine reaching your hand out to grab something on your desk, you could reach the object with your elbow facing toward the ceiling but could also reach it with your elbow facing the floor.
Then to add further to that you can then dive into optimization techniques on how to optimize your path planning based on specific parameters.
Check out this video and it will help you: