Posts by massula

    I don't know any online resource that have this content.


    A first stop would be the PDL2 programming manual, easily found on internet, but can be a little bit overwhelming for first time users.


    Besides COMAU Robot Programming, You also can search for PDL2 programming, where PDL2 is the programming language used by COMAU robots.


    Sometime ago, COMAU Robotics was providing free licenses of RoboShop Lite, a simpler version of their simulator. I don't know if they still do this, but You can try to contact You local COMAU supplier and ask for it.

    I think the problem wasn't exactly this, but please note that in KSS 8.6.x You can convert a regular point to Global point through Inline formular itself, so You don't need to copy it mannually to config.dat or somewhere else.


    When You press modify, in one of the set boxes is now an checkbox or so that You can use to define this point as global.


    IF you do this, the point name will receive a g in its name, its data will be trasferred to a file called Global_Points.dat, and the point can be called in any program.

    Yep.


    As SkyeFire said, there is no synchronization


    But You can change programs and other files in Configuration Workspace, and when You deploy the project, everything will be loaded on the robot controller.


    As a rule of thumb, You can use Programming workspace when in need to change specific config files or programs, and use Configuration workspace when doing major changes in the system.


    Remember that project deployment requires a robot reconfiguration, what will probably shut down robot safety and so on, while Programming workspace (and, specifically a feature called WorkOnline) doesn't need it, being a smooth process.

    Hmm, good question. I am not quite sure, But I i have an plc which has an Ethernet/IP connection. Is it than still be possible?

    But I can always look for an IPC which has

    PLC probably have Ehternet/IP. i'm not so sure about the PC. But I would give it a check.

    In the case Your PC can communicate with the robot through Ethernet/IP, I think things would be a little bit easier, since You could send basic information packages, like bits, bytes, and words, for example.


    So, basically (and I'm writing this from memory) the PC would pick the measurements from the camera, and send it to the robot as big integer numbers. One for X, one for Y, and so on.


    On robot side, You normally associate an input group for each coordinate.


    After reading this information, You must make some calculations inside the robot, to convert Your big integer on a real number, check negative values, limits and this and that.


    After You have the right values for Your coordinatrs, You can write them inside Robot Position Variables, or inside User Frames.

    Are You sure that Your industrial PC is capable to communicate with the robot through Ethernet/IP (the industrial protocoal)?


    Because Ehternet/IP is a little bit different from regular Ehternet (TCP/IP).

    So, I don't have access to these softwares right now, but looking at my notes, and my memory, You should follow some steps to make them work together. And, If I recall correctly, the connection was ons direction only, from OfficeLite to KUKA.Sim.


    On OfficeLite:


    You need select the VRC plugin during the OfficeLite Installation


    On KUKA.Sim:


    You need to build a cell with same robot model You have configured inside OfficeLite.


    You need to launch OfficeLite before KUKA.Sim.


    Click on the robot, and in the left column, select KRC tab. A KCP icon will appear over the robot. Click on the icon. The KCP screen will turn cyan, and this means that OL and KUKA.Sim are connected. If You jog the robot from the virtual KCP, it will move on KUKA.Sim.


    I`m probably missing some step here, but this is what I have now.

    I suppose this program was generated from RoboDK. If so, what post processor was used?


    How this first PTP movement was programmed?


    Normally, what I've saw was milling programs beginnings with something like PTP $POS_ACT, to get the BCO in robot current position. (so, depending on its current position, it can flip, crash and so on).


    You also need to take care about inserting regular movement inline formulars in the middle of raw KRL paths, since robot can "inherit" a wrong wrist config and make strange movements to try to correct itself

    I don't think there is an easy way to do this. You can't simply open a cell created on one program with another. You need to convert the RobCad cell to Process Simulate.


    Siemens recommends make this through EM-Server, and even through this method, there will be a lot of manual work to do.


    But nowadays some companies offer services or even softwares to do this kind of migration. But these are probably expensive.

    Anyway, file extension will still be a number, so them problem of Windows* not recognizing it as a text file, will persist, double-click will not work (at least at first) and I don't think there is an easy way to deal with this.


    In the rare occasions that I need to manipulate source programs that came from NACHI and OTC robots, I first opened an smart text editor, like Notepad++, and opened all the files from there.


    * I'm assuming OP is trying to open the files on a Windows machine, since Linux and Mac(?) normally handle file formats differently.

    I'm not sure if this happens.


    But You can rename an installatiin file to wethever You want. So, in each robot, for example, You could have the urp and instalation files with robot's name, or with a common name, at all.

    URP is the default format of UR robots. On most cases, .txt and .script are just the URP file, converted to easier reading on a text editor. So just the .urp file would suffice.


    But urp file just include the robot programs. Other robot configurations are in the installation file, so it would be a good idea backup this file also.