Is it possible to run Beckhoff motion control on a Kuka controller?
This was a question that arose as we were thinking about new machine concepts.
The final goal would be to reduce costs for large scaling projects, by having only one controller for both.
So far there has not been a choise for a specific robot and robot controller, but it is to request for any feasibility.
From the Beckhoff site we would have some servomotors that will to camming to a virtual master. Motion control
will be programmed in latest TwinCat version, motion will run in NC-task.
There is no coupling of motion between the robot and the Beckhoff motion application. The goal is as said cost reduction for large scaled projects.
Should this ever have been done in the past?
Are there things known from the Kuka side that would exclude Beckhoff motion control running on its controller?
Thanks
Beckhoff motion control on Kuka controller
-
Plc_User -
December 18, 2023 at 11:53 AM -
Thread is Unresolved
-
-
Is it possible to run Beckhoff motion control on a Kuka controller?
Running how? With what level of integration? In the Robot or SPS interpreters, or in the Windows side of the KRC?
If you have a separate Beckhoff motion controller, giving it orders from inside one of the KRC interpreters via fieldbus is fairly easy.
If you want the robot to perform fine-grain realtime control of the Beckhoff motion system (direct control of accel/decel, PID loop, etc), that becomes rapidly more complex, and might end up requiring RSI.
If you want to have the Beckhoff motion control software running independently in the Windows side of the KRC, that's... complicated. And probably not advisable. It might work, but the Windows side of a KRC is always lowest priority for system resources relative to VxWorks/KSS, and probably will have issues supporting a real-time control system. The Windows side of the KRC is generally only suited to applications with high latency/jitter tolerance, like user interfaces.
-
We want to run the Beckhoff independently. The Beckhoff will have nothing to do with robot motions and also not the other way around. It is just using the Kuka IPC for the Beckhoff drives , to reduce cost in a scaling project.
-
Maybe but.. i would not go for it. The thing is that it requires resources that also need to be real time. That will be considerable burden and it is possible that eventually they would fight for resources. Beckhoff has ways of managing resources, for example it is posible to dedicate one or more CPU cores to it, while windows takes the rest. This worked on my PC but it was not problem free. It did reduce number of crashes when virtual machines are running. Without dedicating core(s) to Bechoff, crashes were fatal in a sense that everything freezes and the only way out is to reboot. For me that was unacceptable as i tend to run tons of applications at the same time in addition to 2-3 VMs. So number of modified but lost files was too significant.
And this is on a regular PC where this was supposed to work.
Kyka PC us not your average PC. Also note that on case of KRC, computer hardware is not managed in windows but vxworks ( version that was customized for Kuka). And that is quite exotic and with practically zero hope for any kind of support.
In my opinion idea is not reasonable at all. If you need computing platform and do not want to spend on IPC, try raspberry pi etc and talk to Beckhoff to see what kind of performance level is needed. RPi may not be even suitable.
-
It is just using the Kuka IPC for the Beckhoff drives
You mean the KPC in the KRC? The computer that runs Windows (for the user interface) and VxWorks/KSS (for real-time control) in parallel?
Which OS do you intend to run the Beckhoff controls in? I have to agree with Panic -- running a 3rd-party real-time control on the Windows side is likely to cause resource/lag/jitter issues, and adding it to VxWorks in parallel with KSS is very liable to break something.
KUKA does offer a SoftPLC option (ProconOS, IIRC) that's tested and approved to run in VxWorks/KSS, mostly independent of KSS, and runs at a higher clock cycle rate than than KSS does. This might offer you the additional control you seek without taking the risks of adding unsupported software to the KRC.
-
The idea is put away, as we also got the confirmation from Beckhoff it will not work.
But Beckhoff said their Twincat runtime can run on Denso robots.
The other option would be to use the Beckhoff kinematics (and Beckhoff drives) to control the motors of the Kuka robot. -
are you kidding me? i'd say go for it if you are glutton for punishment
whose idea was that? why do you think that 6 servo drives are cheaper than one IPC?
you would need to see with KUKA if they will be willing to sell you the robot arm without controller.
then you would need to remove RDC and connect the feedback to your own resolver inputs. with all the cabinet design, wiring, programming etc. you are looking at something that will cost as much as 50 IPCs.
not to mention no mastering option etc.
-
But Beckhoff said their Twincat runtime can run on Denso robots.
Honestly, switching to Denso robots so you can run TwinCat on the robot controller feels like the definition of false economy. Denso's aren't terrible, but no one I know who's used them enjoyed the experience.
ProconOS or MxAutomation on a KRC is probably a better option. And I would far rather run a separate PC for TwinCat alongside a KUKA, ABB, or Fanuc, as opposed to switching to Denso (or Adept/Omron, Panasonic, Nachi....)