Posts by saberdud

You can go into the RAPID and change the approach robtarget to be at a constant height, so that the robot will only go to that height then place, rather than rising with the bars at it puts them into the box.

I use the 'other' option for PNS/RSR and in detail you can set what program to run.

For anyone that happens to stumble upon this error in the future. We resolved it today with an ABB support tech coming on site. They replaced the safety boards inside the controllers. We had this issue on 2 robots, both IRB660s. Turns out both were bad somehow and a brand new board solved the issue.

I found this a few days ago, it ended up being the fact that the UOPs were not configured to run via the PLC yet. As soon as I power cycled after config-ing them, the labels showed up.

There is also the way I like to use to ensure it was switched. Most of the time I do the process robodec described. I go to the frame screen through the setup menu and use setID (F5) on the screen for the user frames then click the number I want to use. There is a confirmation that is printed out on the bottom of the screen to confirm. If you're looking at the cursor on that screen, it is not affected by which frame is active and could be confusing.

Quote from MR21

Thanks! Which instruction should I use to adjust the parameter?

I'd try to set it equal to a number of second just in an equals line, if that doesn't work, see if the parameter is able to be changed in a program. Sadly, if it's not, then this approach falls flat and you'll need to find another approach.

Whenever I've done something like this were robots are sharing a space, I use bits from a PLC to control permissions to enter the space. The robots wait for permission, rather than holding the program. This makes it restart as soon as the PLC gives permission to move ahead. I assume you could do this without the PLC, just between the two robots.

This has worked really well for us when the application doesn't really involve humans in the zone so the worst that can happen is that the robots hit each other. We also had an alarm if both the robots were in the shared zone, that threw a hold the operator would have to reset. This was our failsafe, and we measured it by looking at J1 angles, because of where the shared zone was in relation to everything else.

You might be able to adjust that parameter from the BG logic based on the IO you have configured in that reference position, then change it back as soon as the robot moves out of that position.

You cannot simply restore the backup into the real robot like you're asking. The MOC file contains the information on each motor calibration offset, and loading the wrong MOC file into a robot can mess you up, especially if you don't have an As Received backup of the robot. Trust me, I've been there. Take a backup of the real robot as soon as you do anything else, this will give you insurance. Then load the module and the EIO file just like AmateurDC said above. That's what my company and I do, and it's worth the extra time to make sure you don't mess something up.

You can go the other way easily, as the virtual controller doesn't really care about the MOC file, or at least it won't ruin the motion of the robot in a virtual setting.

I read the article you posted, and I agree with all of their reasoning for their size of robot. The stepper motors they use pack a lot of punch for their size, but aren't really a good use for industrial sized robots. for larger robots, you want absolutely no backlash, as that puts the weight of the robot on the motors and it introduces a lot more stress. The stepper motors in their robots will not really care about that because the weight of the robot is so low.

You will quite possibly have to change your collision detection sensitivity to make sure it doesn't trip out. Also you should check to make sure your payload is set correctly, you probably already did, but that's my first step.

I'm not super familiar with CRX sensitivity to collisions, but I figured you could use some kind of answer, hopefully this jogs something in your brain about how to go on.

If you're more interested in the mechanical design of a robot, look more at robot manufacturers, integrators don't really do that, you'll be programming a lot more and working with already made robots.

There might be some robot startups or research companies closer to your area to look at, sometimes they can be working on some really cool stuff.

The AMRs that ABB have are VERY early in development. They purchased the company that made them first about a year ago. I would not be surprised if they have the support on robot studio eventually, but I believe this will be very far down the line.

Thank you for the confirmation, it's good to know I didn't miss anything. We have a ticket with ABB, but they're slow to respond and I was wondering if I was alone in this issue or if someone else has seen it.

What are you referring to when you say 'wiped out'? Do the commands from the HMI not work anymore? are you running in Automatic mode to control from the FlexPendant?

I have a new (has had power on for about a week, right out of factory) IRC5 Controller running an IRB660. Yesterday found an issue with temp sensors on drive 1, also throwing overcurrent alarms at times. That turned out to be a loose R1MP plug in the back of the robot. We plugged it in nice and snug and power cycled. Right after the power came on again, we got issue 90819 "Voltage Test Failed". Because the robot has safe move basic, this opens the superior stop and the robot is unable to move.

We have checked all the plugs and harnesses in the robot, and swapped the safety board with another robot we have straight from the factory too. We've also swapped the R1MP cable to see if something was wrong in there, the issue remains. Has anyone seen this before?

You can use the BG logic to raise a flag when the input is on for however long you want, then you can monitor that flag in the main and do the most you want to when you're done with your cycle. Then you won't have to worry about any collisions during the process.

The abort function will end all execution and then you won't be able to run a program without starting a new program, and I don't think you want to mess with changing what program to run or macros or anything like that.

Are you asking about limiting the manual jogging speed of the robot? Or are you asking how to limit the robot speed manually?

What type of robot is that found in? It may help if someone has an old one sitting around but they don't know the boards inside.

A quick eBay search found one pretty easily as well.

If you wanted to get slick with it, you could move a user frame by your offset and use the new, now offset, user frame in your move instructions.

Kind of like the user and object frames in ABB if you have any experience with that.

Your question of user or tool frames depends on what kind of offset you're looking to do, are you offsetting with your tool? Or are you offsetting from something in your cell?