Posts by rhino

So workvisual 6.0 has a scriptrunner built into it.

Write your own c# script which is run by the scriptrunner.

Anyone seen it and started coding some configurations?

So just a general question.

Using the example of the servo gun technology package irrelevant of version etc.

Looking at servo gun tech package and all the functions, declarations, structures, enums.... it seems extremely overwhelming.

Has anyone really fiddled in depth with these packages, changing code or reprogramming them to make it work for your particular case.

On a project i was asked to program the background tip dressing, allowing a pedestal gun to tip dress while the robot is in a production cycle, busy.

Reading through the variables that was given in this manual and some vague explanations about what should happen.

I felt completely in the dark, not knowing where to start, what conditions to include in each function etc.

Looking back at it now i am thinking should i have just copied a normal tip dressing functionality for a gun on the flange and adapt it to the pedestal and make use of these background dressing variables or completely from scratch.

Is there an actual course or documentation to go through that will assist

or

does it just come down to, someone else accomplished it before so grab their example and adapt it and in so you gain your experience in what seems to me like a dark art.

i have alot of kuka if you are willing to trade whatever you have for fanuc.

My experience is minimal with fanuc and really want to get solid into fanuc and abb but finding some decent source material is hard to come by

this is a great idea.

Thinking of doing this for kuka as well but if they will allow us to write up our own version of their training is another story.

Quote from massula

rhino , vkrc1 is was released decades before VASS. At that time, VW standards where more simple, and they normally changed from plant to plant, and from project from project. I think I have some VKRC1 docs, but they are in German. I will search for them and upload it somewhere.

And, as a side note, some VW plants have regular KRCs on some special cells. So, the chances are low, but this robot can really be an KRC1.

Hi, thank you

2nd day on site here. Busy on a vkrc2.there is vkrc1 here but have bot moved over to that side yet.

I have done alot of first commissioning for vw on vkrc4 which is same as first commissioning for any other krc4 ofcoarse

The vkrc2 is not bad at all to get used coming from krc4.

It takes a bit of getting used to though to get the handle of the vw standard with the makros etc.But not bad.

German language makes it a little tough. I have received alot of tools and documents regarding the current vass standard used here. Need to go through that see if it helps

But so far so good👌

Quote from massula

Hi, knowledgesharing.

VKR (Volkswagen KUKA Robot) use a dialect of KRL, called VKRL. The VKRL is simpler than regular KRL and sometimes this isn't exactly an advantage.

The programing structure is rigid, and is divided this way.

Cell.src - The main program
Folgen - Work programs.
UP - routines or subprograms
Macros - functions
VW_User - technology packages developed by VW, where is possible write regular KRL code. Normally integrators aren't allowed to modify these files.

I've posted a VSS manual sometime ago, here in the forum

http://www.robot-forum.com/rob…system-integrator-manual/

Which standard you need? The newest one is VASS. I have some documentation in german. If you want, drop me a line.

Display More

I was notified today i have to go in to do krc1 work. Im sure it should obviously be vkrc1 as it is at a VW plant.

Any documentation and standard related info would be much appreciated. I dont know exactly what VW standard they will be using on this "what i assume vkrc1".

I have never worked on KRC1/VKRC1 only on KRC2 years back and alot of KRC4's

ryno.nmmu@gmail.com

Thank you

Always wanted to try this, but by the looks of it you just pull the front sticker around the screen off and a couple of screws to access the ribbon and that should be it i think

Quote from panic mode

i don't understand...

what EXACTLY is the (original) issue? how is it similar to topic start?

safety interface was converted from X11 to FSoE?

when using network based safety interface (CIP safety, ProfiSafe or FSoE) X311 circuits must be closed because External Enable Switch is coming from Safety PLC through the mentioned network. normally this means putting small jumper plug directly into X311 (after removing existing wires that go to X11). Alternatively one can place enabling switch jumpers at X11 instead of directly at X311 but this means one cannot remove the X11 interface as it is still partially wired.

also using network based safety interface means that SION-SIB boards must be removed from WoV poject and disconnected from bus - there can only be just ONE and exactly ONE safety interface. Cannot have both CIP Safety and X11.

i don't see SION-SIBs in your photos

also WoV project configuration must be meaningful and actual connections must match the project. only then system can work. so connecting some random EtherCat device to one of the buses (KCB, KSB, KEB) will be a problem if that device is not expected by the controller.

Display More

the issue is similar with the yellow safety belt icon and the robot being red in the top bar with the x48 issue explained in the error message pointing to the Scion-cib. There will be a Beckhoff plc so using FsoE safety yes. Which im not familiar with. There is NO x11 plug. So safety over the network.

Looking at the photo above of the WoV project structure you will see the System bus x48 that contains the Scion-CIB configuration. The plc has not been installed yet so we make use of start up mode to move the robot.

We do have the jumper at X311

NOTE THIS ROBOT WORK A WEEK AGO.

no one changed anything that we know off except connecting and disconnecting the power.

We have an identical robot on the opposite mirrored line, if i connect that panel to the robot it works perfectly.

So i am still trying to figure out where the difference or the issue came in with this cabinet compared to the mirrored one to identify what the issue is causing me not to get the x48 comms and in so be able to get drives and move the robot.

hope that makes sense

Quote from panic mode

with or without PLC there need to be interlocks and handshaking. putting such code in PLC can ensure that program changes on the robot cannot bypass the interlocks. if needed those could be on a safety controller. for example one can use SafeOperation to prevent robot from entering or leaving some space.

and if there is NO synchronization, you must have at least some dead robots.

any photos of robot chewed up by press? i am always looking for good images and video clips.

As panic has stated. you clearly need to add interlocks.

Press machine needs to obviously know for itself when its open and closed fro the robot.

So add that into your plc code.

simple explanation:

1. Robot 1 picks sheet

2. Robot 1 waits at a pre drop location

3. Press has completed pressing the previous sheet.

4. Robot 2 cannot pick the part, press is giving interlock press not complete and not okay to enter

5. Robot 2 picks part when these okay to enter signals are given to the robot, and that is only given to robot once press has signaled the plc that it has completed its operation, press is in open or whatever position so robot 2 has the zone. Because robot 2 has the zone robot 1 also cannot drop until robot 2 is complete and out of the zone.......

This is a simple and crude explanation but should give you an idea

Quote from enleth

So, after getting some hints from a repair tech who sometimes works on KUKA robots I was able to identify the connectors first, and then, using that information, find an extensive manual for KR QUANTEC K prime - whose hydropneumatic counterbalance, while not identical, shares the basic design and many parts with the one on KR200. As far as I can tell, the same maintenance procedures should be safe to apply to both.

What I was able to figure out by now:

1. The allen grub screw on the back of the tank is indeed the gas bladder service port valve. The port accepts a standard M28x1.5 collar-fastened accumulator recharging adapter (also referred to as "filling and testing device") that features a hex extension shaft used to turn the grub screw (and thus, operate the valve) through the adapter's body. See e.g. page 45 of this catalog/guide PDF. Needless to say, trying to remove this screw with an allen wrench is an extremely bad idea that could get you killed. The KUKA manual does actually recommend loosening it slightly with a wrench before attaching the adapter, but no more than a quarter turn, and only to avoid applying excessive torque to the adapter's valve mechanism.

2. The upper connector on the manifold block is the vent valve, used to drain hydraulic oil from the system under pressure, as well as to vent air when refilling. It's an ISO 15171-2 M16x2.0 fitting with a one-way valve. The manual refers to a Parker Ermeto 530017 part (ungooglable), for comparison see e.g. Hydrotechnik 1620 series valves or Hydroll HGV M16x2 valves. An adapter with a manually operated valve is needed to safely drain oil out of a pressurized system.

3. The lower connector on the manifold is used to refill the system with oil. The manual mentions a Parker Ermeto RHV series part (ungooglable). I haven't removed the protective cap on that one yet - and I don't intend to before draining the system just in case, so I'll update this post with dimensions and a part number when I actually get around to fixing that counterbalance.

4. Unless the gas bladder tank develops a recharge port leak (which can happen, there's an o-ring in there that can go bad), there's no need whatsoever to actually touch the recharge port, depressurize the gas bladder and repressurize it. The hydraulic part of the system can be serviced while the bladder is under pressure. In fact, oil must not be refilled otherwise. Which means I don't need to touch the gas side to do my repair. Knowing that, I can proceed safely.

5. The oil used should be ARAL Vitam GF 46 or equivalent.

What I still need to figure out:

- how much oil exactly needs to be refilled into the counterbalance on a KR200/1A - anyone?

- what sizes and types of piston and gland seals and wipers are needed on the cylinder - I'll update this as soon as I get there and have chance to measure the original parts and locate replacements

I don't know when I'll actually perform the repair, I'm looking forward to a busy couple of weeks and the robot did not leak all of the oil yet, so it's still usable (it's a KR200 and we're loading it with no more than 2-4kg of payload), but as soon as I do, I'll be sure to post some photos and more information for anyone trying to do that in the future.

Display More

For the seals, you will most likely have to end up sending it to kuka as i doubt they will sell you those parts. Thats money for them to be made by coming out or receiving the counter balance to service it. oil quantities that is robot specific so you will either need to find the service manual documents for that robot or just contact Kuka and ask them as refilling is not a specialized job so im sure they will give those details atleast.

I think if you subscribe to Kuka Expert you might find all that info for the specific robot on there

DM me your email address, i can only set one attachment to a post. i will email you screenshots of what needs to be done exactly.

Dont have time at the moment to upload and attach here the links

Hi Panic

Sorry yes well the actual error is KSS13012 <SYS-X48> error during Ecat stack initialization [NetworkResponse () no Network Response]

The previous photo with the file missing was the wrong picture that i have uploaded. I tried to remove the SION_CIB X48 from the WoV Configuration and re add it. Did not solve the issue but yes got the config file error sorted and back to the original error.

We have temporary power at the moment for first commissioning and to move the robots for fitting of tools etc. While we wait for installation of permanent power.

Robot was working a couple of days ago and then just decided to come up with the above issue when i switched on to get it moved again.

Might be that maybe it did not switch off correctly that it decided to cause the issue.

Have given a diag to Kuka tech, awaiting response.

I believe there should be a plc between the robot and press machine? or else how does the robot know when it can drop or fetch parts from the press machine?

its way to long ago for me to remember but what i do remember is we used a special fitting and a pump for the nitrogen tanks to fill them. Theres a cap on the top of the counter balance that you take off to fill the tanks with nitrogen and pressurize the oil can.

Think we also used a similar fitting for the oil.I will speak to someone to find out if you have not figured it out already.

Sorry, the site doesn't want to allow me to put the attachments into one post

Hi Skye

Kuka KRC4 - 8.3.27

KRC4 EthernetIP v2.0.3

SafeOperation v3.2.4

SafeOpCrc v1.1.1

usertech,LDD,RemoteSV,RobotSetupMan

DiagnoseSafety v2.1.0

MSI

.....Core 5.1.2 *CustomerKOP*

Grippertech,EthernetKRL

i seem to have a similar issue, robot was commissioned by kuka 2 weeks ago. Moved fine in start-up mode since. Tried to switch on today and had this error which i have never seen before.

Any ideas?

Quote from panic mode

[size=1em]i can only go by what is shared and i saw no earlier mention of KSS8.6 or 8.7 or KRC5micro.[/size]

[size=1em]but just going out on a limb here:
[/size]
no idea what is in your project and how your WoV is configured
[size=1em]each version comes with manual explaining functionality and limitations. did you get familiar with them?[/size]

should we really guess why someone else (WoV developers) did what they did? how is this helping? they share product documentation for a reason. there is a pinned topic in German forum where you can express what you would like developers to consider in next releases. i posted few things in hope they address them eventually. you can do the same.

[size=1em]if one version crashes and the other works, why insist on using one that crashes? [/size]

[size=1em]if software complains with the message, why not read that message and try to remedy the problem? [/size]
[size=1em]if it tells that file XYZ is missing, did you try to create it? does that solve the problem?[/size]

I am still on WoV 5.0 and it works for my needs. btw i hardly do any programming in WoV - SPECIALLY inline forms. I use WoV primarily to make configuration and deploy projects, or view traces... for programming i use Notepad++. when all is done, i dump it on a robot and do the debugging, then add any inline forms if needed.

Display More

I have learned the hard way not to make use of inline forms in WoV 4.... or even using Orange Edit to rename, sort.... any inline forms. More than once. Luckily the 2nd time around i made sure to look out for it.

For some reason orange edit buggers up the e6pos when you select one to either rename or a couple to be sorted

For a real number check photos what i have done there

Quote from massula

rhino, I don't know a simple way to achieve this, but You can create a function to do that.

So, based on Your screenshots, I suppose You already have the digital input group called Wheel_Offset inside Your $config.dat, right?

Ok, now You need to create a REAL variable.

Lets call it RhinoReal

So, in Your $config.dat, You must add.

Code

DECL REAL RhinoReal

Now You need to create a .src file. Lets call it ByteToReal.src (or whatever name You want)

Code

&ACCESS RVP1
&REL 1
&PARAM EDITMASK = *
&PARAM TEMPLATE = C:\KRC\Roboter\Template\FunctionVorgabe
DEFFCT real ByteToReal(n:in )
decl int n,ofs
decl char buf[4]
decl real f
ofs=0
cast_to(buf[],ofs,n)
ofs=0
cast_from(buf[],ofs,f)
return f


ENDFCT

Display More

Now, You can call the ByteToReal function inside Your user programs, and put the converted value inside RhinoReal variable.

Code

RhinoReal=ByteToReal(Wheel_Offset)

Display More

Yes so the signal range is declared in config.dat
For my purposes i only needed an INT, so the binary signal range is loaded into the declared integer and i basically get that value sent from the plc and captured through the signal range into my local variable called PLC_offset

But "Doe" wants the plc to just send him "2" and not in a binary format in as signal range does where it will send e.g. "00000010" which does not make sense.