Posts by MNMRoboter

Quote from panic mode

then better way is to not block at all... let each instruction take the time it needs and look at the program state for verification and sequential activating of the commands.

maybe something like this

Code

IF ABORT_PROGRAM THEN
  MODE=#SYNC
  IF $PRO_ACTIVE THEN
     CWRITE($CMD, STAT, MODE, "STOP 1")
  ELSE
    IF $PRO_STATE1<>#P_FREE THEN
      CWRITE($CMD, STAT, MODE, "CANCEL 1")
    ELSE
      ABORT_PROGRAM = FALSE
    ENDIF
ENDIF

Display More

this version not only checks program state but only executes commands that may be needed. if program is not running, there is no need to issue STOP command, if program is already deselected there is no need for CANCEL either.

Would this not call CWRITE continuously until the checked flags are false? I have not looked at the documentation to know enough about whats going on behind the scenes, but have found that in my experience it is always best to ensure that all calls to functions are explicit. Wouldn't it be better to implement falling edge triggers on $PRO_ACTIVE and $PRO_STATE1 or does it not matter in this case?

Could you provide more information on the forum? I am not logging in to google just to view the files you have shared.

Does the EDS you are using load with images in Sysmac? The file provided by kuka was not complete in our case and caused some problems, the Omron forums have a lot more information on this.

Also keep in mind that FSOE will not work as omron does not support FSOE for 3rd party devices. Why ? Who knows.

I Have a similar use case. What works best for me is to queue requests on the PLC and set priority within the queue if needed. I do this but using a single point of entry i.e. all 8 functions talk to the robot through a single interface. Set a busy flag to true when any of the programs starts a robot request and then have the functions wait for the busy flag to be false before selecting a program to run.

It might take a little more work to structure the PLC code, but i think its worth the effort.

Yea, i'll look into it more.

Thanks for your help.

I forget just how complex the processes running in the background actually are, the interface and simplicity of programming masks so much of the complexity involved.

If KUKA is pushing the use of splines, surely there must be an advantage to using them over the "classic" motions for most cases? I tested our program with both spline and classic motions, not noticeable difference in a simple application. I'm sure there will be edge cases where one is superior to the other though.

Quote from panic mode

"S" motions are newer and generally perform better. i stated here generally as there may be situation where this is not the case.

hence good idea is to always test it and see for yourself.

Was under the impression that they do perform better, this is why I was surprised that he suggested changing it for better accuracy. The crash that initiated the call to support was to do with the robot going to an incorrect point ( ~10mm above the programmed point), not repeatable . No approximations in the path. I've been running some tests and see no issues with using "S" motions for our application.

Quote from panic mode

i was having some problems with SLIN and very slow motions, for some reason programmed speed was exceeded and that was not usable

I came across a similar issue. This was when doing first tests in auto mode, programmed really slow SLIN speeds but programmed speed was exceeded. Ignored this as we would be running at faster speed anyway.

Quote from panic mode

the point is.... you have a controller with set of instructions. use it all...

Good advice, I will keep this in mind. I thought they were left in for legacy support but my eyes have been opened and I can see clearer now.

Thinking back at the conversation with the KUKA support, i think he must have been mixing up with the concept of splines or something. As "S" motions provide better path accuracy in general cases, will use them unless testing proves otherwise.

Thank you for your response.

KR 22 R1610, KSS8.5.6, KRC4

Recently had a strange issue (crash) with a robot program we are developing and contacted out local Kuka for support. Couldn't get to the bottom of the problem/reproduce but the support guy critiqued the program we had written.

To give a background, our application involves working within tight tolerances for what is essentially a pick and place operation. we go along a defined path using SPTP motions and finally an SLIN to the part location and then follow the same path back to the start position. The support guy said he couldn't understand why we would use SLIN motion when the tolerances we are working with are tight and suggested switching to LIN instead as well as putting a "buffer" LIN motion between the final SPTP point and the start of the desired LIN start to the part location. This has completely thrown me off as I was under the impression that SLIN succeeds LIN. Honestly, if this was suggested to me by someone other than a Kuka employee I would not have given it much thought at all . I've gone through the manual and the training documentation yet can't find anything that would support what he has suggested.

I guess what I am trying to ask is this: Are there any applications where using PTP is desirable over SPTP, LIN over SLIN etc. ? If so what are some examples ? Why ?