Best Of
Re: Smart Components Idiots guide?
"Is there an idiots guide with full explanations throughout the process of creating Smart components availalbe... "
I guess not then ?
sturner
1
Re: Network Scan Time Out
I still believe its an Microsoft Problem and not robot studio
Will see if find an solution
Update: after Uninstall Microsoft updates, to a point I remembered RobotStudio worked. Repair Install of RobotStudio it works Again.
Will see if find an solution
Update: after Uninstall Microsoft updates, to a point I remembered RobotStudio worked. Repair Install of RobotStudio it works Again.
PeterPan
1
Re: Modify curve also displace curve
I tried with RS2025 and RS2024 and get the same situation as you do. I'm not sure if this is a bug for RS or not.
Anyway, I found an walkaround for this issue. For the line created, I modify its local origin to the starting point of the line and then do the extension operation. In this way, the curve does not move to another place afterward.
Anyway, I found an walkaround for this issue. For the line created, I modify its local origin to the starting point of the line and then do the extension operation. In this way, the curve does not move to another place afterward.
Re: Rapid Encoder
Does anybody have the Encryption software ( encode) that works on W11 and IRC5
abbGuy
1
Best Practice for Top Level of robot program
In my past robot projects on other platforms, especially if working with PLC control, I create a main loop, and a command processor within that loop. A handshaking protocol is created for each application, but often looks nearly identical. A command is given by the PLC in the form of a number on the robot side, and an 'execute' bit triggers the initiation of the command.
At that point, the robot is often starting a process of many steps, but to simplify control and recovery, the PLC is usually commanding discrete steps individually. This is more efficient when both 'picks' and 'places' can be from different sources and to different destinations.
Other processes may require the robot to complete the entire cycle from one given command, and this can be more complicated for the robot program to recover and continue after an interruption.
With RAPID, I find that I have more options in how I can approach this.
What are the best ways to handle this kind of control in RAPID?
My experience is leading me toward this solution:
* A main loop command processor that waits for a PLC command.
(The PLC has the knowledge of what is currently in the robot cell. The command contains this information, in my case.)
* Once the command is given, the robot has the task of fully completing it, or recovering from an interruption, and completing it, unless and until a cancel is given.
* So, in a multi-step process, the process State must be tracked, and if an interruption occurs, the robot must resume from the last known state and successfully complete the original task before finally handshaking with the PLC to indicate that it is complete.
Q: What is or are some best practices for cleanly handling this state tracking, and then resuming at the correct state after an interruption, in RAPID?
(I have experience with a simpler robot system that is a good deal more primitive than RAPID, and with Structured Text in a PLC that is closer to full-on real-time, multi-tasking Object Oriented Programming. Since RAPID falls into the middle between these two, I'd like to make sure I am making the best use of RAPID's capabilities.
I DO have the Multi-tasking option on my robot, but I know it isn't nearly as powerful as having a PLC.)
My current approach would be to always restart at the top of Main, and start at a 'command' processor, waiting for a PLC command. Then, if a command task was already in progress, skip that and go to a State processor, which would redirect the pointer to the next sub-task that had not yet been completed. For example, it might start up and go back to pick or 're-pick' the third thing in a process, and finish the final step, before signalling to the PLC that it's current command is complete.
My current state tracking is to create constants for each state, and then update the state at each point that I need to. If resuming from the top, the 'state processor' looks at the state variable to know what was last fully completed, and then jumps to the thing that it needs to do next.
Thanks,
At that point, the robot is often starting a process of many steps, but to simplify control and recovery, the PLC is usually commanding discrete steps individually. This is more efficient when both 'picks' and 'places' can be from different sources and to different destinations.
Other processes may require the robot to complete the entire cycle from one given command, and this can be more complicated for the robot program to recover and continue after an interruption.
With RAPID, I find that I have more options in how I can approach this.
What are the best ways to handle this kind of control in RAPID?
My experience is leading me toward this solution:
* A main loop command processor that waits for a PLC command.
(The PLC has the knowledge of what is currently in the robot cell. The command contains this information, in my case.)
* Once the command is given, the robot has the task of fully completing it, or recovering from an interruption, and completing it, unless and until a cancel is given.
* So, in a multi-step process, the process State must be tracked, and if an interruption occurs, the robot must resume from the last known state and successfully complete the original task before finally handshaking with the PLC to indicate that it is complete.
Q: What is or are some best practices for cleanly handling this state tracking, and then resuming at the correct state after an interruption, in RAPID?
(I have experience with a simpler robot system that is a good deal more primitive than RAPID, and with Structured Text in a PLC that is closer to full-on real-time, multi-tasking Object Oriented Programming. Since RAPID falls into the middle between these two, I'd like to make sure I am making the best use of RAPID's capabilities.
I DO have the Multi-tasking option on my robot, but I know it isn't nearly as powerful as having a PLC.)
My current approach would be to always restart at the top of Main, and start at a 'command' processor, waiting for a PLC command. Then, if a command task was already in progress, skip that and go to a State processor, which would redirect the pointer to the next sub-task that had not yet been completed. For example, it might start up and go back to pick or 're-pick' the third thing in a process, and finish the final step, before signalling to the PLC that it's current command is complete.
My current state tracking is to create constants for each state, and then update the state at each point that I need to. If resuming from the top, the 'state processor' looks at the state variable to know what was last fully completed, and then jumps to the thing that it needs to do next.
Thanks,
Re: How to run buttons in auto mode??
Hello Jerry,
I think you must be using RunRoutine Button control. By default this control would work only in Manual Mode. If the button is required to run in Auto then there is a property in the control called "AllowInAuto". Set this to TRUE and redeploy your application on FlexPendant.
Thanks
Abhishek
Re: How can I call a userfunction onClick with a button?
Hi Yvok,
I have now also created a new project and it does indeed work now. Is there a way to convert the old project to a new project so that the userfunctions now work?
Jur148
1
Re: Pack&Go file not letting me make changes to the RAPID code?
Have you tried to use 'Apply - Apply changes' or 'Apply - Apply all' button under 'RAPID' ribbon?
I think there is only a 'save' button to save the entire RS project, but not a 'save' button for saving RAPID change. I will have a popped up window to select a location when using 'Ctrl+S', yet to save RAPID I use 'Ctrl+Shift+S', which is the hot key for 'Apply all'.
I think there is only a 'save' button to save the entire RS project, but not a 'save' button for saving RAPID change. I will have a popped up window to select a location when using 'Ctrl+S', yet to save RAPID I use 'Ctrl+Shift+S', which is the hot key for 'Apply all'.
Omnicore V250XT A_AutoStop Situation
Hello everyone.
I recently purchased 3 new identical robots 6700 swVersion="3.02.03" RW_Version="7.18.00", Controller=V250XT;
I have a problem related to Safety.
I use Siemens Failsafe PLC as master (Profinet/Profisafe) and the robot is a device.
For the safety part, considering that I use Profisafe and not Hardwire, I chose to connect the X14 signals exactly according to the manual to bypass that part.
I mention that in the SafeMove part, the robot was synchronized, the configuration validated and locked, because I use safemove pro and I have many safety zones and only I have exclusive access to modify that part.
For the safety part, considering that I use Profisafe and not Hardwire, I chose to connect the X14 signals exactly according to the manual to bypass that part.
I mention that in the SafeMove part, the robot was synchronized, the configuration validated and locked, because I use safemove pro and I have many safety zones and only I have exclusive access to modify that part.
There are a few signals that are default in SafeMove without the possibility of deleting them, which I can only change the category (0 or 1) stop:
1. A_AutoStop
2.ES_ExternalEmergencyStop
3.G_GeneralStop
4.TPU_EmergencyStop
My problem is related to A_AutoStop. The straps are made correctly, I read all the documentation, I even asked the local ABB technical support (What's more, I sent a backup and they replied that the configuration was done correctly) and no one can help me to make that signal true.
Is there something else to configure?
In the documentation there is a reference that specifies that you can choose what the AS/GS inputs do but nothing concrete.
Thank you very much!
The last solution given by the local technician from ABB was to update RW to 7.18.1, but I refuse to believe that this is the problem, considering that there are 3 new robots. I don't think that this is necessary.
I think it is a stupid thing like the bridge with the cut pins for A_AutoStop was on IRC 5 (for ABB to demonstrate that the new robots have not been used in auto mode before).
I think it is a stupid thing like the bridge with the cut pins for A_AutoStop was on IRC 5 (for ABB to demonstrate that the new robots have not been used in auto mode before).
I mention that I have a bunch of ABB robots installed on the active but IRC 5 and even one S4C+, but I have already lost a day with this problem and I don't know how to solve it.
Thank you very much!
