Posts by saberdud

    When the conveyor moves, do you see blinking lights change on the DSQ board? The changing lights mean that the board is reading the changes from the encoder. If not, look at wiring before programming.


    Next, see if the counts are changing in the ICI section of the controller in robotstudio. This changing means the controller is seeing the counts from the board. If not, look to make sure your board is configured correctly.


    Finally, check your counts per meter, if they aren't set up, there will be a 0 in there, which results in a 0mm change in position for every count of the encoder, which could result in the issue you're seeing.

    ¿Tiene una herramienta gráfica en la estación? ¿O estás pidiendo ver dónde está el TCP?


    Si tiene una herramienta gráfica, asegúrese de que esté configurada como visible en el panel lateral de la izquierda.


    Si solo está buscando el cono TCP, asegúrese de que la herramienta esté seleccionada; de lo contrario, activará la Tool0, que no muestra nada.


    Perdón por los errores gramaticales, esto está traducido.

    Rhenius is right, that will show the DCS. However, not every robot has the option on it, that could be a reason you would have a hard time seeing it. You can check the installed options to see if that robot has it installed.

    You can probably use the offset after the movement to the new area, as long as all your frames are set up right. The kicker is how you're moving the parts, if that isn't accurate, or if the parts shift at all, you're going to have a hard time picking them accurately.

    I would recommend downloading the iRvision manual, it helps a lot to know the commands and how they interact. The Get_Offset gets the offset information from the vision routine and applies it to a vision register than can be used to move the robot with. Hope this helps!

    The location the item is imported into is dependent on the origin of the part when it was designed. Like pdl said, you can offset it to make it line up. If you can, you can look into where the origin is and do some measuring to align it more than your eyes can in a simulation.

    In order to do a B-Start (Robotware 5 language, in Robotware 6 language it's call "Revert to last auto saved"), go to the restart menu from the top left menu. Then press Revert to last auto saved and then "Next". Follow any directions that come up and the robot will reboot.

    You could also find some success looking into tech schools in the area. I know in my area, the local tech school has courses on ABB robots and has hands on labs. They could have an opportunity for training in specialty cases too.

    And to add onto this, you can't do this in BG logic as PRs aren't able to be used. The program must be a motion program to do so, so you must CALL it, not RUN it. You can add it to any program that's run every cycle or periodically.


    Be careful moving Uframes when running, if something changes too much you can end up swinging wildly due to a fat finger input.

    To add on to Lemster, that is what's stopping you from jogging, the rev counters error comes from a system wipe or a battery dying, like you said. Not a big deal to fix those, but if you're expecting the tool to jog straight down after the system failure it gone, it might surprise you that you can't.

    You might be able to look into tying the controller parameters to your smart components, that might be the way you're going with simulation this in depth. You should be able to set an analog signal to the distance of a linear motor if I remember right.

    I've swapped flexpendants around pretty much randomly and have never had an issue with Robotware versions. The flexpendant isn't running the robotware so it shouldn't have any issue. Kind of like plugging in a different keyboard to a PC. The operating system of the PC doesn't really make a difference.

    So that change that you made is very close. You changed it to always approach the same amount (110mm), rather than the PM set value.


    I would make a change to set the height to a constant value, something like changing the trans.z value to the workobject uframe Z value plus a certain height that you want. That way you're not working on an offset, and always going to the same height before going to your place.


    Hopefully that helps!

    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.

    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.

Advertising from our partners