Posts by saberdud

    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.

    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.

    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?

    I think SRS is a few years behind robot studio but still a very strong software for development. The newer version has a much better tp interface in my opinion where you can actually use a virtual TP like in Fanuc Roboguide. The simulations also look very good, on par with ABB and better than Fanuc. Galet said this new version of SRS changed to DirectX, and I can defiantly tell a difference in rendering time as well as just moving around.

    If you use Staubli a lot, or even just consistently, I recommend the new version for the extra troubleshooting capabilities you have offline just off a backup.

    Adjust the Enter/Exit values for the work area that it is tracking the conveyor in. Also the timing of the pick could be shortened to alleviate the timing challenge. The robot only looks at where the item is when it starts tracking and if it takes too long to pick it, the robot can track out of it's reach, then you have an issue.

    The YuMi defines the configuration a different way than the 6 axis robots do. That is the "using old target def" error, saying you're not using the right format for the 7th axis robot. What I do is add a robtarget from the flexpendant and modify the position from there, rather than defining it in Robot Studio. If the arm is in the right position when you do that, it should work with no issues, the robot figures out the configuration by how the arm is positioned when you touch modify position.

Advertising from our partners