Serial communication port

[ellim]

Can i know that max serial communication port can be use in KR C2? is that possible that i connect 2 device with  2 serial comm port in KR C2?

[SkyeFire]

I've never seen any documentation of support for more than one serial port, but I can't say definitely that it's impossible. 

There are some other alternatives that might work.  You could use an RS232-to-RS485 converter and hang multiple units on the RS485 bus, although this would require some creative programming to manage traffic.  Still, I've seen it done.

Most PLCs still have RS232 communication modules available -- you could have the robot communicate with the PLC via RS232, and the PLC handle the multiple "slave" devices.

Or, using CrossCom or .NET programming, you could create a program in the Windows side of the KRC2 to pass commo from VxWorks over to COM1 or COM2.

Still, probably the first thing to do is contact KUKA's support hotline and ask them for a definitive answer on the number of serial ports.

[ellim]

Skyefire thanks for your information.

[soravis]

Hi
My questions regards not just the serial comm., but I didn't want to open a new thread...
Thanks to a university project, I'm working with a KUKA KR6.
Basically, I want to fetch the angle positions (and communicate with the robot on serial port) realtime, while the robot is moving (during a PTP for example).
So far, could do this with the submit interpreter. I created a custom .sub file, with the serial communication (reading the $axis_act variable), I run it as submit interpreter; then I start another program with the move commands.
Questions:
   As the two program can't share a common serial port handler, my best idea to send a message from the submit interpreter (which receives commands on the serial port with cread)  to the other running program is through global variables. Is there a better way?
   Is there a way to interrupt a PTP action and change the destination point, or otherwise alter the movement? Forexample I would like to track a moving (rolling) ball with a camera, and grab it with the robot
   I searched, but didn't find detailed information about the submit interpreter. What is it exactly? What is it's purpose? It is simply a "background process"?

regards:
soravis

[gianne]

Hi soravis,

the submit interpreter is a "background program" like a plc program, that loop continuously when you turn on the KRC.
Generally it's used for managing the periphery of the robot cell and to communicate with other machines.
Inside the sps.sub (program relative to submit interpreter) you can't insert move intructions and wait sec or wait for statement, so you shouldn't stop the loop.

gianne

[SkyeFire]

 "Realtime" over the RS232 port is often an oxymoron.  I'm not going to say it's impossible, but it's definitely questionable.  I've seen near-realtime RS232 operations done using the SPS, but only in applications that could tolerate the occasional "hiccup" in communication.

There is a way to interrupt robot program execution and re-direct motion on the fly, using Interrupts.  However, this is a "chunky" method -- if you're trying to chase a moving target, you're going to have problems doing it this way.  If the target is moving in a straight line at a constant speed, such that you can interrupt the robot's motion and send it on a pursuit course, this may be workable.  But if you're thinking in terms of constantly updating the robot motion in near-realtime, I have to say I don't think it's going to work very well.  Maybe if the target was moving slowly.

The best way to handle an application of this kind is to buy the KUKA RSI tech package, which is intended exactly for the kind of thing you're doing -- realtime control of robot position and velocity by an external sensor.  It won't work with RS232, because RS232 isn't timing-determinant, but the latest versions will work with streaming TCP/IP data.

However, if you can't afford that, my next-best advice is as follows:

1:  don't go opening/closing the RS232 channel in the SPS, this causes timing lags.  Open it on a request from the robot main program and keep it open until the main program signals that the operation is over.
2:  Global variables are, yes, the best way to communicate between the SPS and the main program.
3:  if you can send "delta" corrections to the robot (that is, "from your current position, move +x, +y, +z"), that should make things easier. 
4:  Try to buffer at least 2 corrections ahead of the robot.  Maybe feed a looping array of positions.  I would avoid using interrupts in the robot program unless you don't need smooth on-the-fly updating, as noted above.
5:  If you want smooth robot motion, you have to keep $ADVANCE higher than 0, but anything higher than 1 will cause other problems, with the robot trying to plan motion more than 1 move ahead.  Factory default is 3.

My off-the-cuff program would look something like this:

Code:

WHILE $IN[50] DO ; input to keep running
  FOR i = 1 TO 3
    PTP_REL MoveBuffer[i] C_PTP ; "ring" buffer of relative moves filled by SPS, SPS must keep at least one full move ahead
  ENDFOR
ENDWHILE

Speed will be an issue -- the faster you go, the bigger and more "chunky" the corrections will be. 

[soravis]

Thank you for the detailed answers!

gianne: Well, I'm already using a wait sec instruction in the .SUB, and it's working. :) Moreover, once I stopped the loop with exit, and the submit interpreter terminated nicely.

SkyeFire: Yeah, the KUKA RSI package would be too much cost... I'm stuck with plain KRL. In the meantime, I found this topic: http://www.robot-forum.com/robotforum/kuka_robots/smooth_motion_of_kuka_in_visual_servoing-t2919.0.html, and that is similar to what I would like to do.
My plan is to run the serial communication in the submit interpreter, and feed the point queue to the main program, to a ring buffer - as you mentioned. As for the smooth motion... I already tried the c_ptp method, with a loop and $advance=1; yes it's a bit slow, but works. I will try triggers as well.
One more question... What's the difference between a simple loop with "ptp point c_ptp" instructions, and the code you posted in the aforementioned topic (where you suggested triggers)?

Thanks again

Soravis

[SkyeFire]

Well, using RS232, I'm a tad concerned about timing issues.  Using a TRIGGER'd subroutine to fetch serial data might allow you to do this without having to monitor the RS232 port from the SPS, but I think it would be more vulnerable to "hiccups" in the data flow.  The TRIGGERs in the other post were more to fire I/O at certain points along the path, anyway.

The general concept of these approaches is the same, in that you have some sort of near-realtime guidance system streaming correction data to the robot and staying at least one step ahead.  The low-level implementation is something that'll probably have to be worked out experimentally.  Unfortunately, I've never had a chance to try this out for myself, so all my advice is just theoretical based on other things I've done with the KRC over the years.