Posts by robotecnik

    Hello all,

    We can store data in PR in cartesian and in joint modes.

    If I understood it correctly, if in the PR[1] I have a position stored in degrees/joints, If the programmed line is L PR[1] it will go to PR[1] using the shortest path, but, if I use J PR[1] it will work as a MoveAbsJ in ABB, granting that the robot will move to the position in degrees for each axis, allowing me to grant a known starting position.

    If I have not understoodf it correctly, how can I execute a movement to degrees like MoveAbsJ in ABB?

    Thank you all!

    Yes, the KCP is a simple display with a membrane keyboard and the safety devices in it.

    You should be able to exchange them without any issue.

    Another option you can do is to plug a keyboard, mouse and VGA monitor into the PC to do the same.

    I can't remember now, but maybe it was needed to activate the VGA output in the BIOS before being able to do that.

    Hibernation: the computer stores everything in RAM into the HDD before shutting down. Then, at boot, it reloads everything again in RAM.

    This means that, after the operator loaded one program the first time, he will have the program working until something fails and they need to cold start the robot (which almost never happens).

    In any case, if this happens then their maintenance department will just recover the file using the depicted steps and everything will be OK again.

    You don't have the complete picture: the program itself stores program local variables (used by the libraries) (i.e. limits of the pallet table for that model) and of course, those variables are not there if the program is not there... and, following with the example, the pallet control library won't find those variables...

    That also happens with a few functions (and as far as I know KRL doesn’t offer late binding).

    But this is another story, I can explain you how the design was done years ago (by a group of programmers with master degrees) and why this was the best solution (given KRL limitations) but this has nothing to do with the problem itself and I’m sure no one has time for that.

    What it was not acceptable was to go through the risk of relying on a human being every morning.

    Now, if they need technical support an expert will come and follow the simple steps to reload a program file, but in a daily basis the problem is solved. As I told in previous posts this structure has been working in plenty of robots for years without any issue.

    In any case, thanks for posting and for helping people here panic mode, you do a terrific job in this forum.

    I already found what was happening, that robot came from KUKA Germany, a technician from Spain came to make the final touch and adaptations...

    And that guy configured the controller to stop without hibernating.

    He changed the robot name (to something different than the customer standard, wrong), the fact the robot is hanging in the ceiling (good), he did not install the bought technologies (wrong) and for who knows why, he changed this setting (wtf).

    OK, at the end the problem is solved, now that I know what it was going on, it was a really easy thing. All working as usual.

    More on the proposed option:

    If I open the program, add a space, and close the program to save the changes, the program can't just reach libraries then.

    Renaming the file doesn't help.

    Only moving it out of the programs folder and moving it back there helps.

    Hi panic mode ,

    Thanks for answering.

    I know, the folder where I move the file is the repository of programs in a network folder outside of the /R1 folder.

    It works properly because, as you say it recompiles the file when it's pasted back to the R1/Program folder. The strange thing here is that an unchanged program just works well after moving it back to the programs folder.

    I know libraries should not depend on programs, but, when you have a shared logic that is the one that handle the cell behavior, you have two options: repeat the code in every program or put the code in a library, that way your main routine in the program can call the main shared cell routine and you have the same code working for all the programs, pallet handling, alarms handling... and all those things work perfectly well without repeating a single line of code then. Been using this approach for years without any problem.

    About permissions, I moved the file from Expert and Administrator and in both cases the same happened., in any case, I don't know where to look for permissions in a program, could you explain the steps to do so?

    If I don't get a better approach from KUKA service tomorrow, I'll propose my customer to make that minor change every time he restarts the robot, this has the risk of a syntax error, but at least the operators can't copy the wrong program.

    Thank you again!

    Hello all,

    KSS 8.6.10.

    I have one program (ProgX) and multiple library modules, that depend on some program variables, inside a sub folder inside the Program folder.






    And the program /R1/Program/ProgX.src + dat

    Of course, if I remove the program all libraries are marked with a red cross showing errors as they can't find the variables in the active/loaded program.

    When I copy the program back into the /R1/Program folder all the errors disappear.

    This strategy worked fine with at least 6 robots at my customer (and in multiple other robots out there).

    With this robot, though, when I power on the system, I can see libraries show the red cross (analysys error) even the program is in the folder.

    When this happens, if I try to select the program, I get a message saying that /R1/ProgX doesn't exist.

    This is strange as the program itself is not in the /R1/ProgX folder.

    It is in /R1/Program/ProgX folder.

    If I cut the rpogram from the /R1/Program folder, move it into an external folder C:/Shared (i.e.) and then I move it back to the /R1/Program/ folder, everything starts working again.

    This is a safety risk since the operator could easily select a different program and create a collision problem. Again, in all the other robots I programmed this is not happening.

    Maybe I've done something wrong.

    Any idea of what is going on here?

    As always, thank you in advance.

    Hello all,

    I have the RobotStudio S4 Lite cardboard box with the CDROM since the days the computers had CRT monitors..

    As I never used it before, and, as far as I know, I should be able to use a 30 days demo version of that software which now it would help me debugging the code I have to prepare for a customer that wants to use a very old robot while it lasts...

    This said, when I install the virtual controller package then I get a license error and I can't use the software at all.

    I have installed it into a virtual machine.

    Is that a normal behavior?

    Should I do any steps to be able to use the 30 days demo version?

    I only need to compile the code to ensure I am not using any functionality that is not present in the IRC5 rapid versions...

    Of course, I can develop it all and "compile" it by sending files to the robot and start solving the errors there, but it would slow the process a lot.

    As always thank you in advance.

    Thank you Skooter , a long time passed since I worked with S4C+ and I really lost track to the naming of those manuals...

    I posted a copy of one of those manuals (user's guide) yesterday in the manuals forum... I should delete that one.

    Maybe adding in the topic of those posts that those manuals are for S4 controllers would help other users.

    I don't need lots of functions, module (which I can program myself in case of need) and a few more, but in order to make the maintenance easier I'd like to ensure I can put the logic and the "library" functions in SYS modules common for all the programs... that is the most important thing to make it easy to maintain. Customer will make lots of programs and having logics and global functions copied in every program can be cumbersome.

    That's why I asked about the S4 Lite version, I could use the virtual controller to test the code in the 30 days demo version offered... I got it a gazillion years ago from ABB and never used it... I have not seen how to add a virtual controller there.

    Thanks for your messages Lemster68 !

    Hello all,

    A customer asked me to make a program for a very old ABB robot with a S4 controller.

    I started years ago programming with S4C+ and I would not like to do all the programming based on that S4C+ controller programming style to find that it can't work on a S4 robot.

    After copying a couple of files to the robot controller everything worked except the calls to SYS modules functions... I think I had to write GLOBAL in front of whatever function or procedure I wanted to call from different modules, but I can't be sure without some documentation.

    Do you have a manual for the S4 rapid programming?

    If you don't have a manual or you can't share it, can you explain me how should I write the function declaration in a sys module to make it visible in the program module loaded?

    Apart of that, a manual for the old "Robotstudio S4 Lite" would also be nice to have, I would like to create a virtual controller and send my programs there to get them checked by the robot compiler.

    Thank you very much.


    Global and local variables, structures, arrays, being able to return values from functions.

    Get the possibility to name points.

    Proper if/else, select clauses. Remove the need to jump and allow to branch normally.

    Remove line numbers.

    Remove the ";" after comments.

    Remove the need of an empty line at the end of the programs.


    A watch window.

    Faster interface.

    A proper editor.

    An improved error list.


    HawkME, Doctor_C, Fabian Munoz and Shellmer thank for your messages.

    Shellmer I don't have the original mastercount values, and I am sure the robot has lost power to the encoders, in fact my customer decided to power on the electrical cabinet without plugging the robot to the cabinet before.

    I will have to specialize the points a lot more than I would like... Patience.

    Doctor_C I've attached the tool picture with the values.

    You'll notice the values have changed.

    I've used roboguide to find the "normal" orientation, Z was looking upwards before.

    The old values gave the same TCP position with the Z axis looking in the opposite direction (at least in roboguide).

    As those are vacuum cups, it's complicated to get a "perfect" zero teaching it manually, that's why we wanted to go the manual introduction method.

    There is some mechanical play in the 4, 5 and 6 axes. But even with that the behavior seems strange to me.

    With any of those numbers in tools the virtual robot moves normally / as one would expect.

    Thanks for posting!

    HawkME the tools and frames I have defined:

    Tool Frame

    -165.9 51.9 -27.9 -160.0 30.0 -180.0 t1

    -165.9 -51.9 -27.9 160.0 30.0 -180.0 t2

    User Frame

    419.3 -317.6 -118.1 0.0 0.0 150.5 UFrame1

    -363.1 -194.6 -115.7 0.0 0.0 59.4 UFrame2

    419.3 -317.6 -118.1 0.0 0.0 150.5 uFrame3

    Fabian Munoz tool data comes from a 3D design and I entered the numbers directly, one tcp is at the right side of the robot and the other one is at the left side.

    But, if Fanuc works like the other robots out there, even the TCP is not perfect, the robot should move in a straight line when you move it using the frame system...

    Thank you all.