Basically, you set up a group input from the PLC to the robot in which you send the values for the corresponding program to run. It is a good practice to echo the number back to the PLC so you need a group output from the robot to the PLC. If the numbers match, then the PLC should send a start signal to the robot.
hi
Whats the group output?
I guess you know PLCs " I change the program on the PLC"
A group of outputs/inputs is very similar to a word in PLC language
You grouped together a bunch of I/O and you call it GO or GI
Also what values are to be sent to the robot?
At the moment, are you using the PLC to send I/O to the robots ? Group I/O are the same principle, you just use a word to read them
Search the ABB forum for EIO and Group
Example:
nProgramNumber:=giProgNum;
Test nProgramNumber
CASE 1:
rProgram1;
CASE 2:
rProgram2;
and so on....
DEFAULT:
!Good to have in case something unanticipated happens
Stop;
ENDTEST
Not quite...
A Group Input is a collection / group (hence the name) of digital inputs read as a Binary input.
For example, a group of eight inputs would allow you to set a value (i.e. call a program) between 0-255
You only need to assign as many as you need to call programs for...
4 outputs would give you 15 programs, 5 = 31 etc.
For example, a group of eight inputs would allow you to set a value (i.e. call a program) between 0-255
Depending on how many options you need, you can create a smaller group - 4 inputs would give you 16 options (though I don't usually use "0"), a 5-bit group would yield 32 options.
@SAABoholic,
I seem to be about half a post behind you today...
Just designate a Group of inputs then use this value to call you program
reg1 := GInput(gi1)
then
CallbyVar "proc", reg1;
need to name your routines proc1, proc2, etc
or
TEST reg1
CASE 1:
procedure_a;
CASE 2:
another_process;
CASE 1:
last_c;
DEFAULT:
EXIT;
ENDTEST
In this case routines CAN have different names
or
%"proc"+NumToStr(reg1,0)% ;
same as the first case, routines should be name proc1, proc2, etc
I wont need that many only need 5 or 6 options max
3 outputs / inputs would give you 7 combinations / programs.
2 outputs would only give you 3
The case-statement-style software method (using EtherNet/IP in/out of the robot) was how I do it with Fanuc, too.
(After a command number is echoed back, then a start bit activates that 'command' or program.)
What about getting the robot running from a PLC-connection? With Fanuc, I can have the PLC reset and start via EtherNet/IP bits.
After EStops are enabled, can the EtherNet/IP connection between my PLC and IRC5 controller clear, reset and get the main program running? (Or is the 'command processor' set up to run automatically in a multitasking system?)
Thanks,
If the robot runchain is ok and the robot is not faulted, then you can send the system input for motors on. When the robot sends the system output that the motors are on, then you can send the system input to start the program. Some use startatmain, but I don't like that, it can create a lot of problems, especially crash problems which would have to be dealt with in a recovery routine. A multitasking system typically will have background tasks which are either semi-static or static. They will run all the time, you don't have to start them. If you configure a background task as normal, however, and it will start when the start command is given.
Thanks for the replies.
Being from Fanuc World, I am guessing that the "run chain ok" is "all safety devices on all circuits are closed, enabled, etc?" I did multiple searches in IRC5 manuals and found no definition of "run chain," but that is what I infer from how the phrase is used.
I currently have a PLC connected to my IRC5 controller via EtherNet/IP, and so I can configure any one of these system I/O to my EIP bits?
In my case, I can have Main be mostly a looping case statement waiting for a command number and run bit from the PLC (with echo back of command number to the PLC to acknowledge before running). So if the robot is commanded to run the Main program from the beginning, nothing happens until the robot is also commanded to run a specific process (a program called from the case-statement, initiated by the separate PLC process once it knows the robot is running and ready).
But the one 'gotcha' I see from your description and my experience is the "robot is not faulted." In Fanuc, I don't have a "must acknowledge" fault from an EStop or Gate Open event. Yes, it stops the robot. But then the PLC can reset and restart over EtherNet/IP without having to reset or manually acknowledge anything on the pendant. So, in a basic scenario of running the system, performing a process, the robot returns to waiting for a new process command, the operator opens the cell gate, stopping the robot via the safety inputs, resets up the work-piece, exits the cell, returning the run chain (?) to 'ok,' and then he can hit a button on the HMI to reset the robot, and another one or more buttons to run robot Main, and initiate a process on the new work-piece.
In my experience with ABB, opening the gate creates a fault that requires the operator to also have to perform an acknowledge on the Flex pendant prior to being able to run. Any way around that, or do I have to live with that. Or am I wrong on one or more of these points? Also, I have multitasking, so if an always-running task helps in this application, let me know.
Thanks,
When an operator opens the gate and opens the auto stop circuit, there will be a message written to the teach pendant stating such. It is not really a fault, it is doing what it is supposed to do. The operator can acknowledge it or not. As soon as the circuit is closed again, it will have Run chain ok despite not acknowledging the message. Only the e-stop requires a reset, all others are good once the circuit is complete again.
Thanks for the answer!
Currently working on the implementation.
