I don't work with Agilus often, but on the A4 arm, there should be 6 ports attached to 3 valves that you can use. The IO for these valves should be already mapped in the controller, and if not, you can certainly map them.
Posts by brianr
-
-
That link goes nowhere.You aren't looking for synchronization, you're looking for collision zone logic. Which is used daily across millions of robots throughout industry. Basically, each robot asserts a signal that it is "clear" of the potential collision zone, and waits for that signal from the other robot before entering the zone. Usually includes "safety net" logic where both robots halt if at any time both "clear" signals are false. Edge timing can be a bit tricky, but this is essentially a solved problem in industry.
Everything you said is (and almost always is) correct, but I'd just like to add for the OPs clarification that I would avoid at all cost the use of a "spinlock" in a robot's logic. You don't ever want to tie up the robot when you don't have to, and you certainly don't want to tie up the SPS. You want a robot that can't enter a zone to be free to do other things in the zones it can access if need be.
Example: We use KUKA's safe operation A LOT. We also have cycle stop buttons. I can't have the cycle stop tie up the motion code in a loop doing nothing, because if they leave it paused during the weekend, or long break, there is a chance that the brake test will become due, and it won't be able to preform it. If this "spin lock" persists for more than the grace period, the robot will not start back up when required, as the brake test
Just have robot A check if shared region is clear, if not signal it's intention, wait time X, and then check that zone is clear again. Make robot B do the same, but with time Y, where the difference in X and Y are greater than any latency and cycle time delays in the signal. If the zone isn't clear, move on with the logic.
EDIT: Just want to clarify that it's much better to signal when clear than to signal when it's in the shared region, that way it fails safe. If one robot is off, it can't give the clear signal, as it MAY be occupying the shared work space.
-
Hello. When you TouchUp your reference point, it also stores S and T values. So I would check correct T value in that error position for axis 6.It does store status and turn, but if he is using a frame, that data is discarded.
Is the position before the palletizing point a frame or an E6POS? Try teaching that point 360 from it's current and see what happens.
-
If you have the Zenon plugin Tech Package, it does introduce $USERMODENVAR (might need to check the spelling on that one) which can be used to determine the current user group. I use it extensively with the Zenon plugin.
-
is the USB cable from KPC to PMB (CCU) ok and plugged in correctly?I'll have them check that. They just called, and they actually have about a different faults, and all the screens are acting very slow (minutes after pressing the screen). I think something has a memory leak and is just crashing things randomly. This is probably just a symptom of the PC crashing.
Thanks for the quick reply!
-
We've got a KRC4 controller with the above message (KSS14004)
I've never seen this one before, nor can I find much info on it. It comes and goes and doesn't seem to be causing any issues (the robot is behaving unexpectedly at the moment, but that's most likely a sensor issue, not this message).
Hs anyone ever seen this one before?
-
I just run BrakeTestReq() every time I am at home, which (I think) only runs it during the 2hr grace period, which for our use is more than fine. Our robots are always on, and total cycles are well under 2 hrs (more like 10 seconds-2 minutes)
It'll bitch if it can't run at speed, which means I put in the condition for ($MODE_OP<>#T1), otherwise it bugs me while I am commissioning.
-
a simple power outage would not ruin the PC, although if the batteries are compromised, it could cause files to become corrupt, or more likely lose mastering. A voltage spike on the other hand may cause issues, which I have seen before (on the KPP, not PC)
What is your definition of "broken"?
-
Without knowing which cable you're talking about specifically, Intercontec and Harting make up like 90% of the connectors on KRC2, KRC4 and KRC4 compact. Basically, if it's round, its Intercontec, if it's rectangular, Harting.
-
We suspect a connector bad on our CCU X44. X47 is a spare, is there any way to send EtherCAT communication through this port?
Suffice to say we've tested everything and the last thing not replaced is this port/CCU
-
Articulated arms are generally not rated in accuracy, but in repeatability. It will go to the same spot every time with great repeatability, but internal measurements may be off. I think KUKA offers their robots in an HA (high accuracy) variant. All this means is that they measure the arm very carefully so that its kinematic model is accurate to that specific arm.
-
Prrrrrrobably? The high-impedance state should be equivalent to "NC". The output cards shouldn't need to be supported by KUKA -- as long as the bus coupler is supported (and it is), you should have no issues adding any I/O device to that bus coupler as long as you have a valid definer file for it. Although I do wonder about the I/O mapping -- you'd need two bits per output on this card, to control the three states per output.
Still, Panic mode has a point -- you should try a quick test of each control line on the lamp individually, and see how they turn out. If each line controls R, G, and B respectively, then he's right, and the "NC" shouldn't be technically necessary, because 3 "bits" of color will give you 7 combinations (R,G,B, RG,RB,GB,RGB). The high-impedance trick should only be necessary if the mfgr is pulling some strange multiplexing tricks with their LEDs internally.
I've had EL2502 off of a EK1100 totally F things up on different versions of WoV. At least the only thing I could narrow down is separate laptops with newer versions than mine had problems with it (the 16bit PWM outputs getting mapped to different outputs, like the EL2502 were not consuming the data... or something...) Asked KUKA for the install of an older version of WoV, and then it was all fine on all laptops. It COULD be something else, but that was the common problem that I could pin down. I dug through how the 2 versions of WoV were creating the X44 config for the same project, and it WAS slightly different. This doesn't seem to be an issue in the current versions, but it did kind of scare me.
-
I have only skimmed the requirements here, but would a tri-state push pull output like the Beckhoff EL2202 work? The outputs can be +24,0, or high impedance.
I've used a similar card (can be configured as EL2502) to drive PWM outputs to RGB+W LEDs. I haven't used it configured as the e 2202, but even as a PWM output, it does push pull (which is nice because my LEDs are 24v common) not sure how you'd map the 2202 in WoV. I left my laptop at home, or I'd try it out.
Neither of these cards are supported by KUKA, and I did have a version of WoV kill the EL2502 compatability, but I've had luck in the current version (again, no laptop, so can't check what that version is)
-
This was the first question I asked on these forums about 5 years ago. I see it get asked pretty readily now.
-
how do you know you are pinging correct device? did you ask someone on-site to unplug it so you can ping again? if that is correct device, you should no longer be able to ping it... so you have confirmation.
one issue with large networks is that you never know what ports may be blocked. this means you will need help of IT (good luck with that) or dedicated solution of some sort (hardware or software or both). for example, colleagues i talked to like to use hardware infiltrator from eWON - apparently very easy solution.
I know it's the IP address because I have it written down, saved as an IP profile on my laptop, and the IP address listed in the project agrees.
What ports are required for cell discovery for WoV? I have the ear of people high enough in this organization to maybe get this done. They are already getting me an RSA SecureID and VPN access, they might be willing to open up a few ports for me.
-
Using a gateway to the XML DA server on the robot, and now all my software sees it as a local OPC server over COM. Thanks for the help, this might actually work.
-
I have a question. I am trying to VPN into a HUGE network with thousands and thousands of PLCs and a handful of robots. I usually program on site via the service port, but need to do it via the KLI remotely to solve an issue a thousand miles away.
I can ping the robot just fine, and the robot talks to the PLCs on the network just fine as well. An engineer there told me that he can't browse for any of the PLCs as well and need to connect via IP.
So my question is, is there a way to connect via an known IP address, or is there anything else I should look at? Any experience with huge networks In this case, huge means across the globe connecting probably 100 facilities.
Thanks
-
I'm actually connecting via the XML DA, so that doesn't use DCOM? If so, maybe I can make this work
-
Is DCOM the only way to access OPC on the KRC4? I'm thinking it is, but it's looking like the client I wanted to use doesn't officially support DCOM (although said it's technically possible).
I did get the supplied softing client to connect however.
-
Port range
Firewall
Acess Right (both sides)
Client Windows account use the same as server (kukauser/68kuka1secpw59)above normally could be the problems
I didn't have the kukauser on my PC, but had an additional user on both (as KUKA instructed me). I set the port range on both machines via DCOMCNFG to 20,000-20,300, firewalls are off on both machines, all accounts listed in documents (and them some) added to DCOM and full access.
Thanks for any help, it at least helps me tick off things I could have missed.