I've imported a backup into K-Roset to begin working on cycle time improvements for one of our cells and one thing I noticed is it doesn't restore the io configuration, (names,ranges) when I import my existing backup in. Is This a error on my part or do I hve to manually configure that? Thanks.
K-Roset IO Setup Question
-
ericwiz7923 -
January 24, 2020 at 8:26 PM -
Thread is Unresolved
-
-
Sorry can you elaborate a little more with this, I know it's basically repeating your post, but could you provide some specific details.
- What do you mean import an existing backup, can you describe you're procedure.
- Which IO configuration are you referring to, General IO, Fieldbus IO, ALL IO.
- Are you referring to the IO Tab or the Teach Pendant.
- What names are you referring to, dedicated names, general names, variable names.
KROSET misses this as a direct function in my opinion (in comparison to other OEM OLP).
I don't think they incorporated the 'importing' of a real world robot file save into KROSET and I have found that I have to modify/prepare a file save before loading it into KROSET.
-
Thanks for replying Kwakisaki,
"What do you mean import an existing backup, can you describe you're procedure."
I right click on the controller and load a pre-saved .as file backup
"Which IO configuration are you referring to, General IO, Fieldbus IO, ALL IO."I'm probably using incorrect terminology. I'm assuming by loading that saved file that my IO names, and dedicated asigned signals would all load in to after I sync K-Roset with the controller. If I look under I/O name monitor all I have are the basic Home, Cycle Start, Error, Teach Mode, Auto ect.
"Are you referring to the IO Tab or the Teach Pendant."
the Virtual Teach Pendant, correct me if I'm wrong but the IO signal tab is just for sending IO between two virtual robots?
"What names are you referring to, dedicated names, general names, variable names."
Mostly Dedicated names.
I will admit I need to familiarize myself more with how the IO Configuration (between robot and PLC) work. I know we aren't using the arm board (correct name?), that everything from the EOAT is hardwired from a j-box on j3, through a multi conductor cable going through the robot cable way and is terminated inside the robot cabinet on the door. Everything is ethernet from the robot cabinet to the plc.
-
Tried attaching my whole backup for reference sakes but the comment box didn't like the .as file extension....
-
yes, change the extension to .txt and it'll upload then.
I'll bash it in KROSET my end using the method I use (and video it if you like and post it), so you can maybe try that method.
Would it be ok to post a video clip of my procedure using your backup?
As I said, Kawasaki have not implemented or documented a 'simple' method of porting in a backup from the real world, something I hope they will address soon...…
As most users of KROSET are using it to look at existing applications, tweaking them in simulation and transferring to the real world.
-
Feel free to post a video, I appreciate your help. K-Roset has been great tool to help familiarize myself with Kawasaki's in general but I agree, some features aren't user friendly or obvious. I've really enjoyed K-Tools for reading/modifying programs though.
-
Give me 10 mins...….
I think the main problem is using the 'Right hand side' to upload your file to.
I've just tried it as per your procedure and yes I can confirm the IO names do not update on the Teach Pendant.
I use an alternate method, this I'll video and post.
-
OK...…….
So the key with file uploading, as KROSET does not have a built in option for this (well not a direct option), is you could do with familiarising yourself with the data contained in a backup/controller.
When you are familiar, you will know whether you will receive errors or not during the upload and also whether they are important or not.
So, first you need to remember that KROSET uses preset AS Firmware.
The file you are loading in will be based on a certain firmware and this firmware probably will not match the KROSET AS firmware.
Therefore it may or may not include the same settings, so you can appreciate there may be errors during the load.
Also, the file contains the IP of your Controller, KROSET uses a default one.
This would also produce an error during the load as you would be changing it.
The procedure I use is by way of terminal, this is as close as you can get to replicating your cell without having the 'Online' function in KROSET available (licensed required for KROSET to enable you to go online with the real world).
However, you are likely to receive errors, for the reasons I highlighted above.
So I always remove the header (the header is not important at all) and IP address from the filesave.
Sometimes I also remove the ROBDATA1=>.END but in the video, I have just done the minimum.
I know straight away that I am likely to receive errors during the load because the firmware is different, but depending on the nature of those errors, will depend on whether I can use it or not, or need to strip more out.
But I do know, that the resulting transfer will be as close as possible to the real world BUT not identical.
Have a look at the attached and see if that is a better method for you...…..
-
If you create a standard project using your controller and manipulator.
Then using the Terminal method, you may find it easier to upload exactly what you want, and ignore other settings by modifying the backup before loading.
Have a look at the backup and you see 'sections' wrapped.
.ROBDATA1
.END
.OPE_INFO1
.END
.OPE_INFO2
.END
.SYSDATA
.END
.AUXDATA
.END
.INTER_PANEL_D
.END
.INTER_PANEL_TITLE
.END
.INTER_PANEL_COLOR_D
.END
etc etc
You could just strip out these sections and load them independently using the Terminal Method.
Or you could strip out more out of the sections and just load those in.
This way you can control just what you load into KROSET project.
For example, if you have an empty project, and want to upload your signal names.
The signal names sit in the .AUXDATA section, so you could create a text file in notepad for example with:
.AUXDATA
N_OX1 "Close Gripper 1"
N_OX2 "Open Gripper 1"
N_OX3 "Close Gripper 2"
N_OX4 "Open Gripper 2"
N_OX5 "Latch Tool Changer"
N_OX6 "Unlatch Tool Changer"
N_OX7 "Bypass Light Curtain"
N_OX8 "Robot in Start Zone"
N_OX9 "Tool Change Ready"
N_WX1 "Gripper 1 Open"
N_WX2 "Gripper 1 Closed"
N_WX3 "Gripper 2 Open"
N_WX4 "Gripper 2 Closed"
N_WX5 "Tool is Coupled"
N_WX6 "Tool is Uncoupled"
N_WX7 "Tool Ready To Couple"
N_WX8 "Light Beam ON 2nd Aligne"
N_WX11 "Tool 1 "
N_WX12 "Tool 2"
N_WX13 "Tool 3"
N_WX14 "Step Key Switch"
N_WX15 "Select Tool 1"
N_WX16 "Select Tool 3"
.END
Then save that as a file (extension you could have as .txt)
Then place that file in the PG folder of your project.
Then in the Terminal, type in load 'filename'.txt and it will load just that information into the AUXDATA.
In this case, your IO names will appear on the Teach Pendant...….
I do recommend having a good play around with this, remembering that you can just load in what you want, as long as it is contained within the correct section/wrapper name.
-
This is very helpful! Would you recommend after completing the terminal back up to individually tackle and resolve each error that is created or can a lot of those be ignored. I do have a full license so in theory I could get online with the cell/robot, I just have never done it and figured offline was the easiest/safest way to "create" a test program for that cell. Would you recommend trying it online? Thanks again Kwakisaki.
-
I looked over the beep program
.PROGRAM beep() #6173
SIGNAL 46 ;beep
TWAIT 0.5
SIGNAL -46
.END
You can do it with PULSE 46,0.5 it is the same function.
-
That's a very good question and one that Kawasaki do not seem to answer.
They do not make every firmware available in KROSET that is available in real world, only a select few.
Therefore, if you look into those errors, you may find nothing but a brick wall without having the exact firmware in KROSET available.
Also, Kawasaki Controllers do have different applications and when creating a project, you need to:
a. Make sure you select the relevant application.
b. Try and use a firmware level that is closest to yours from real world a superseded one is preferable.
This will reduce the amount of errors received during a load.
Any error produced in KROSET during loading in, you would need to treat as a 'as required' basis and would need further research to see if you can fix the error.
If it was not impacting on what I was doing in KROSET, then I would just make a note of it and carry on.
Remember, KROSET purpose is not to produce a valid structure which could be simply uploaded to the real world controller.
A lot of users have this misconception, produce a backup in KROSET and load it into a real world controller which could result in many errors including re-zeroing the robot with KROSET values (which would be very disastrous).
It is purely an OFFLINE simulator tool.
An additional license is required to actually go ONLINE with KROSET (if you have it, it's worthwhile using in your case).
However, you may still experience the 'stock firmware' differences between the 2.
However, when you're up to speed with 'what is contained' in a backup, you can use KROSET very effectively to test sequencing, setup IF pages, IO names, and ultimately make modifications, prove them and then load JUST THE CHANGES you've made into a real world controller by preparing the relevant data from KROSET to be transferred to the real world.
-
An example is above what Alexandru has written.
You could simply copy and paste that code into a text file in notepad, save it in the PG folder of your project and load it in.
Only that program will be rewritten with the load.
-
As a test, download the attached program.
Place it in your PG folder.
Then from the Terminal type in: LOAD ifpdemo.txt
This will copy the program into the Controller.
Then from the Terminal type in: PCEXECUTE 1:ifptoggle
Open the teach pendant, you will see it toggling the IFP Panel pages 1-4 and back to the teach screen.
To stop it type in: PCABORT 1: and then PCKILL 1:
Then you can delete it if you no longer want it.
A simple test of transferring a program from an offline source to KROSET and testing it.
Then if you want, in the Terminal type in : SAVE/P testifp = ifptoggle
This will then save it with the filename in the PG folder with a .pg extension.
You could then edit it (change the TWAIT value for instance) and then reload it in again and test it.
(you would need to include the .pg in the load command again)
-
I looked over the beep program
.PROGRAM beep() #6173
SIGNAL 46 ;beep
TWAIT 0.5
SIGNAL -46
.END
You can do it with PULSE 46,0.5 it is the same function.
That's good feed back thank you. Besides being cleaner programing will this save on scan time possibly?
That's a very good question and one that Kawasaki do not seem to answer.
They do not make every firmware available in KROSET that is available in real world, only a select few.
Therefore, if you look into those errors, you may find nothing but a brick wall without having the exact firmware in KROSET available.
Also, Kawasaki Controllers do have different applications and when creating a project, you need to:
a. Make sure you select the relevant application.
b. Try and use a firmware level that is closest to yours from real world a superseded one is preferable.
This will reduce the amount of errors received during a load.
Any error produced in KROSET during loading in, you would need to treat as a 'as required' basis and would need further research to see if you can fix the error.
If it was not impacting on what I was doing in KROSET, then I would just make a note of it and carry on.
Remember, KROSET purpose is not to produce a valid structure which could be simply uploaded to the real world controller.
A lot of users have this misconception, produce a backup in KROSET and load it into a real world controller which could result in many errors including re-zeroing the robot with KROSET values (which would be very disastrous).
It is purely an OFFLINE simulator tool.
An additional license is required to actually go ONLINE with KROSET (if you have it, it's worthwhile using in your case).
However, you may still experience the 'stock firmware' differences between the 2.
However, when you're up to speed with 'what is contained' in a backup, you can use KROSET very effectively to test sequencing, setup IF pages, IO names, and ultimately make modifications, prove them and then load JUST THE CHANGES you've made into a real world controller by preparing the relevant data from KROSET to be transferred to the real world.
After our conversations I am seeing that is the big hitch in this. I'm slowly picking out a lot of the finer details.
As a test, download the attached program.
Place it in your PG folder.
Then from the Terminal type in: LOAD ifpdemo.txt
This will copy the program into the Controller.
Then from the Terminal type in: PCEXECUTE 1:ifptoggle
Open the teach pendant, you will see it toggling the IFP Panel pages 1-4 and back to the teach screen.
To stop it type in: PCABORT 1: and then PCKILL 1:
Then you can delete it if you no longer want it.
A simple test of transferring a program from an offline source to KROSET and testing it.
Then if you want, in the Terminal type in : SAVE/P testifp = ifptoggle
This will then save it with the filename in the PG folder with a .pg extension.
You could then edit it (change the TWAIT value for instance) and then reload it in again and test it.
(you would need to include the .pg in the load command again)
I'm just getting back to this project today so I'll give it a twirl.
-
Quote
That's good feed back thank you. Besides being cleaner programing will this save on scan time possibly?
Little things like that can save you cycle/scan time for sure.
A lot of the AS Commands have some subtle features associated with them and would require further reading of them to fully understand them and therefore produce more efficient code structures as well as improving cycle times etc.
For example:
TWAIT
Holds program execution for the period specified in secs.
DELAY
Tells the robot to move nowhere for the period specified in secs.
But does not stop forward processing/execution upto the next motion instruction.
2 types of 'delay', but have different characteristics.
QuoteAfter our conversations I am seeing that is the big hitch in this. I'm slowly picking out a lot of the finer details.
In comparison, I am in your position but with an alternate OLP as I am self training on Fanuc's Roboguide and that has some really good features compared to KROSET.
But if everything was easy, it kind of takes the fun out of it...…….so for that reason, I do like KROSET as it produces lots of challenges......
Keep with it though, you'll be amazed at what you can learn just from KROSET and just reviewing full backup filesaves and trying some text file editing, loading, downloading etc...
-
Around 1:40 of the alternate file load video you posted you did a save as of the modified txt document, selected a file type of "all files", and ended up with a AS file type. I keep ending up with .txt file, any suggestions on a way to correct/work around this? I tried copy and pasting it into a program file of a KTools file and when I loaded I got a bunch of syntax errors then.
-
Yep, with notepad it always defaults to extension .txt.
By selecting 'all files', this allows you to place an extension on yourself.
Therefore the filename you type in to save it as, you specify including the extension.
Not sure about whether KTOOLS can accept .txt files as I don't use it (but would be surprised if it can't).
What sort of errors did you get?
-
I'll try and re-create that here shortly. I ended up dropping a known backup into the PG folder and loaded that and this is where I'm at currently.
-
And here is my pendant.
-