Hi to everybody!
I have a question is it possible to run some predifined program from 1 button? And what I need to do for this purposes?
Thank you in advance!
Regards,
Scotty
Hi to everybody!
I have a question is it possible to run some predifined program from 1 button? And what I need to do for this purposes?
Thank you in advance!
Regards,
Scotty
Depending on your robot and controller you can switch the controller to "automatic external" and then connect a PLC or some clever wiring to give the right commands at the right time (clear messages/activate drives/motion enable/start). If you have that wired you can easily connect 1 button for the start signal.
If you make sure that you have the right program selected then this should work.
With UserTech, it is possible to run some minor "macro" type programs based on pendant buttons.
At greater complexity levels, the SPS can monitor buttons and perform certain tasks based on them, but these tasks cannot include motion of the robot (certain external-axis configurations can be SPS controlled, however). It is also possible for the SPS to emulate the pendant menus and perform tasks such as Reset, Cancel, and Select in the Level One interpreter.
Depending on your robot and controller you can switch the controller to "automatic external" and then connect a PLC or some clever wiring to give the right commands at the right time (clear messages/activate drives/motion enable/start). If you have that wired you can easily connect 1 button for the start signal.
If you make sure that you have the right program selected then this should work.
I want to avoid using PLC's. And what do you meant to make sure that I selected right program? As I know with external auto it should call all the time 'cell' program.
How do you ensure that someone hasn't manually selected the wrong program? Or that someone hasn't manually jogged the robot to a bad starting position? Just putting the robot into External mode does not guarantee that CELL.SRC is selected. Yes, the default SPS should select CELL... but only if there is no other program already selected.
You can, perhaps, avoid PLCs, but if you want to use EXT mode, you'll need several safety and "regular" I/O devices, connected to the robot, to serve in place of the PLC. The robot must be provided the correct safety signals before anything can happen, and then your manual 'buttons' would have to provide the startup signal sequence in the correct order and timing. Not to mention, you have to protect against situations where the robot could collide -- for example, starting CELL from the beginning when the robot is not at Home position can easily cause a collision when the robot attempts to move directly Home. And for some serious faults, you may have to connect the SmartPad anyway in order to recover.
This (starting with one button) is not an issue. Solution is to use EXT mode and submit as 'external controller'. There is NO need for separate PLC but you do need few jumpers and correct configuration.
This (starting with one button) is not an issue. Solution is to use EXT mode and submit as 'external controller'. There is NO need for separate PLC but you do need few jumpers and correct configuration.
Could you tell me what I have to do for this purposes? I was thinking that I need to make some special code for analyzing the button in sps.sub but I didn't think about jumpers.
Thank you in advance!
as mentioned - use EXT mode. this requires AutoExternal IO configuration (explained in system integrator manual).
since submit is replacing PLC, one must write some logic that mimics PLC. i normally create state machine.
some signal in EXT must be robot IO, such as drives on and external start. to control them from robot itself, you need those inputs connected to robot outputs (this is where jumpers come in)
[size=2]
EXT sequence is something like:
a) select correct MAIN program (CELL for example), could be steps 1-9
b) powerup drives (if not powered already), could be steps 10 - 19
c) acknowledge messages , could be steps 20 - 29
d) start program, could be steps 30 - 39
e) optionally select correct application (subprogram to CELL), could be steps 40 - 49
common way to do something like this is by making FSM (finite state machine) since writing same program using conditional logic could be very difficult. FSM principles are explained here:
https://en.wikipedia.org/wiki/Finite-state_machine
you can make as many states as you like and each state can be used to do something specific. once complete, change state to another one, so FSM will process next state etc.
Note, above list of steps is just a rough overview, each of those "steps" may need to be further broken down into sub-steps, perhaps powerup drives is really five or eight steps (depending on your implementation) since powering up drives is edge triggered.
one way to handle this is to:
10. set DRIVES_OFF HIGH, set MOVE ENABLE high, set DRIVES_ON low
11. if PERI_RDY is high, job is done and we can move on to the next step (step 20) but if it is not, you need to do proper sequence such as:
12. wait 20ms (keep DRIVES_ON low! it must be low long enough in order to detect rising edge)
13. set DRIVES_ON high and wait another 20ms (too short pulses may not be detected)
14. return to state 10.
Further notes:
* one can also make many FSMs running concurrently and interacting with each other.
* when programming in System Submit (or program called by submit) it is important to avoid WAIT commands (use timers and IF statements). failure to do so will lead to slower execution of housekeeping tasks and logic used by various tech packages (for example gripper tech etc.). it may also completely stop them from running so programming logic for Submit requires care.
* Submit task is more challenging to troubleshoot, it is a good idea to test as much as possible using robot program (any functions etc). if your robot is running recent KSS (8.3.15+?) ask KUKA for MultiSubmit. this will give you up to 7 user tasks and you can use WAIT commands too if you like and all your code can be in those tasks (leave System Submit to experts).
* if calling another program from Submit, run-time variables will be disposed after each call. state variable therefore must be declared in DAT file
* for easier monitoring it is helpful to make such variables global (at least during development phase)
[/size]* if you think you can or cannot do something... you are probably right. if you are not sure but want to try anyway, make sure to have good backup and ... consider taking KUKA training
I did couple state machines with Fanuc robots, same concept. I was using BG logic as you sad without wait conditions. Just 'IF' and regular system timers for making program start sequence. I hope I will do a good job with KUKA.
My concept for KUKA is:
a) modify sps.sub to check button press and rest of handshaking signals and interlocking
b) when button is pressed and robot isn't running, no warnings and etc then do
CWRITE($CMD,STAT,MODE,"STOP 1")
CWRITE($CMD,STAT,MODE,"CANCEL 1")
CWRITE($CMD,STAT,MODE,"RUN /R1/MAIN()")
c) rest of robot job in MAIN.SRC
Looks like in this case I no need to choose a program all the time when I stop/e-stop robot.
After b) You have to start the selected job. Because the Select command will only select the main.src but it will not run.
Therefor You have to doe I/O thing with the bridged motors_on / confmess / ext_start .... Signals.
also those instructions take longer to execute (CWRITE...) and may take several loops, so.... you may want to check each of them for completion before starting another one.
After b) You have to start the selected job. Because the Select command will only select the main.src but it will not run.
Therefor You have to doe I/O thing with the bridged motors_on / confmess / ext_start .... Signals.
I wrote RUN command and this command should run the program.
I was asking before to give me some template about jumpers/IO bridges for regular staff like servo on, ext start, etc. Unfortunately, nobody want to give me. Could you give me some template about IO bridges?
this is not something secret, in fact it is rather well documented. just check key manuals (system variables and programming manual for system integrators).
you need jumpers for things that must come through input and you have no option but to drive that input yourself. since inputs are read only, you cannot drive them directly. solution is to connect inputs to outputs (outputs you can control from your program).
example of signals that must be passed through such jumpers are $EXT_START, $DRIVES_ON and $CONF_MESS
you cannot have those signals simply mapped to $IN[1025] because they are edge senitive and MUST be able to change state.
other signals may be "massaged" into submission through some workarounds. for example:
$DRIVES_OFF can be fixed to $IN[1025]
$MOVE_ENABLE can also be fixed to $IN[1025] (this requires modifying $CHCK_MOVENA) etc.
as already mentioned, CWRITE command runs slowly and asynchronously. this means entire SPS may run multiple times before one CWRITE command is processed. this can cause problems specially on fast controllers (KRC4). therefore proper way is to condition your code so that each of those commands is only called once (give it a chance to complete what it is doing).