Post actual error codes.
Post the DEF lines of those two programs.
Post actual error codes.
Post the DEF lines of those two programs.
do not modify anything until you have proper backup
In the case of tampering with IP addresses, "proper backup" means a full KSR hard drive image. Unless things have changed, that's the only way I know to recover from someone breaking the Virtual Network connection between the Windows and VxWorks sides of the robot's brain (which will happen if you try changing the IP settings from Windows, instead of from the KUKA HMI).
So, one of those seems to be a simple RowHammer vulnerability, which isn't really an issue for a KUKAbot in most circumstances. Properly isolating the KRC if it is handling any confidential data that RowHammer might expose should be a fairly trivial exercise.
The other is simply that the robot can be brought to a halt using the Task Manager, after which "Brake recalibration must be performed." There's no details on that, but I'm betting this just means a Brake Test, which can be performed easily enough, without requiring special KUKA skills and/or equipment.
Frankly, neither of these seem at all serious, unless the second CVE is leaving out a LOT of details. Either one can be made very difficult to exploit simply by using proper security procedures and controlling password access, possibly adding a secure firewall between the KRC and the general network if one is really paranoid.
I am working with KUKA KRC4 running Windows 7 and need to make communication work,
What communication? WorkVisual? Ethernet/IP? Profinet? EKI?
I installed KUKAKAVA protocol-based program, but cannot connect to it. Tried KUKAKAVE with the same result.
What programs are these? Where were you installing them? On the robot, your computer, Amazon cloud server?
If you can ping the robot via the KLI IP, then you don't need to change the IP. You say you can't access shared drives -- did you set up security and sharing correctly? Are you using the correct SMB login remotely?
Does WorkVisual communicate with the robot? Have you checked your computer's firewall settings?
...now I'm going to have to get PCDK and break out my WireShark tap.
i do not care for the regulations in this case.
Anyone in this line of work who says something like that has proven they should not be trusted with automated equipment. Either they don't know what they're doing, or have a callous disregard for human life.
Most of the people you're interacting with in this thread have been in the field long enough to see people injured, or even killed, by the attitude you implied above. I've had two incidents where I came within millimeters of losing my life because someone else said "I don't care" and proceeded to act on that attitude. And if I'm honest, I can count 2-3 incidents where I was the one who got careless (due to fatigue or moving too quickly) and got lucky that no one got hurt as a result of my carelessness.
So, saying "I don't care" on this subject is a very good way to get experienced people to stop helping you on the forum. Because we don't want to help you in injuring or killing someone. And if you "don't care," you will injure or kill someone, eventually. It's hard enough to avoid even when you follow every safety rule obsessively.
And before you try to say we're taking an offhand comment too seriously: this is a topic where we cannot afford to have a sense of humor. If someone says "I don't care," we have to take it seriously, barring explicit clarification. And anyone in the forum who enables this kind of attitude is a candidate for banning.
TLDR: there are damned good reasons we take this subject seriously. Respect that or GTFO.
EDIT: I probably came across as rather intemperate, above. There's a reason for that. I literally just left an entire production line that was, apparently, designed&built by a Chinese company, to apparently no safety standard, and shipped to be installed and put into production in a North American plant.
There was no safety. At all. The robots had their built-in pendant E-Stops, but those only stopped that robot -- nothing else. There was no lock on the gate, not even a latch -- anyone could walk into the cell, at any time, and everything would keep running. There was no place to lock out air, electrical mains, or other energy sources -- killing the 480V mains to one robot required going to the plant level main electrical box and turning off the breakers for an entire zone of the building. Every safety interlock on the robot was hot-wired. There was no "software" safety -- the PLCs were non-safety rated, there was no CIP-Safe on the Ethernet/IP network, and no safety options installed in the robot (hence, no safety-rated way to ensure the robot couldn't punch right through the fence if someone programmed it incorrectly). Adding even minimal safety to meet RIA 15.06 will require massive amounts of new hardware, and re-wiring everything.
In the two weeks this line had been powered up for installation, they've already had two "near miss" events where someone teaching one robot was nearly hit by an adjoining robot that someone else had put into automatic and accidentally started.
I've seen some pretty damn serious safety oversights in the past, but this was pure, high-octane nightmare fuel. I did a massive write-up, helped add some makeshift interim safeties using the non-safe I/O, and made it clear I would not hesitate to call the responsible authorities if this plant was put into production without addressing these issues.
It varies -- Leoni has 3D and 5D models. Also, some robot&tool combinations may need to run at different speeds in order to achieve accuracy.
It's been quite a few years, but I recall the 5D taking about 10sec for a complete run.
When you reboot the robot, how far off is the clock? How long is the robot off? Are there any robot error messages (especially battery-related ones) when the robot reboots?
I am assuming that I shouldn't have big problems with crashing or whatnot because the two bases are very similiar, it is only a matter of precision.
Maybe. As Panic says, S&T can trip you up -- it depends on whether your two Bases drive any of the robot axes into different quadrants. Sticking to LIN motions instead of PTPs, at least in areas where switching between Bases could cause S&T issues, can help, but it can also "wind up" the wrist in ways that make the next PTP behave unexpectedly. So using a joint-defined point (like Home) to force all axes into an expected pose before/after the "offset" moves is a good idea.
Using Frames instead of POS or E6POS for the moves in the different bases will let the robot use the "best fit" S&T based on where it starts from, which can also help.
(Disclaimer: I AM NOT A LAWYER)
I have to go with Nation on this one. While I would love to see a Linux PCDK implementation, especially a 3rd-party one (and double-especially if it were open source), the legal issue seems to turn on one critical question: Did you create your interface from scratch, or by decompiling Fanuc's PCDK DLLs and translating them?
Generally, if you did it by purely "white room" means -- reverse-engineering the protocol from scratch, without any access to Fanuc's source code, it's legal. However, proving in court that you had no "insider knowledge" or reverse-compiled Fanuc's software could be difficult. And even if you're 100% legal, Fanuc might well still be willing to spend the money to tie you up in court until you go bankrupt from paying defense attorneys.
The question of how to write a program to handle 2D or 3D "grid" type operations (often for palletizing, but there are other operations that need the same mathematical offsets) comes up on a semi-regular basis.
Long ago (KSS 5.4 era), I was stuck doing this myself, and then ended up with a few weeks with nothing to do, thanks to supplier delays. So I amused myself by writing a general library that would handle any conceivable 1D, 2D, or 3D grid, with offsets, "every other position" patterns, etc, all by just adjusting some standardized variables. I used it for that project, polished it to a high gloss, and then proved its flexibility when the customer threw me a massive curveball by completely changing the pallet-grid pattern of the parts I had to handle (and creating a situation where my "zero" index was actually in the middle, but I still had to pick from one corner to the other raster style).
So, I bundled up my nice shiny module... and ended up never needing it again.
Until this year. I finally got another assignment where I needed to help a co-worker with a grid-style operation, with some odd requirements, pulled out my old module, and... wow! It still works, even under KSS 8.5!
So, I decided to clean it up a bit, and post it for posterity. Maybe someone will find it useful.
Now, despite my bragging above, while this is production-tested code, I've never had to use it in a full 3D grid, only 2D, and only X&Y. It's been used for "solid" grid patterns, and "spaced" grids (think a chess board, only using the black squares), plus some patterns that were "solid" on one axis and "spaced" on the other. But not anything more exotic. So while I'm confident this is solid, mostly, there are axes on the test volume that are empty. So to speak.
So, feel free to rip it apart and tell me what I got wrong.
And once again: it is not necessary to use INW in iosys.ini even if you want to use words or double words as integer signals in the robot. You can define every signals as bytes, and use them as whatever you want (single signal or integer with 2-32 bit length) in the signal declaration in $config.dat or other .dat file.
As Hermann says, you could have this in IOSYS.INI:
Then, in your program, have:
That combination works no differently than using INDW in IOSYS.INI.
It could perhaps be done in RSI, but would require building all the math into an RSI container. I don't think RSI is the best environment for trying to program heavy math operations.
Regardless, RSI can only apply corrections in Cartesian or Axis, so wherever your kinematic model resides, it must be translated into joint angles or Cartesian coordinates before being fed to the xxxCORR objects.
RSI also needs to be programmed as a series of PID algorithms. RSI motion control acts on a displacement/time model, so the input to any xxxCORR object is applied every 12ms (4ms for IPO-Fast mode). So it is up to your algorithm to, in realtime, examine the difference between the actual position and the desired position and scale the difference for input into the xxxCORR objects, tapering down to 0 as that delta is reduced.
If you're building your own kinematic model, you can simply feed either the Cartesian corrections or Axis corrections to your RSI program.
Still, if it cannot line break it the big disadvantage of editor or language
Why? Professional programmers generally avoid overly-long lines in favor of function calls. Any time your line gets wider than the interface, that's a sign that it's time to consider greater modularity.
Yes, I also considered that, but in the end I decided for another solution. But now that we talk about it: Is the alive flag always up to date, even before a connection is established in first case?
I relied on it when I was using EKI heavily, and never had any issues. I suppose there could be a problem if some other program were to manipulate the Flag or Output in conflict with the EKI driver.
I have tried BRAKE, that doesn't help.
I checked the auto external I/O's and nothing changed when the problem arises.
I changed the timer to 10 seconds and the problem went away. any ideas why the timer would do that.
You still didn't answer the question: with the timer set to 20sec, does the Notify Message show up in the message window or not?
The "Alive" flag that Panic refers to is part of your EKI channel XML file -- you can assign an $OUT or $FLAG to reflect that status of the channel. This is in the EKI manuals.
Tex -- you're generating a program offline and loading it into the robot(s). And you want an operator to be able to adjust certain points. Correct?
What does your .SRC and .DAT file actually look like?
Do you want the operator to be able to use the TouchUp button on the pendant for easy recording?
There are two ways to do this, offhand: the "hard" way is for the operator to use the VarCor, type up the full name of the point, and set it to $POS_ACT. This requires that the correct $TOOL and $BASE be active at the time.
The "easy" way is to use the TouchUp button, but this only works if your .SRC file has every point built as a correct Inline Form. This can be done, but you would need to adjust your postprocessor accordingly.
Unfortunately, using the "array of points" method as Panic suggested does not work with Inline Forms. I've often wished it did.
A 3rd way might be to create a separate executable program that, when run, would stop at each point and offer the operator a pop-up message to update the point or leave it alone. This would work with the "array of points," but would require some careful KRL programming. And integrating that with your offline program generator might be a bit tricky.