Posts by Spirit532

Quote from the leg

did you install KSS Version V5.6.10 SR

It never said SR anywhere(during the installation and also in HMI), but I might have - how do I check? And if I did, is there a way to "un-SR" it?

You should probably also mention that you work for KUKA and the prices are consistent with regular techpacks.
That is, exorbitantly extortionate if bought after the configuration.

So turns out, I was running SP1.

After updating to SP2(which KUKA says is impossible), and installing KSS, I was presented with this issue:

I've checked the MADA - it's almost identical, with a few new things added in the later KSS, here's the diff:
https://www.diffchecker.com/1ZV3cnjv
Left is old(functional), right is new(kss5.6).

Any ideas why it might be angry at $PMCHANNEL[3] specifically?

I've tried downgrading the MADA, changing everything to match, but nothing works.

The message #259(machine data loader aborted) says "The number of errors detected by the machine data loader exceeds the capacity of the message buffer", which is weird, too.

The extruder's velocity needs to be controlled from the robot, and the robot should run in constant velocity mode - look up how LIN C_VEL works.
In 3D printers the extruder is the fourth axis, driven synchronously from the motion controller. On the robot that may not be possible, since you don't have a hard realtime option, but just setting the extrusion speed and then moving the robot in continuous velocity mode should be fine.

Solution edit:
1. KUKA's statement that upgrading SP1 to SP2 is impossible is incorrect - I have completely upgraded SP1 to SP2 with no hiccups.
2. KSS5.6.10 is incompatible with KRC3, regardless of which service pack you use. The latest version that seems to be working is 5.5.16 b78, anything later doesn't.
3. Installing EthernetKRLXML via the Setup -> Install additional Software function of KSS5.5.16 solves the issue of the MFC2 being discovered as the only option.

So here's a question - can I upgrade a KRC3 controller(runs ed05 software on non-ed05 hardware and a custom MFC2/3-ish card, no KSDs) directly from KSS5.2.15 to KSS5.6.10, given that I have the full installation ISO(dumped into D:/)?
Will I kill the controller by doing this?

It's running XP SP2, so it's technically compatible with both, but I'm unsure.

Side question:
Is there a way to install EthernetKRLXML without killing the windows network driver? I see it mentioned as using KUKA Router, which I have installed, but it's still asking me to kill the driver.

I'll just reply with this picture.

KSD are customized Siemens drives with no resolver feedback. There's really not much of a point to doing what you describe, since the resolvers are still read by a proprietary system higher up the chain, and AFAIK that data is not on Interbus. For which you won't find a controller by the way(Ethernet to Master), as Interbus is KUKA-specific, even if it was based on several other fieldbus systems.
The KSDs are just gigantic 3-phase full bridge drivers with some intelligence.
What you want to do is toss the entire controller and build your own from scratch, using servo drives that can talk to resolvers.

You really need to familiarize yourself with the internal structure before asking surface-level questions like that. Everything is searchable on this forum and via google.

Quote from SkyeFire

There was a European demo project that did this for very large-volume, low accuracy milling (10m by 30m, IIRC), and achieved it, but only for "soft" materials at low speeds, at ~1mm accuracies. And it took them 3+ years, a PhD team, and several million dollars.

The only exception to this is the small Agilus robots(the 10kg models in particular) milling wood.
They can be expected to achieve very reasonable precision. I've seen my ancient KR3(same as mine, owned by someone else) hit ~100um precision, but again, if you tried to mill something remotely hard, like aluminium, you'd barely hit that precision - several companies have done so, and there are even videos that show kuka bots milling aluminium with questionable precision.

Quote from eKaninchen

I'm still missing from your posts, how writing application to process Ethernet packets and feed data to SPS (which is running at 12ms cycle) reading in a loop is much different from RSI.

Because SPS doesn't take a 12ms input. VxWin does and talks to the motion planner, the rest(including safety!) is completely bypassed when you're running in RSI. It also isn't running at a 12ms cycle, RSI and MOVECORR(here's your first hint at how it works) do.
If you just want to change variables, KUKAVARPROXY is the way to go.

There's no sorcery in developing software and hardware - in fact, that's my job.
There's definitely sorcery in reverse-engineering a proprietary system with a convoluted architecture that was built on 30 years of crutches. And even more sorcery in making something that's perfectly compatible with a black box.

There is no universal motion interface - and there's no API in VxWin that can tell the robot "move servo X that way". RSI implements a lot of the lower level control, and it's a massive binary, several hundred kB in size. I was working on creating my own version of RSI for the very reason you are - very hard realtime control, even more than what you get out of RSI. However, that project is now shelved due to the extreme complexity of it.

I'm just saying that if you really want to do what you've described, you'd be much better off buying third party servo drives and building your own LinuxCNC-based controller. It supports 6-axis cartesian kinematics, and it'll cost you less in time and money to build.

VxWin is 100% proprietary. You have to sign an NDA to get the full package AFAIK, and they might not even work with you unless you're a large commercial customer.
It's also extremely outdated, but KUKA keeps it going regardless.

RSI is a software option that is loaded into VxWin and takes over a 3com ethernet card at the driver level, for realtime motion correction on a 12ms loop. Just use google, it's easy to find.

And again, there is no documentation available, and there won't be any. You're trying to make a hack, and KUKA isn't going to help you. They have CNC and RSI packages.
You're going to have to reverse-engineer the entire controller architecture to do what you want, and you don't sound like the world's greatest hardware reverse engineering expert.

I'm also almost certain that the robot you have is old and used, and you just want to put a milling head on it to do precise work. This... won't happen, because your robot is likely lacking the absolute accuracy and high accuracy options, which are additional, paid-for calibration that you can't do without using an expensive($20-150k) laser tracker. Even if you manage to get absolutely perfect realtime control, the robot simply won't have the accuracy you want from it. Absolute numerical accuracy requires external calibration.

If you really want to go this route, just build a completely custom controller that will drive the servos and read the resolvers.

None of what you're suggesting is possible in VxWin.
All of that is done on the motion planner card, in the FPGA. VxWin just gets slow feedback for other purposes.

The only thing you could do is somehow reverse-engineer enough of the code to create a copy of RSI, which is already an option you can purchase. I have a copy of RSI, and while I can't give it to you, I can tell you from what I've gathered by looking at the code(actual RSI code in IDA/other tools, not end-user code), unless you're an expert in working with Wind River products in general, you're going to give up in a few hours. It's massively complicated.

This is an effort that will require several hundred, if not thousand man-hours to implement.

And, again - this isn't VxWorks, this is a custom version called VxWin, and as far as I know, the only compatible development toolchain for it is made by the actual developers, Acontis. There's evaluation versions for it on their site, but I doubt you'll get anywhere that way.

If you want to try doing this, you're better off spending the $4000-5000 that RSI costs to purchase. It'll be faster and cheaper, but it won't get you the results you're looking for, because realtime hardware control is impossible on KUKA robots. The best you can do is influencing the motion planner via RSI by providing target corrections every 12ms.

VxWorks(and VxWin by extension) is a hard-timed RTOS with tasks sharing execution time instead of threads. VxWin is also a highly customized version of VxWorks, so you'll have to talk to Acontis to get the right toolchain.
You have to have a very good reason for wanting to write a realtime application for VxWin.

What are you trying to do?

RoboDK is not relevant to this problem.
It does not provide path-accurate motions and can only output KRL.

ready2animate is a package containing EntertainTech, and, I believe, RSI(Ethernet). It's a set of tech options configured from the factory.
Mimic can export either EntertainTech sequences, or regular KRL code.
EntertainTech is cheaper to purchase, but since you appear to have ordered the robots already, prepare for a massive quote, especially for 3 robots.

I use a custom version of Mimic with a live control package I wrote, which also exports to KRL.

You're trying to use a spline where a PTP/LIN motion with C_VEL and soft acceleration/deceleration profiles should be used.
Robots have to obey the laws of physics(boring, I know), and the best it can do in a sharp corner with constant velocity is oscillate while changing their velocity vector(via acceleration).
Best you can get in terms of continuous velocity is using motion approximation with $ADVANCE and C_VEL/C_DIS

Otherwise you can just do LIN C_VEL and have it dispense a glob in the corner, but adhere to the lines perfectly. To mitigate this you could also use $ADVANCE with C_VEL and cutting the adhesive dispenser off just shy of the corner, to let the last bits drip while it changes direction.

Read the READ FIRST topic.

It doesn't really matter which VNC server you use on the KRC - unless it's been heavily upgraded(or is KRC4), it will still peg the CPU to 100% when it's encoding a lot of images.
Make sure to use the tile block option, so that it doesn't send every single frame, but only sends updates.

Are you sure you know what you're doing at all? I'm almost convinced you don't.
That message isn't a problem, the robot is ready to run.

If you haven't figured out what the deadman switches are for and where they are, you really need to go read at least the basic manual before you kill yourself, someone, or the robot.

You have a big and very heavy metal robot with powerful servo drives there, it's not a desktop Agilus that can't harm you if you stand a meter away.

X11 also counts as estop. The X11 plug must be connected to a valid safety system(cage, estop buttons, light curtains, etc.), but it may be jumpered according to the manual for brief testing.

I don't have experience with KRC4, but it seems like the SIB isn't receiving power. These are the errors I get if I disconnect the power jumper for the ESC in KRC3.