Hi Viesturs

 > I agree with Andy about keeping servo amps.

The problem is, that these amps are from Kuka and linked to the 
controller by some kind of bus system. At present I do not know anything 
about this bus.

 > I actually think that You
 > should keep as much hardware as You can, as long as You can get it to
 > work with LinuxCNC.

Sure, on the other hand replacing all the electronics would enable me to 
by a used plain robot, these are cheap, and add the new LinuxCNC controller.

 > LinuxCNC will certainly give You more freedom to adjust the controls.
 > OTOH I have seen some interesting features in Kuka controller that are
 > not yet available in LinuxCNC (more precisely, I do not know, how to
 > do that in LinuxCNC), for example, for any point-to-point moves user
 > can specify, if that move should be done in cartesian space or in
 > joint space - in cartesian space the trajectory is straight line that
 > connects both points, in joint space joints separately move to their
 > new locations in one interpolated move - this ensures that each joint
 > makes smallest required travel.

Indeed that would be difficult, but motion in the Cartesian space 
(called linear movements in the Kuka Robot control Language (KRL)) would 
be enough. What about the powerful base coordinate system in KRL? I 
guess G68 and G92 could be used to partly mimic this feature. But I 
don't see a way to work in a tool tip coordinate system, neither does 
G42 provide the possibilities to specify an offset in xyzABC. So this 
would probably have to be implemented via a custom M command.

 > And process of teaching the robot the trajectory also has been
 > worked out for those robots, while it would take some effort to make
 > it somewhat equally easy in LinuxCNC.

Hmm, I don't want to teach moments, but I'd be handy to be able to teach 
the work piece offset, by teaching three points to specify orientation 
and location of the XY plane.


What LinuxCNC would be able to do out of the box is tool radius 
compensation, though I don't real know how well this is implements for 5 
DOF movements. KRL can't do it at all.

 > So I would say that LinuxCNC will give You more control on how things
 > are done inside (and this does not guarantee that LinuxCNC will do it
 > better, You simply will have more freedom to adjust different things),

What I'm mostly interested would be a simple and fast way to control the 
motion of the robot from an external system by streaming location and 
orientation data at the speed of the main control loop and/or at the 
speed of the servo control loop. Almost all or all motion planing an 
tool path interpolation is than done external only the kinematic would 
be handled by LinuxCNC.

It's possible to get this (at cycle times of around 12ms or from 
1-100ms) but both solution would require replacing our old KRC2 
controller. So it would be an investment of about 20000 EUR or more.

 > If I understand correctly, the Kuka controls are already working, so
 > it is already there for no additional cost, while implementing
 > LinuxCNC will cost You some materials (probably a PC, wires etc) and
 > _lots_ of time, which could be spent doing other useful things.

Yes, the current set-up (original Kuka KRC2 controller, slightly 
modified: more RAM, SSD, faster CPU, KVM extender, KVM over IP (best 
investment ever as it alowes copy/past to and from the Kuka controller 
and recording screen shots and videos)) works.

My problem is that I would need faster communication to the robots 
motion planer to get down delays and to speed up movements. If I buy it 
form Kuka its 20k and up, we don't have that money, but I also don't 
have a lot of free time. Hmm. It would be so easy if detailed in depth 
information the Kuka controller and an SDK would be available. The main 
motion controller is running in VxWorks environment, so in theory I 
could write a simple program receiving my data stream via UDP and feed 
it into the motion controller. Unfortunately the VxWorks installed does 
not include any network interface drivers (network trafic is routed to 
VxWorks by the Windows NT embedded running in the idle thread of 
VxWorks) and I was not able to find information on the interfaces of the 
VxWorks motion control program.

See you
Florian

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to