Hi Kwakisaki,
following your suggestion in the yaskawa forum:
I use the prime command to re-call the main program (indeed I've a button that when pressed execute the prime of the main) but as I said in the yaskawa forum I haven't enough experience on kawasaki ( and you confirm my suspect
) that could exist an automatic way of recall a main program.
Ah.....thought you'd be interested.
So:
- Your master program MUST be called pg0.
- RPS system switch MUST be turned ON (recommended that you have this controlled/monitored within a PC Task to prevent someone turning it off).
- You must then allocate and use dedicated input external program reset.
Without RPS system switch turned on, the current program in the stack would get reset to step 0 upon receiving the external program reset input.
With RPS system switch on, then pg0 will replace the current program in the stack and reset to step 0.
So, in essence, as long as:
- You have your master program named pg0.
- RPS system switch remains ON.
- Then the input allocated to external program reset, will re-prime pg0 from step 0.
- You could then wire the external program reset into a dedicated output or an output from a PLC to force reset to pg0 (very common method).
As a test, if you have KROSET on the virtual TP and Terminal Window.
- Create a program and name it pg0, and put a couple of steps in it.....HOME and CALL testing.
- Create another program and name it testing, and put in a step......JMOVE #p1.
- Prime the program testing in the program window.
- Go to Aux 0601 and set EXT.PROGRAM RESET as dedicated and allocate internal signal 2001.
- Go to Aux 509 and set a push button (no 2) and set the signal as 2001.
- Go back to main teach screen and turn off all monitoring screens - you will be left with the FUNCTION TABS.
- You will see RPS 'greyed out' - indicating it is OFF.
- Press A and you will see it turn black, press the RPS button and it will turn Yellow - indicating RPS is ON.
- Now go to your interface panel and press your button, you will see program testing is replaced with your pg0.
- If RPS is OFF and you press the interface panel button, then ONLY the current program in the stack will be reset to step 0.
- So it is imperative RPS to remain ON for this function to operate flawlessly, otherwise you will just reset the current program in the stack to step 0.
This method is very common place and because it is not 'well documented', it can cause startup issues if RPS is accidently turned off.
I have been called out to several sites, where the RPS being turned off, has caused line stoppages.
Hope this helps......................let me know if you have any trouble................
Hi,
I tried the procedure this morning in kroset (PcAs environment ), of course it works.....well.....we can say that is quite the equivalent of yaskawa, but a little bit tricky to achieve.
This method is very common place and because it is not 'well documented'.
Just to talk about: but would you recommend this procedure to prime a job?
Just to talk about: but would you recommend this procedure to prime a job?
In my opinion, it depends on your client and application requirements.
It provides simplicity for the operator, but can offer restrictions for maintenance and testing unless configured appropriately to circumvent.
The fact it is optional and not enforced is a distinct advantage and therefore allows a more flexible system for end user requirements.
It is certainly something I bring to the discussion table when clients are not conversant with Kawasaki options available.
Kawasaki veterans are well versed in this method, and as it's not well documented, then newcomers may not be aware of the availability.
I am in the process of trying to convince a client to adopt this as they're operators do not use the Kawasaki regularly enough to remember how to sufficiently interact with the system, should they need to if it stops.
Don't forget:
- pg0 could just be used to CALL a more user defined naming convention, so could easily be 'bolted on' to an existing application.
- External program reset input is leading edge (pulse) recommended 0.3s - 0.5s duration..... so are very push button friendly.
On a side note I consistently see applications where the PLC or Field device is permanently sending HIGH signals to signal types that only require a pulse.
It can cause problems when it comes to troubleshooting and also could create unwanted actions when recovering from emergency stop events.
Please read the External IO Manual regarding the signal types and apply the appropriate type in the field devices.
when do you want to prime the main program? it is not necessary to have the name program with the pg0 name. Can you describe the conditions?
Kawasaki veterans are well versed in this method, and as it's not well documented, then newcomers may not be aware of the availability.
Yeah for sure...of course I see more natural "my methods" because I've always used it for the other robot firm. I just want to know what is more familiar to kawasaki programmer.
Please read the External IO Manual regarding the signal types and apply the appropriate type in the field devices.
Wow...personally I spend a bit of time reading the manual, but I think that without your process description I will never find the "RPS solution"
when do you want to prime the main program? it is not necessary to have the name program with the pg0 name. Can you describe the conditions?
Hi Alexandru,
to prime and then execute the main program, I create a pc task. Every time the operator restart the machine or turn it on I forced him/her to press 3 push button:
1 push-button -> prime the main job
2 push-button -> turn the motor on
3 push-button -> exec the main job
The first two button have got a lamp: the lamp turns on when the job is primed and the motor is on respectively, so the if the two lamps are turned on the operators know if everything is good to push the third button to start the process. Otherwise they have to do again the procedure.
Yes, if I remember rightly, RPS is more utilized in BLOCK programming in conjunction with using this method of program selection.
- You don't need any other code/background task to control program selection.
- Just set up the dedicated signals, wire them upto the PLC and use the pgxx naming convention and BLOCK program away.
- So it's like a built in macro really.
These are indeed documented in the External IO Manual, but if you're not BLOCK programming, then the references contained are often overlooked.
With the flexibility and power of the AS Language, these features can be programmed in instead and therefore newcomers sometimes do not realise features like RPS are available to also exploit from an AS perspective too.
But as Alexandru has mentioned, pg0 is just a name at the end of the day and most programmers result to 'their own' naming unless explicitly requested by the client.
There is one good/bad thing about this when using the external program reset dedicated input....irrespective of RPS or not:
- If in repeat mode and running, if a 'pulse' on the input of external program reset is received, this will abort the current motion instruction.
- Turn off cycle start.
- In a controlled stop.
So the external program reset can be used as a process abort and re-prime button.
If RPS is on and you have used pg0:
- This will be loaded in the stack at step 0.
If RPS is off:
- The current program in the stack will be reset to step 0.
This can cause some issues if not correctly managed, but also a great feature too.
Hi,
as Motouser mentioned you can use pc program to abort current operations (if they are) and start with main program, for example:
------------------
MC ABORT ;stops current program execution if neccesary
WAIT TASK(1) <>1 ;waits to stop
-------------------
MC KILL
IF SWITCH(POWER) == FALSE THEN ;turns on motors if they aren't
MC ZPOWER ON
WAIT SWITCH(POWER)==TRUE
END
MC EXECUTE your_pg
This way is better if you want the robot to do all stuff with resetting program. If you want PLC to do this, use kwakisaki method.
I am trying the above method and I have verified that RPS is ON. (It indicated it is on to the right side of the screen). When the External program reset is input I get an error "P1038 Program does not exist"
I created pg0 and copy pasted my main program logic to is but it doesn't seem to recognize pg0 as being valid. Any ideas on what I can try?
Try with the extension .pg maybe it will work.
If You have a button, you can prime your main program and you dont need pg0 or other stuff.
Attached is a very quick demo of how to implement pg0 and external program reset and the importance of RPS ON.
