Posts by Spl

See the attachment

Moderator note: that was internal document

You can use dot product to get an angle between two vectors.

Even if you can create new frames with the smart pad, what's the point if you can't make the programs use them without modifying the code using workbench?

Have you tried using spline motion?

https://www.robot-forum.com/ro…ripper/msg86357/#msg86357

Rel is a counter that tells how many times the document has been modified

$in[2]=true is assignment and end if should be endif

if $in[2] then
prgm_1();
endif

Using interrupts worked. With two interrupts that use pulse(), data from the scanner arrives now constantly 5 ms later than the data through EKI. I'm guessing the 5 ms is just the scanner's response / output delay, and it doesn't really affect the data synchronization.

Thank you SkyeFire for the help.

Thanks. Didn't know that the code execution can transition like that. Will try with an interrupt tomorrow, and I think I have read from the manuals that pulse length is a multiple of the ipo cycle.

I know it must be frustrating, but it's also frustrating to me, because if setting output is supposed to be instantaneous, the results I'm seeing doesn't make sense to me.

> 1. If you need real time and determinism use RSI. EKI is just not meant for that....

I guess I could try RSI.

> 2. If you want to improve performance learn about advance run and CONTINUE, use flags or variables instead of io and remove that 50ms delay.

I don't want to improve performance. I want to find out why the $out=true/false doesn't seem to happen instantaneously, because the message sent through eki has been arriving max. 13 ms before the data from the scanner that's pulsed with the output. The 50 ms delay is there for a reason to limit the frame rate of the scanner.

Just to clarify, the time difference isn't constant. The minimum it has been is 1 ms and the maximum 13 ms, not taking rounding into account.

This is the code that I'm having problem with, and if as you are saying that the $out IS instantaneous, then I'll just ignore the time difference for now.

FOR i=1 TO 20
   IF (NOT $OUT[17]) THEN
      ; rising edge
      OFFSET = 0
      CAST_TO(Buffer[],OFFSET,0,0,$POS_ACT_MES.X,$POS_ACT_MES.Y,$POS_ACT_MES.Z,$POS_ACT_MES.A,$POS_ACT_MES.B,$POS_ACT_MES.C)
      RET = EKI_Send("Server",Buffer[])

      $OUT[17]=TRUE
      $OUT[18]=FALSE
   ELSE
      ; falling edge
      $OUT[17]=FALSE
      $OUT[18]=TRUE
   ENDIF

   WAIT SEC 0.05
ENDFOR

I know EKI and $OUT are two different things, and the scanner is MicroEpsilon's ScanCONTROL 2700. $OUT is only used to trigger the scanner to synchronize the robot's movements and the scanner's measurements. Both the scanner and the robot send data to the PC independently. I know there are possible bus, network and scanner reponse delays, but the time difference being 12ms just sounds like ipo cycle, so I'm trying to make sure if $out is actually instantaneous. The KRL program is just a loop that calls the subroutine continuously, which toggles $out on and off periodically, and every rising edge sends the robot's pose to the pc.

KSS 8.3.28, KRC4

I have a subroutine that triggers a scanner using $out and sends the current robot pose through EKI to a PC. For some reason though, the measurements from the scanner arrive to the PC 12 ms after the robot pose, so I'm wondering if the output is actually set electrically right after the instruction or the next ipo cycle.

Well, I'm yet to code for IIWA myself, but looking at the code you pasted, the javadoc KIIWA pasted, and the manuals I have, just change the frame parameter of the createNormalForceCondition().

So maybe something like this:

AbstractFrame TCP = nase.getFrame("/TCP");
AbstractFrame NewFrame = Tranformation.ofDeg(0,0,0,180,0,0), TCP);

ForceCondition normalForce_x = ForceCondition.createNormalForceCondition(
NewFrame,
CoordinateAxis.X,
40.0,
8.0);

OR you could just define a new frame to the sunrise project, and use that in the function call instead.

Use a correction frame which axes point opposite to TCP's?

I highly doubt that card is going to work in the robot's bus. The only way I can think of to get it work, would be to add it to an external Beckhoff PLC, and then pipe the data to the robot using EL6692 or EL6695.

Or just use EL2624 if relay output is what you need.

The operating manual states that the lamp takes ≤120 mA, so there should be no reason why it shouldn't work.