I guess you have implemented a KAREL routine with socket messaging. How many positions do you stream ? is it only one position at a time ?
Posts by Famous_Fella
-
-
I dont leave such decisions on operator personnel. The robot operators only deal with the HMI and the controls I have implemented through the PLC. I dont even let them choose the production program or cycle start. I use recipies that directly store every variable the robot needs, to choose the correct program.
Recipies take care 90% of the decisions. I also use RSR services to start the robots remotely. When the operator loads the desired recipe, the RSR program goes through a switch case logic to decide which production program to start based on the selected recipe. All this does not require any particular experience on robots.
If you check my original post, the Home routine uses a pretty sofisticated branch logic to decide how to go to home based on the cell's current equipment. This way the operator only needs to know how to navigate through the HMI pages and press "HOME" to home the robot. It goes without saying that when you add a new fixture or equipment inside the cell you will also need to modify your background logic to add one more danger zone and your home routine to calculate one more exit move based on the new equipment/fixture added.
Usually, when a customer needs to make additions to a cell they always contact their intergrators. If an employe of a company has the skills to modify a robotic cell by adding new equipment and integrate it to the system (=integrate it to the machine controller/PLC controlling the system) I can assure you he can modify the home routines too, or easilly learn how to do so.
They can add as many processes as they want as the home routine is not subject to the currently running program but only to solid fixtures and equipment inside the cell.
-
No you can't. It monitors the current TCP and this is really the way it SHOULD work. You can change the current TCP by pressing SHIFT+CORD button and selecting a new number near TCP but you really shouldn't. What you should do is make different routines to update the TCP values based on the different programs and tools, and run them each time you run your program. You tie each program to the tool it uses. If you have diferent tools you can create different TCP programs containing only the TCP values saved to specified PRs.
I have 5 different tools each containing different TCP values representing the TOP, Bottom, Center, outer side middle, inner side middle. For every tool, I use a seperate TP program and store each representation of that tool in specified PRs. Now depending the tool each of my production programs use, I bind the correct TCP program call inside the production program. This way I make sure each program will always use the correct TCP values + I encapsulate critical tasks such as TCP values away from the operator.
-
I see one problem with Diag_GRP[1].CUR_TCP. If someone change the tool or frame for whatever reason, it will give false results.
if someone changes the physical TCP (meaning the actual tool currently mounted on the robot) without updating the robot's TCP values or falsely enter wrong TCP values for the currently mounted tool of course it will give false results. But this practice is false by definition.
When you program and commission a robotic application you need to box and encapsulate certain critical tasks like TCP value assignments. Changing a tool is obviously associated with updating the TCP values to reflect the specified tool and those tasks must always be automated in the background and hidden from the operator. -
Gotcha, yes that makes sense. And the nice thing is it will always update and an operator or inexperienced user can't just turn off or on one of the outputs used, so therefore it makes it idiot proof, for lack of a better term.
You can better encapsulate a Home routine by declaring it as a MACRO and binding this macro to an SU key of your teach pendant. (Operator can then use Shift + SU key shortcut to bring the robot home. This is provided you don't use a PLC, which is even easier to bind the Home macro to a DI signal and just create A BIG BIG HMI button reading: "HOME" or "H-O-M-E !!!" or "HOME4DUMMIES"
-
Does $DIAG_GRP[1].$CUR_TCP_X work when robot is jogged? Somewhere else on the forum someone mentioned that it only works in auto.
It always works, but you can copy paste the code to a sample bg program on your own teach pendant and test it for yourself by splitting your screen in double and have one screen switched to Digital Output Monitoring. Jogging the robot must switch the defined DO's on and off when exiting/entering the zones you create.
-
Right, sorry I missed that as I skimmed through. Too bad my current robots have neither DCS nor 4D (it's a very strict budget project...) I can get creative with the basic interference check I twisted their arms to get for the robots possibly or setup all the LPOS boxes...Thanks for the information.
Pay 2 minutes trouble to read my orginal post
You don't need DCS, only a well defined BackGround Logic routine to check your TCP location. Use Diag_GRP[1].CUR_TCP_X, Diag_GRP[1].CUR_TCP_Y, Diag_GRP[1].CUR_TCP_Z system variables. Use your own DOs depending the TCP Location. Create a home routine and use those DO signals to safely exit any danger zone (defined in the BG logic) and return home. BG logic will constantly update those DOs based on its current TCP location. Each time you will call your Home routine, the robot will use some branch logic (IF-ELSE) based on the signal ON from the BG LOGIC to decide the exit strategy and safely return home. You can even use CUR_TCP_W, CUR_TCP_P, CUR_TCP_R which represents your TCP orientation to better define your danger zone. Or you can use Space Function which is a standard function although I find that creating my own Space Function is a lot more reliable than the embedded space function that has a lot of bugs (especially when using continuous turn axis).This is a sample code that defines 3 "hazard zones" for my robot and constantly checks for them.
IF ($DIAG_GRP[1].$CUR_TCP_X<1050) THEN
DO[4:ON :out of space wheelstabl]=ON
ELSE
DO[4:ON :out of space wheelstabl]=OFF
ENDIF
IF ($DIAG_GRP[1].$CUR_TCP_Y<700) THEN
DO[35:ON :out of space bench]=ON
ELSE
DO[35:ON :out of space bench]=OFF
ENDIF
IF ($DIAG_GRP[1].$CUR_TCP_X<(-90) AND $DIAG_GRP[1].$CUR_TCP_Y<(-700)) THEN
DO[3:ON :out of space barrel]=OFF
ELSE
DO[3:ON :out of space barrel]=ON
ENDIF
-
This is good information, but I'm curious about a couple things: I get using DCS Zones to see if robot is here or there, but once you've determined you are inside that DCS zone are you then using LPOS to see where the robot is inside that Zone? How are you determining then where the robot is compared to the programmed position(s) to bring it home? Do you query each point of the program and see how close LPOS is to each point? Saying that out loud to myself sounds silly, so I know I'm missing something very obvious...Thanks for any input you can/may provide. I'd love to replace my lazy use of the breadcrumb trail (i.e. register setting). I definitely have seen where it can fail to do its job.
I have posted a sample R_HOME logic macro that answers your question . Only difference is that instead of DCS I use a BG logic routine to continuesly scan TCP location and activate certain DOs depending the location. You don't need to worry about the programmed positions but only for the current one. Using LPOS to save the current position and Linear move for exit move your TCP orientation will not change so you dont need to worry about crashes when exiting from a tight spot (provided you have programmed a correct exit move).
For the application that this macro takes place there are effectively 3 zones I need to look out for: a Barrel fixture, a feeding table and a double rotary wheel. When robot moves inside one of the 3 zones, BG logic activates the specified DO. If any of the specified DOs are not activated it means that the robot has a safe distance away from any fixture, so a simple JOINT move to P[1:Home] is safe and the robot need not check anything.
-
If you use a Siemens PLC you can use Sharp7 library (which is basically a C# driver for siemens PLCs) together with some DLLs from PCDK and build and embed your own app directly to the PLC's HMI using C#. Sharp7 is really powerfull, coupled with the DLLs from PCDK. It basically bridges the gap between standalone application development (PCDK) and traditional PLC controls. Whatever you imagine can be done on the PLC's HMI. Even custom vision applications built directly into the HMI with duplex communication and controls (robot - vision - plc).
-
This is what I use, it is a MACRO bound to both a DI signal coming from the PLC and a user button as a shortcut.
UTOOL_NUM=1 ;
UFRAME_NUM=0 ;
IF (DO[36:OFF:R_HOME]=OFF) THEN ; //DO36 is the reference home positionIF (DI[20:OFF:Home Robot]=ON) THEN ; //DI20 is the PLC trigger for the robot to go home
OVERRIDE=25%CALL PINZA_AP //release the grippers
//dicision logic to plan the path home
PR[31:Home robot]=LPOS //save current position to a PR
IF (DO[4:OFF:out of space wheelstabl]=OFF) THEN //DO4 is controlled by BGLOGIC
PR[31,1:Home robot]=PR[31,1:Home robot]-500 //if robot is near the wheels table substract 500mm from X current pos
ENDIF
IF (DO[35:ON :out of space bench]=OFF) THEN //DO35 is controlled by BGLOGICPR[31,3:Home robot]=PR[31,3:Home robot]+250 //if robot is near the table increase 250mm from Z current pos
ENDIF
IF (DO[3:ON :out of space barrel]=OFF) THEN //DO3 is controlled by BGLOGIC
PR[31,1:Home robot]=PR[31,1:Home robot]+250 //if robot is near the barrel increase Z by 250 and Y 250
PR[31,2:Home robot]=PR[31,2:Home robot]+250
ENDIF ;
L PR[31:Home robot] 400mm/sec FINE //after calculatins are done move away from fixture with Linear move
JMP LBL[1]ELSE
LBL[1]
J P[1] 100% CNT100
ENDIFENDIF
if the robot is not already at home, and it is not commanded from the PLC to go Home go straight to P[1] without any calculations. If it is commanded from the PLC to go home, drop the total speed to 25%, release the grippers, check where you currently are, safely step away using the calculated PR and after, move to P[1] which is the Home position.
Here is the Background logic.
IF ($DIAG_GRP[1].$CUR_TCP_X<1050) THEN
DO[4:ON :out of space wheelstabl]=ON
ELSE
DO[4:ON :out of space wheelstabl]=OFF
ENDIF
IF ($DIAG_GRP[1].$CUR_TCP_Y<700) THEN
DO[35:ON :out of space bench]=ON
ELSE
DO[35:ON :out of space bench]=OFF
ENDIF
IF ($DIAG_GRP[1].$CUR_TCP_X<(-90) AND $DIAG_GRP[1].$CUR_TCP_Y<(-700)) THEN
DO[3:ON :out of space barrel]=OFF
ELSEDO[3:ON :out of space barrel]=ON
ENDIF
I would refrain from using Registers and Flags just to keep track of the robot's position, I find it really cumbersome and unproductive way of programming, especially when you constantly create new jobs and tasks for your robot. If you save your current position to an LPOS format and your clearence move is Linear, you dont need to worry about crashes provided you have declared some solid and accurate danger zones.
-
Another option that I have found to improve Joint movement speed is the Path Priority mode against Cycle time Priority. In theory it should work the opposite (setting robot to cycle time priority should theoritically produce faster moves) but Path Priority seemed to produce a lot faster JOINT moves.
Check SCR_GROUP use_tbcart nad use_tbjnt system variables. -
Hid my advice and refrain from using the Robot as a client being fed with positional data to move to. Instead use it as a server and feed its positional data as variables accepted by your FTS system to calculate its next movement. The reason behind this has already been mentioned:
1) you don't need to cripple your robot's motion planner and look-ahead functions
2) latency will introduce heavy motion judder, stops, and errors
3) Its a lot easier to rely on the fact that the robot is a machine with great repeatability factors (and not so great accuracy factors). Program a good path, use strict control logic and the programmed path will have an almost perfect repeatability. Then rely on this fact to accurately program your FTS system since there is already a hardware cam implementation which dramatically raises its accuracy.4) It is a lot easier to program a linear system to follow a six-axis system than the opposite.
Always when designing a new system my design approach is as follows:
1) Identify the main parts that will form your machine. (Robot, FTS system, conveyor etc)
2) Brake them into smaller parts or segments. (Robot = robot manipulator+controller+vision system?, FTS system cam sensors controll mode (PC/PLC), Conveyor system (motor inverters maybe, electrovalve actuators).
3) Try to make a list of all your variables. I mean, logical system variables.
4) Try to convert as many variables as possible into constants with your main goal being your system's robustness, integrity, repeatability.
In your project the first thing I would convert to constants, are the facts that your FTS has great built in hardware tools towards accuracy where as your robot has all the tools you need towards repeatability. Those 2 advantages combined together would be my building blocks for a system that relies on syncronized movement.
I would still prefer the Fanuc built-in functions, but by all means I dont want to discourage you. after all evolution comes with trial and error and your project is surely doable. -
The software on our side (FTS) has camming/gearing functionalities, which makes it possible to rectify this inaccuracy over a CamTable ( hermann)
However, the data does indeed need to come in faster to improve synchronization. There is already a connection to FANUC's web server via TCP/IP. Nevertheless, we would like to explore the possibility of master-slave communication using R648: User Socket Msg. The license is on the controller (R30iA Mate). Furthermore, the controller does not contain a KAREL license ( Famous_Fella).
Is there any information I could find on Socket Messaging R648?
in the above link you will find what you need:
http://therobotguyllc.com/downloads/I have not developed nor maintained the above site and I am not connected to the author by any way. This is the manual you need and I found it using google service for the sole purpose of not giving you the manual myself as it is forbiden by fanuc. Chapter 11 goes in debth about Socket Messaging and how to use it.
Here you can also check an implementation with Karel Socket messaging and a vision application. There is also Karel code you can study Socket messaging implementation between a vision system and a Fanuc robot.
https://docs.pickit3d.com/en/2…grations/fanuc/index.html
Good luck!
-
Your best bet would be using KAREL Socket Messaging function to send and recieve positional data to and from the robot with .csv file manipulation but
you will never succeed at fully syncronizing the robot with the carrier. You could spend hours of testing and fine-tuning how many positions to send and stream and when (based on the calculated latency of the network you made between the robot the controller and the carrier) and come to a solution where you have almost syncronized them only to realize that a small flood in network traffic between the two, a sudden crash on the PC handling the streaming, a sudden change in its RAM available capacity will desync them. There is a reason why PCs are not used (or shouldn't be used) in production environments, they are unstable, they crash, they overload their RAM they do things in the background that we dont want them to do.
You could also use ROS-Industrial framework since you are adept with python but keep in mind that by streaming positional data to the robot, you effectively cripple big time the robot's motion planner which is a pretty sofisticated piece of software. In fact this is where the big money goes when buying a robot. you should expect occasional jerks and judders, missed positions (due to latency) from time to time although not really often, but imo all those solutions are what I call "Leeroy Jenkins" projects, they rarely comply with the basic safety standards a robotic application must meet when installed in a production environment.
I would stick with the FANUC solution. -
I can't think of a reason why to put a production robot actually producing, in step mode during auto instead of just pressing hold but this is propably the variable you need to check: $RSMPRG_SV.$no_step.
When in AUTO mode check the status of this variable. Check any KAREL routines or BG LOGIC that mess around with this variable.Also check $SSR STRUCTURE and specificaly $SSR.$singlestep.
-
in a PR the first 6 data are X, Y, Z, w, p, r the 7th data is the position config which is not directly accessible with TP language, nor by inderect addressing (PR[2,7] = [PR1,7]) but only with the use of Karel routine which doesn't really worth the effort. The best way is to make a point in the config you want and copy it in the PR before loading each of the 6 values of positions (XYZwpr).
-
try the teach on/off switch on the pendant. Does the led "Teach Pendant On" on the controller's operator panel activate ? When I had the same problem on some RJ2 controllers, it was due to bad teach pendant cable connector at the teach pendant's end. Try and hold the cable connector at the bottom of the teach pendant hard and firm, reboot the system and check if this solves your problem. I stopped buying cables some years now. I am using teflon tape around the cable connector to make it hold firm inside the teach pendant connector
-
By your post I understand that this happens during Linear moves, what about Joint moves at full speed? Do they produce the same error? And also one more question, does this move, the linear one, include a violent orientation change of your TCP ? It is very important to use degrees/sec instead of mm/sec during a linear move that involves an orientation change of the TCP
-
So many ways invented to spy on a robot's usage. Can't you guys just.... ask?
-
There is another way without purchasing HMI Device option.
You can use explicit messaging and extract everything you need concerning Alarms.
1 Alarm ID The Alarm ID, or Alarm Code.
2 Alarm Number The Alarm Number
3 Alarm ID Cause Code The Cause Code of the Alarm ID.
4 Alarm Num Cause Code The Cause Code of the Alarm Number.
5 Alarm Severity The Alarm Severity.
6 Time Stamp The Alarm Time Stamp in 32-bit
MS-DOS format.
7 Date/Time String The Alarm Time Stamp in a human
readable string.
8 Alarm Message The Alarm Message in a human
readable string.
9 Cause Code Message The Alarm Cause Code Message in a
human readable string.
This is provided you are using Ethernet IP communication protocol between PLC and robot. Explicit messaging itself is very easy to syntax and use but you must be a bit carefull as it is a broadcast packet. If you overdo it you can easilly flood the LAN of your machine.