EgmClock message does not represent UNIX time on RobotStudio

RAPID Programming
, , ,
1

The definition of EgmClock in proto/egm.proto is

message EgmClock				// Time in seconds and microseconds since 1 Jan 1970
{
    required uint64 sec = 1;
    required uint64 usec = 2;
}

Below are headers of EGM messages sent from RobotStudio on my system:

header {
  seqno: 352216
  tm: 28397221
  mtype: MSGTYPE_DATA
}
feedBack {
  joints {
    joints: 0.00025089801056310534
    joints: -0.010418600402772427
    joints: 0.03861050307750702
    joints: -0.0001342049945378676
    joints: 45.01199722290039
    joints: -0.0667094737291336
  }
  cartesian {
    pos {
      x: 1216.9378662109375
      y: 0.0046911695972085
      z: 1187.1817626953125
    }
    orient {
      u0: 0.3823593258857727
      u1: -0.0005403859540820122
      u2: 0.9240135550498962
      u3: -0.00022283525322563946
    }
    euler {
      x: -179.93319209849528
      y: 44.95977143802771
      z: -179.90533858705996
    }
  }
  time {
    sec: 28397
    usec: 216500
  }
}
...

The time data sec: 28397 does not look like “time in seconds and microseconds since 1 Jan 1970”.

This happens on RobotStudio only; with the real robot the timestamps are OK.

Is this a RobotStudio bug? If yes, where should I report it for it to be fixed?

2

28397 seconds = 0.32866898 days

Perhaps it starts counting once RobotStudio is launched?

3

@xerim looks like it. But it is not UNIX time :slight_smile:

4

This is the response that I got from ABB support:

according to our support EGM is not supported by RS this is why You notice different behavior of EGM clock.

"…

I checked with RobotStudio R&D and they advised that RobotStudio doesn’t do anything with EGM, so it is not a bug with RobotStudio, instead it is not designed to work with it.

…

"

It is surprising then that RobotStudio does execute EGM RAPID commands, and even does send EGM data.

5

The issue seems to be fixed in RobotStudio 21.2.9526.0 – the timestamps look like UNIX time now.