Hi Skyefire, thanks for the reply. The recovery should be fine as that's already been developed.
So then if I set up a flag and then sequence in the SPS to make sure that this has ran before I kill all the programs it should be fine I imagine?
Posts by BOTTECH
-
-
Hey Guys,
KRC4
KSS 8.3I'm looking to quit a program or set of programs when an estop or operator safety circuit is broken and go back to a state where the system can be restarted. What I am wondering is that if I write in the SPS to cancel programs via CWRITE when I pick up $STOPMESS will this also effect ir_stopm or if this is even a good way to go about this.
Basically I want to kill all when either of the safeties are broken and then go back to a state where the system will be applicable to restart and then the operator can start the system again through a push button which will be picked up in the SPS and cwrite the program to start again.Any input is appreciated
-
Hey guys,
Is it possible to release the deadman (i.e program being stepped through in T1) and then run the program again without having to do a BCO. Basically just disable the BCO run for a period. I want to run through a program, pause it, jog the robot and get the current position and stay there and continue the program.
-
As in the model number of the actual Harting connector?
-
And what about whole projects?
-
Hey Guys,
I'm looking at updating my naming convention to become more organised with my systems. Does anyone have any good standards for naming of their programs that they would be willing to share. I know it will be application dependant but I would like to get a feel for how the community deals with organisation of things such as dealing with bug fixes etc and what you would consider a major and minor change.
Say for example:Serial#_ProductName_ToolName_Major_Minor_BugFix
And on top of that how you track your changes and manage them, through the use of a simple Log or using something like Git or something else.
-
You are on the wrong road.
Fanuc has a webserver, and the HMI is based on that webserver, therefore You can configure the HMI with .XML files.
Kuka has a Windows HMI, the HMI consists of several Windows programs/plugins. If You want to create Your own HMI You have to build Windows plugins, or buy an extension to configure Your own HMI. There are some commercial extensions on market (Kuka, OrangeApps). A search in the forum "kukavarproxy" will lead You to an open source utility to build Your own HMI.
The only built-in possibility is the already mentioned "Display/variable/Overview".Thanks herrman, thats the kind of area I was looking to get into, it seemed that I was definitely going down the wrong road. I shouldn't have assumed it would be roughly the same as another system. I'll take a look at kukavarproxy, it looks very interesting especially for further development if going down the ROS route.
And thanks as well Panic Mode, for something going to be running in production I'll definitely be running one of the available resources that you have mentioned. This was more to sate my curiosity for development more so than anything.
-
Yeah, my counter example was probably a bad one to give since that functionality is already there. I'm just a bit curious of what could be done without going straight to Kuka HMI. Just for any minor HMI purpose I suppose, just having a simple go to screen that the operator could read say temperature alongside the counters or alongside the IO, without actually having to do any navigation through the menu.
Kuka HMI might just be the only way of going about it but I'm guessing that all that kuka HMI is doing is providing you with a way to already modify these existing files. -
Yeah I'm my worst enemy with these things, sometimes I think I'm the one that needs the debugging more so instead of the robot
But the jerky motion still has me stumped, so both reboots would have been without the reload file option checked.
so the flow would have been like such:1) Robot running completely fine, doing exactly what it was supposed to do as it had for the last few months
2) I came and made some very simple minor changes.
3) Re ran the program and everything was back running as normal and did so for at least half an hour
4) Then I wanted to do the removal of T2, went through the process and did what needed to be done and then did a cold start (but I never specified to reload files so it didn't work)
5) Re ran the program again and then this issue occurred with the jerky stop and go motions with no errors
6) Same thing again, did a cold start (never checked to reload the files the same as before)
7) Run the program again and everything is back to normal, running as it was in step 3) -
And I know that there is already Kuka HMI out there but for a very simple screen do you think that there would be a file located in there that could be modified for use. Say for example just to add a simple counter screen that could look a little tidier than using the variable screen?
-
Thats the weird thing, there were no errors thrown at all. It acted as if it was in normal operation and everything was running fine. Now I only let the robot run for two or three minutes to see what was happening but nothing seemed to change other than the jerky stop and go motion, it seemed to still traverse the paths that it would use when operating normally.
The T2 change worked, it was a silly mistake on my part. It worked for me on some machines but I think the reason it didn't work on others was because I must not have checked the reload files check box.
Thanks a lot for the info though, thats also something very useful to know -
Hey Guys,
Does anyone know where the file locations for the current smart pad KSS interface are located? I'm making an assumption here that the files are .xml like on a fanuc robot and that the interface is generated via this xml file but of course this could be completely wrong. Any heads up on this would be appreciated.
-
Hey Guys, I have a weird one here.
So I have a kr 20, with a KR C4 midsize running KSS 8.3.39. The program running has been running for months and works fine, motions are fine, everything seems to be fine but yesterday I wanted to make a change to make T2 mode unavailable (software turn off) on the machine and was directed to change T2 to off in the cabctrl.xml (This ended up having no effect). So I did this and then did a cold start of the controller and ran the program again but when the robot started running the motions were jerky as if you were moving in T1 and releasing and pressing the dead man on and off. Did a general search to see if anything was different but everything seemed to be fine and then after rebooting the controller once again everything was fine and back to normal.
Any ideas on what would have caused this?
And any ideas on the T2 turn off also?