Posts by notverycreeative

Quote from SkyeFire

The line numbers shown are often off by a few digits, for reasons that don't bear going into now, but they'll get you close.

I am well aware of the program pointer and the advance run pointer. Our Kuka teacher hammered on that one pretty heavy. Plus Fanuc reads ahead 3 lines too IIRC.

I've done a bunch of Fanuc and Motoman programming, along with a lot of PLC programming. On the robot side I'm not used to having to go in and troubleshoot pre-built functions because they usually work, and if they don't then you just call Fanuc or Motoman to get them to fix it.

Once again, thanks.

Quote from SkyeFire

Can you identify the line of code in ST where the program stops? One way would be to change the Visibility property of the ST modules (temporarily), log in as Expert or Admin, and then single-step through.

The good news is, ST should be completely open -- unless they've changed things, the entire tech package should be plain KRL code. If you can identify where that message is being fired from, then you should be able to back-trace to the condition that caused the message, and that should tell you which signal state is missing. Then it's a matter of which signal from the WTC needs to be mapped to that input. Or, possibly, which ST parameter needs changing -- you may simply need to turn the communications check off, or increase the timeout value.

Yes, I have found the line of code that triggers the message, but I don't really understand what is going on in that code just yet. It was pretty easy to just do a CNTRL+F and search for 362, and narrow that line of code down out of the 18 that were returned. I looked at that message code for maybe the last 30 minutes that I was there today, and will probably start back there again tomorrow.

I thought it was weird that the message said "weld controller1", but I could not find "weld controller1" if I searched for it in the project. My weld controller is named "WTC" in the Custom Weld Timer menu and I can find the line of code where that item is set.

Thanks for the reply. At least now I know I am headed in the right direction

If your PLC and Robot are both using Ethernet/IP then there is an Explicit Message configuration in the PLC that you can use to read the Alarm. I believe this topic is addressed in one of the Ethernet/IP manuals.

According to the manual it is not supported with any robot that has Safety Over Ethernet (FSU Ethernet Safety).

I have tried to implement it in the past, but have never had the time to figure out how to make it work. We read the alarm codes out of Fanuc robots all day every day though with a similar process.

I think Servo Tracking Error is the one you will get if the robot crashes.

Is the path being offset by a sensor or perhaps with some math?

Hi, I am fairly new to Kuka. We did go do the Programming 1 and 2 classes at Kuka, but past those topics I am pretty inexperienced.

We have some brand new KRC4 controllers running KSS 8.6, GripperSpotTech, Servogun Basic 3.1, and Ethernet/IP. I've figured out how to get the spot guns set up, and how to get the robot communicating with a PLC. I have gotten hung up with getting the Spot weld instruction to work though.

We are using a WTC 6000 Weld Controller/Timer. It communicates with the robot via Ethernet/IP. The communication and mapping between the robot and the welder is good. I can go to my Digital Outputs and turn Weld Enable on and off, and the Digital Inputs for "Weld Mode On" , coming from the welder, will turn on and off. I can also make the welder weld if I toggle the "weld initiate" DO. There is not a module available for the WTC in the catalogs, so I used a Custom Weld Timer. I entered all of my Input/Output numbers into the configuration screen for the custom weld timer too, but if I try to execute a Spot instruction the controller returns a "ServoGunMessages: 362 - Communication Timeout for communication to weld controller 1". There doesn't seem to be much information about that exact error.

I spent several hours today googling, searching this forum, and looking through the various SG files, but have not found anything that stands out to me as to why I am getting that error. In the ServoGun Basic manual it mentions that if you use a custom timer that you will need to get with Kuka. Does anyone here happen to know if this requires files from Kuka to resolve, or is there just some variables that need to be altered to get the Spot instruction to interact with the IO I already have set up.

I have an open ticket with Kuka, but I am not expecting any real response until Monday. The project is pretty hot right now, so I figured I would ask here to see if anyone can bonk me in the head with the knowledge stick

Thanks for any help.

You need to see if you have the Extended Weave Schedule enable in the system variables. It's something like $WeavSchedExt_Enb. Make it true if you can and you should get all of those options in your weave schedule dialog. I don't know if this is something that needs a Pac Code or not, but I would look and see if it's there first before you call Fanuc.

Or if you want to keep those settings hidden but still change the values you can do it in the $WeavSchedExt variable.

I don't have a pendant in front of me, but I would think you should be able to do something like this. So you'll be giving the value to the PLC through the groups, and they should be able to BTD it into a tag and do the addition to get the final number

If your values are going to be larger than 512, then you should be able to create separate if statements that will cover you for when the D value is higher. You would need more than two groups though.

// If the value is less/equal to 255 only write to one OG
If D20 <= 256 then
Set OG68 D00020
Set OG69 0
Endif

//If the value is larger than 256, but less than 512, set first group to 255
// then we subtract 256 from the D variable and set
//the remainder into the second OG
Elseif D00020 > 256 AND < 512
Set OG68 256
Sub D0020 256
Set OG69 D0020
Endif
//If the data is larger than 512, but less than 1024,
//We do the same thing, but subtract 512 once we have
//populated the first two groups with that value
Elseif D0020 >512 AND < 1024
Set OG68 256
Set OG69 256
Sub D0020 512
Set OG 70 DO20
Endif
//or even larger than 1024
Elseif D0020 >1024 AND <2048
Set OG68 256
Set OG69 256
Set OG70 256
Sub D0020 1024
Set OG 71 D0020
Endif

I don't have a pendant in front of me, so I can't test this for you right now... but I think that should work?

Have you checked Motomans documentation database?

I know there is some Fronius documentation in there.

https://www.motoman.com/manuals/

Went through the setup of these reamers that SKS is now offering... We were told that this was the first time they have been sold in North America so maybe this will be of some help to people on down the road. Our setup was on a DX200 controller with a FSU board on R1.

The reamers can be wired right into the SKS UNI5 Interface board, and you can use the SKS interface bits that Motoman has labeled in the Universal In/Out. There is one wire that has to be tied into the cell E-stop circuit. The way it's designed, the cell should be in an E-Stop condition to get into Manual/Setup mode for the reamer. In our setup, we put this wire on a spare terminal that we had running back to a safety output on an AB Remote rack in our Control Cabinet and just tied it in via the Guardlogix. If you didn't want to do that, you could employ a safety relay and one of the dual channel Functional Safety Outputs to drive the safety relay. We tested it this way, but someone wanted it to go back to the Remote Rack Control Panel for some reason.

The E-Ream manual was correct in almost every aspect. The wiring diagram was right, but for some reason once we wired the discrete I/O into the SKS interface board, the robot lost communication to the UNI5 interface. After much head scratching, several minutes of interrupted cussing and much more manual reading, I could not find anything telling me what the issue may have been.

What it boiled down to was that you need to run the weld macro (the one that calls up your group, file, and program number) job after you attach the reamer wires to the UNI5 interface... My best guess is that there may be some transistors in that board that freak out once they go under load.

TL;DR: We had two robots, both with UNI5 boards.. Hooked the reamer leads up to the first board, and the relays didn't work... tried the relays on the second board and those worked.. Hooked the reamers up to the second board, then the relays on that board stopped working... A few hours later I thought running the weld macro couldn't hurt.. Ran it and everything started working for some goofy reason.