Test program Kuka KRC2

If You want to check just logic statements and program flow, the way to go should use OfficeLite, KUKA controller/KCP simulator.

If You want also check robot positions, You also need to use KUKA.Sim, in conjunction with OfficeLite

I think newer KUKA.Sim can simulate old arm models, but I'm not sure if KUKA sell OfficeLite for KRC2 anymore, or if work together with new KUKA.Sim.

Quote from dudz

The position i already checked.

We just have one robot and the company don't want to buy a license the OfficeLite, and from what I've seen there isn't a trial version of the OL like the kuka.sim

i did the same logic in ROBOGUIDE e test the logic and program flow and works like i want, but i don't know if in the kuka the logic will be work

Well, without a simulator, your only testing environment will be the robot itself.

That said, you can take steps to reduce the downtime involved. Testing the logic in RoboGuide isn't a bad idea -- basic logic is going to work the same between robot brands, aside from language differences. Like IF statements -- in Fanuc TP, IF statements can only result in JMP commands, but in KRL, an arbitrary amount of code can be placed between the IF, ELSE, and ENDIF keywords.

General rules: modularize. Make a "logic module" where your non-motion code goes, set up as subroutines or functions that can be called from the motion routines. Make each sub/func as small and single-purposed as possible. That minimizes the number of things that can go wrong, will make troubleshooting easier, and also make it easier to translate between TP and KRL when you're trying to use RoboGuide as a logic tester.

Create your "motion module" as a separate module, and write the "skeleton" of it in OrangeEdit. Use lots comments like "Program Pick Position 1 here". Put calls to your logic module in the correct places between these comments. Then, when you load the modules into the robot, you can just go to the correct comment, hit the Move button, and add in the motion command you want.

When loading more than one module into the robot, load the "lowest" modules first. That is, if Module A makes calls to Module B, and Module B makes calls to Module C, load in the order C, then B, then A. That'll help avoid linking errors during load. In fact, load C first, then fix any errors found in C before loading B -- that way, if new errors occur when loading B, you can be confident that the errors are either in B, or in the calls between B and C.

Quote from SkyeFire

.. in Fanuc TP, IF statements can only result in JMP commands, but in KRL, an arbitrary amount of code can be placed between the IF, ELSE, and ENDIF keywords.

On newer Fanucs there is a similar IF/then/else.

That is a problem in any programming language... For humans, not for computers...