The controller requires to be in Repeat Mode in order to carry out a SYSINIT either via command or via Aux Func 0805.
Yes, sounds strange indeed......I would of thought this would be a teach mode function, but it is not.
There must be some form of software interlock internally that requires Repeat Mode to be used.....as for why, I have no idea.
On a physical robot "P1020: cannot operate, teach pendant in operation." is generated when the teach lock on the pendant is ON. This will happen when the robot is in repeat or in teach when you try to do a sysini.
My guess is that in the simulator when in teach, it must be virtually turning on the teach lock automatically and turning it off when going to repeat.
Yes, sounds strange indeed......I would of thought this would be a teach mode function, but it is not.
Yeah..really strange, but it works.
Thanks
My guess is that in the simulator when in teach, it must be virtually turning on the teach lock automatically and turning it off when going to repeat.
I have a "dedicated" button to switch the controller ON or OFF that are the same of the TP, so I'm sure of it status. As kwakisaki said, simply, the controller must be in repeat to perform a sysinit.
On a physical robot "P1020: cannot operate, teach pendant in operation." is generated when the teach lock on the pendant is ON. This will happen when the robot is in repeat or in teach when you try to do a sysini.
Ah.....that's a very good point ShAdOwDrAgOnS
Been ages since I have done this on a live controller:
- Try out a sysinit when in Teach Mode and Teach Lock is OFF and see if the message appears or executes the sysinit.
- Then you'll know if it is tied to just the Teach Lock and not also Repeat Mode.
In KROSET, when you toggle the Teach and Repeat switch, if you then use SWITCH command, you will see the TEACH_LOCK status also toggle between ON (for Teach) and OFF (for Repeat).
So by definition, in KROSET you always need to be in Repeat to 'force' the Teach Lock off in order to carry out a sysinit.
Ah.....that's a very good point ShAdOwDrAgOnS
Been ages since I have done this on a live controller:
- Try out a sysinit when in Teach Mode and Teach Lock is OFF and see if the message appears or executes the sysinit.
- Then you'll know if it is tied to just the Teach Lock and not also Repeat Mode.
I know this for a fact to be true on a live controller, which is why i mentioned it. Because the only time i come across this error is if I left the Teach Lock ON when doing a sysini. Robot can be in teach or repeat when doing sysini as long as the teach lock is off.
So by definition, in KROSET you always need to be in Repeat to 'force' the Teach Lock off in order to carry out a sysinit.
That's what I suspect is happening when using virtual controllers such as Kroset.
Edit :
When working on live robot , before anyone reading this thread is tempted to do a SYSINI, i always suggest making a backup of your code and only use SYSINI for legitimate reasons to clear the robot memory as it will result in changing high level system switches which could have adverse effects.
I recommend using SYSINI/U to only clear the User data as this will leave the environment data and high level system switches as they were.
Use at your own risk. You have been warned!
I recommend using SYSINI/U to only clear the User data as this will leave the environment data and high level system switches as they were.
Hi,
I search for this command in the manual but I only find the "classical" sysinit:
Are there other options for this command to clear other specific part of the system?
(like save /p/l etc....)
P.S.
Indeed i found a sysint/n: I try to compare the differecences with a sysinit/u but I'm not sure of what is the "clearest".
Yes, Kawasaki only mention sysinit as this is the method that is with Aux Function - this is the way Kawasaki recommend end users to clear memory.
In 99.9% of cases, customer will use Aux Function method, then load in previous backup to restore controller without diagnosing further.
As ShAdOwDrAgOnS also says, some high level system switches are also reset to defaults with sysinit so a previous backup is essential if the controller is to restored to identical condition.
ShAdOwDrAgOnS says You've been warned!......and I echo this too............
You can use SAVE/ROB, SAVE/SYS SAVE/A etc (See AS Manual) to just make sectional save.
Then reload to 'clean' up if required.
But be careful, as mistake in these areas could introduce many problems and without previous data to compare to, could cause damage or even injury.
There is the hardware dipswitch initialization procedure which returns to empty factory default settings.
Which make the controller inoperable until minimum configuration data is setup.
