Posts: 32
Threads: 10
Joined: Aug 2023
Reputation:
1
Is there potential problems with using the Run On Robot feature of RoboDK to run production stations rather than uploading LS files to the controller and running them from the teach pendant? I get better results when using the Run on Robot feature on Fanuc, mainly due to the way tool frames have to be created outside of the program and I'm running hundreds of different programs which have 6 to 12 unique tool frames each. It does not appear that LS files can create these tool frames within the code, so there is this big potential for mis-matched tool frames. Letting RoboDK handle all the tool frame calculations and just send move commands to the robot has been less problematic for me, and also allows a cleaner interface with my HMI application. I just don't know what the down side would be and this probably isn't the way people typically run the robots in production mode.
Posts: 3,071
Threads: 2
Joined: Apr 2018
Reputation:
154
Using the Fanuc driver should work for production purposes. The main downside of using the Fanuc driver over post processing LS files for Fanuc is that you are more limited in terms of the type of instructions you can run. For example, blending/rounding (using the CNT movement modifier) only works well with the post processor.
You should also be able to define tool frames and coordinate systems through the generated LS files. Just make sure you don't use numbered frames. You can configure this behavior by customizing your post processor as well.
Posts: 32
Threads: 10
Joined: Aug 2023
Reputation:
1
For my application the robot movements are very simple and the programs are relatively short. There are just a lot of tool frames and they change for every program, plus there are a lot of variations of the program so the robot doesn't just get to run the same program over and over. Having RoboDK running in the background and then my HMI application over top of it produces the best results so far. I like being able to switch between different programs without having to load LS files to the controller and worrying about if tool frames were setup correctly. Never having to mess with the teach pendant is a big plus also. I've just only seen "run on robot" discussed as a program debugging method and not a production method, so thought maybe there might be reliability issues with using the Fanuc driver.
Posts: 3,071
Threads: 2
Joined: Apr 2018
Reputation:
154
Thank you for your feedback. In short, drivers are not as easy to support as post processors at scale. We do our best to make sure our drivers are reliable for all the robots we have in our library. In practice, developing drivers for some robot controllers require using 3rd party libraries that could be available for specific CPU architectures (for example, 32 bit Windows systems).
More specifically, the drivers for the main robot controllers should be well supported and production ready (including Fanuc, ABB, Yaskawa/Motoman, KUKA, UR and more). Let us know if you have a specific need. If you need a specific feature implemented, let us know and we can do our best to add it.
Drivers are suitable for more advanced robot applications, for example, when you use a camera connected to a computer and you want to run your custom algorithms to decide where the robot should move (3D bin picking for example).
