Im not sure for older versions of KSS but at least for KSS 8.7,
Base Offset:
LIN XP1:{X 0,Y 0,Z 0}
Tool Offset:
LIN {X 0,Y 0,Z 0}:XP1
There are plenty of posts on the forum discussing this along with how to use a combination of different offsets in a single move.
That was our thought as well. The MAM file seems to be correct for the robot, especially since we can rename the MAM file to match the 0 serial number and see the file then. Our conclusion is that either the RDC went bad during shipping or that it was never flash properly with the correct serial number.
If you go to Startup->Robot Data, does that show a 0 serial number?
Yes, Robot data shows a 0 for the serial number. We also tried connecting to WoV and when we pull the project, we can see the robot serial number (its correct) but when we go to deploy said project, we get RDC faults.
We talked to our Kuka Support Rep and they are sending out a Kuka Tech in order to look at this robot along with a second robot that we are having seperate issues with. I appreciate you answering. Hopefully the tech is able to figure out our problem with the MAM file.
Hello all,
Controller: KR C5
Robot: KR150 R3100 - 2
KSS: 8.7.4 HF2
We have a brand new KUKA robot. To start up the robot we did our normal routine. Power on -> backups or archive, project, and image with USB recovery stick. After we renamed the controller and deployed the project. Once that was done, we tried confirming safety configuration but got the error "Suitable MAM file not found. Error 8". Got into contact with KUKA, restored the original image back into the controller, and received a new MAM file from KUKA support.
Our new issue now is that when we go into Start-up -> Robot Data -> MAM to RDC, we cannot see the MAM file on the flash drive we have inserted into the robot. We changed the name of the controller to match the serial number of the robot with no luck. Also tried having both the .zip we received containing the MAM file as well as the normal MAM file on the flash drive. Finally, we tried loading the flash drive from both the pendant and the controller to see if that made a difference.
After looking at the controller compared to what KUKA support was sending us in screenshots, our controller doesn't have the serial number loaded onto it. Just has "0". For a test we renamed the mam file to 0.mam and were able to see the mam file then but failed to load. This was expected since the MAM file is encrypted and contains the serial number for the robot.
Has anyone had to deal with this before? Any suggestions or insights on how to load the MAM file would be greatly appreciated.
It is also possible to have your program set $OV_PRO, but this is something to be approached with extreme caution, since the override is used for reduced-speed testing.
As SkyeFire said, you have to be extremely cautious with setting $OV_PRO inside your program as it will override the speed of the robot when its being run at a lower speed for any reason. Example, if $OV_PRO is set to 50, the robot is running at 50% speed. But if you change $OV_PRO to 100, the robot will suddenly change back to 100% speed.
If you want to change it just for the paint motions as you said before. You can run something like this.
paintVel = 0.03 ; Sets paint speed to 3mm/s
$VEL.CP = paintVel
;This calls a trigger when your robot starts the motion to run the command
TRIGGER WHEN DISTANCE = 0 ONSTART DELAY = 0 DO SpeedOverride() PRIO = -1
;This will run a trigger when your robot finishes the motion
TRIGGER WHEN DISTANCE = 0 DELAY = 0 DO SpeedReset() PRIO = -1
LIN XP1Then you can write the following a programs in another file to run when the trigger occurs. Note that the global real's in the following code will have to be declared in a .dat file but for simplicity sake, I'm placing them in the same as the other programs
GLOBAL REAL PrevSpeed = 0
GLOBAL DEF SpeedOverride()
PrevSpeed = $OV_PRO
$OV_PRO = 100 ; Sets the overall speed of the robot to 100%
ENDDEF
GLOBAL DEF SpeedReset()
$OV_PRO = PrevSpeed ; Returns the speed back to previous set amount.
ENDDEFWith this setup, you can temporarily adjust the speed of the robot. But there is also the limiting factor that if you run the SpeedReset before the SpeedOverride, then you will tell the robot to run at 0%
We have EthernetKRL V3.1.3 and Kuka.PROFINET MS V5.0.4 for communications
If you start with $IN[16] up to $IN[23]
This was just an example byte that I used. Robot is a few hundred miles away and I am trying to fix an issue we just recently found for the customer. The actual bytes will be in a single byte, just quick numbers I threw off the top of my head. Sorry for the confusion.
that part is not an issue. you can make temp byte signal somewhere in the unused outputs such as
SIGNAL UpdateTemp_Byte $OUT[4016] TO $OUT[4023]
Ah ok. For some reason I got it locked in my head that we only had 2048 signals since thats what we have with the PLC.
Thank you for your help.
Reading or writing to a "group" signal should eliminate the issue you describe. However, back in KSS 5, there was a potential issue where large SIGNALs could have bits update asynchronously if they crossed certain boundaries in the I/O table. So it's probably still best practice to add a "handshake" to guarantee no such issue can occur:
Yes. The group signals is what I am going for. Currently we are using a Group Output (GO) and Group Input (GI) to communicate part status between the PLC and the robot.
SIGNAL PLCInput_Bit0 $IN[16]
SIGNAL PLCInput_Bit1 $IN[17]
SIGNAL PLCInput_Bit2 $IN[18]
SIGNAL PLCInput_Bit3 $IN[19]
SIGNAL PLCInput_Bit4 $IN[20]
SIGNAL PLCInput_Bit5 $IN[21]
SIGNAL PLCInput_Bit6 $IN[22]
SIGNAL PLCInput_Bit7 $IN[23]
SIGNAL PLCInput_Byte $IN[16] TO $IN[23]We also have the same kind of setup for output but using output signals. We then do:
PLCOutput_Byte = PLCInput_Byte
The PLC is then constantly looking for updates on the output byte which can cause invalid statuses on the PLC side if the scan hits the read at just the right moment. And I am trying to avoid using other signals because of the limited number of signals going between the PLC and the robot.
My goal is something like this:
SIGNAL PLCInput_Byte $IN[16] TO $IN[23]
SIGNAL UpdateTemp_Byte ;Not sure how to set this up
SIGNAL PLCOutput_Byte $OUT[16] TO $OUT[23]
UpdateTemp_Byte = PLCInput_Byte
;Robot updates UpdateTemp_Byte as individual bits depending on laser input
;values. Such as turning on lid presences bit and turning off search bit.
;Continue after necessary updates are completed
PLCOutput_Byte = UpdateTemp_ByteFrom my understanding, this would allow me to update the byte without allowing the PLC to see the byte mid update, avoiding the invalid status issue.
KRC4 KSS 8.6.8 KR 210 R3300-2 K
My goal is to program in an internal only byte with bits to use as a temporary byte during our programing.
Currently, we have an 8-bit GI and an 8-bit GO going between the PLC and our robot. The robot reads in the GI and copies it to the GO. The robot then reads the GO and updates the individual bits based on the program that's running. The GO is broken down into bits and grouped on the PLC side. This allows us to send multiple pieces of info across at once such as part status, lid status, tray counts, search bits, etc. Then the PLC is constantly reading in that GO. The issue is that sometimes due to the PLC scan, the PLC catches the GO at the perfect moment while the robot is in the middle of updating the bits inside the GO. Resulting in an invalid status.
I don't want to use another output, even if the PLC never reads the new GO. I thought of using a group of BOOL types as follows:
GLOBAL BOOL updateByte_Bit0
GLOBAL BOOL updateByte_Bit1
GLOBAL BOOL updateByte_Bit2
GLOBAL BOOL updateByte_Bit3
GLOBAL BOOL updateByte_Bit4
GLOBAL BOOL updateByte_Bit5
GLOBAL BOOL updateByte_Bit6
GLOBAL BOOL updateByte_Bit7but I'm not sure on how to then group it similar to how one groups signals to form GO's. Any suggestions would be greatly appreciated.
How can I define the tool zone for this robot , please instruct me
In Robot Studio, you can sign in as Safety User and then get write access. Then go into Safety under the Configuration Ribbon. Once there, you can add tools and then add tool geometries based on the shape of your gripper. These are then taken into account for Safe Move. After you finish making adjustments, you will have to write to controller and then do a warmstart in order for the changes to take effect.
Yep! I actually just made a simple program turning the outputs to true/false to open and close and it works. I was just trying to make it easier to have that subprogram to call instead of doing OUT1=True OUT4=False each time I want to open.
To get fancy (and possibly easier for others to follow code) you can replace calling OUT1 or OUT4 by creating a .dat file. Inside this .dat file, you can rename signals to whatever you choose while also keeping all of your signals in organized and located in one place with comments. An example could be:
&ACCESS RV
DEFDAT GeneralSignals PUBLIC
;This file contains signals and comments
GLOBAL SIGNAL GripperClose_Q1 $OUT[1] ;Signal to Close Gripper
GLOBAL SIGNAL GripperOpen_Q4 $OUT[4] ;Signal to Open Gripper
;Insert Signals as needed...
GLOBAL SIGNAL ClosedGripper_I1 $IN[1] ;Signal Showing Gripper is Closed
GLOBAL SIGNAL OpenedGripper_I4 $IN[4] ;Signal Showing Gripper is Opened
ENDDATPersonally I add in the "_Q4" to mark that its an output with DO4 (replaced O with Q to keep from messing up zero and "o". Same is true for "_I4".
With this, you can then call the signals with their new names inside of your programs:
;OPEN GRIPPER
GripperOpen_Q4 = TRUE
WAIT FOR OpenedGripper_I4But in addition to asking here, signing up for KukaXpert is also a good idea. There you can find plenty of manuals from programming to wiring diagrams for your robot.
Also that program is not called "DEF", its WRITE_CM_SETTING.
GLOBAL allows the program to be called from outside that file
DEF/END is the start and end of the program
WRITE_CM_SETTING is the name of the program which u can call with WRITE_CM_SETTING(*,*) Replace * with actual variables
SETTINGS_IDX:IN is the integer you want to send into the program.
VALUES[]:OUT is the integer array you return with that program
All of this can easily be found in Kuka Operating and Programming Manual
Hello jinesh rohit,
The variable $COLL_ALARM is set to true whenever a collision is detected. From there you can make another outgoing bit mirror the state of $COLL_ALARM in sps to constantly send that status to the PLC
Hope this helps
KRC4
WorkVisual 6.0.24
KSS 8.6.7
I am working on a program that will control a string of movements that will allow the program to call a point and have the robot safely move there from another point, working its way through intermediate points.
Example: Robot is at P1 but needs to move to P5. To get there it needs to move through P2 and P4 but can skip over P3 safely (assume they are in order). The way I have it setup currently is that the program calls the function name and inputs the desired position (1-10) and the robot runs a series of case statements that will move the robot around. The moves are called in a sub program just to keep the main one a little cleaner.
My question is, can I set the movement variables (acceleration, speed, base) once per run of the sub program and have it work for any of the points. Or do I have to have the variables set directly before each movement?
EX:
moveCall (movePos:IN, type:IN)
BAS(#PTP_PARAMS, 100)
FDAT_ACT=HOMEBASE
SWITCH movePos
CASE 1
IF type == 1 THEN
PTP P1
IF type == 0 THEN
PTP P1 C_DIS
ENDIF
CASE 2
etc....
what are you trying to merge?
Mainly want to copy over the IO and program files. I know the program files can be transfered but the IO i am worried about.
Would kinematics, drives, and robot specs be generated from WOV as long as I start with the correct robot. Ex: Choosing the KR 210 3300 2K would auto generate the correct specs to run the robot not including mastering
This is probably a simple question but I need to make sure that I am not about to mess up two brand new robots. I am working on a cell with two robots. KR 180 R2900-2(R1) and a KR 210 3300-2K(R2). Original images of both robots have been taken and stored in a separate location. I have to add an previous projects setup to these new robots. Old robot was a KR 150 R3100-2(R3). All three are running KRC4 8.6.8. All three robots are doing similar jobs (basic pick and drops). The question I have is what do I need to watch when merging, or if merging the old project to the two new ones is even possible? Goal is to be able to not only copy the file programs, but other aspects of the old robot such as safety, IOs, and the main.src that we use.
I created a new project and set the cell configuration to match the new robots (R1 & R2). The previous project has the R3 in the cell configuration. Again, I know this is a simple question but I am also very weary of completely ruining these two new robots.
Normally yes, but I think this was a one-off kind of situation where they forgot to manually trigger a flag off again
So, robot was given UI15 when there weren't any boxes (i had turned on DO25 manually and forgot to turn off). So, it went all way to step 8 before i could stop it. I needed the robot to go back to line 4 and repeat pick process. However, robot alwahys goes to where it left off
From what I understand, your stopping the program, selecting line 4 from the TP, and then running it. But when you run it, the robot continues with the move function from line 8. From my understanding of Fanuc, the robot will continue to finish its line of code before moving on to the line you selected unless you abort. You can do this by selecting "Func" and then pressing "Abort All" on the menu screen. You can then run the program with the line you want to start from selected and the robot will instantly start to move to that new line.
Ok thank you. We now have the PLC guys working on figuring out a way to have the speed changes from the HMI be spread out over a period of time so that the robot is not gaining that huge increase or decrease in speed and torque
I don't like the idea of the user controlling the speed but thats what the customer wants. We have a sliding bar on the HMI that will be used for the user to change speeds. But we call a function per move that changes the speed for the move based on the type of move it is. But we want to overrides the overall speed of the robot so for example we have it set in the program for the robot to make a linear move at 1000mm/s so CP_VEL = 1.0 but we want the over all speed at 30%
Curious though, what kind of issues or glitches do you think we would experience?
