EgmClock message does not represent UNIX time

[mkatliar]

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".

[gavanderhoorn]

So just to be clear: this repository is not where ABB maintains its EGM implementation.

This is an OSS library which implements an interface to EGM running on an ABB (robot) controller.

Issues with EGM itself -- as it seems yours is -- should be either reported to your local ABB branch office (which will then escalate them if/when appropriate) or posted on one of the official ABB fora.

From your description, I don't have the impression the issue you are reporting is specific to this library.

If you agree, please close the issue.

If you post on the RobotStudio forum fi, it would be appreciated if you could post a final comment here with a link to your post there, so we can keep things connected.

[gavanderhoorn]

Having written that: I could imagine that RobotStudio uses a non-wallclock internally for the robot controller, and the timestamps you show are relative to when the virtual controller was started.

For 28397 specifically, that would be about 8 hours ago.

[mkatliar]

@gavanderhoorn I agree. I thought maybe the documentation needs to be changed. What is the source of information about what EgmClock should contain? I could not find it in EGM documentaion.

[gavanderhoorn]

Perhaps @jontje can clarify where EgmClock comments come from.

They were added in #32, which copied the files distributed with RobotStudio.

I thought maybe the documentation needs to be changed

we try not to diverge from upstream here.

If the documentation should be updated, it should be done in the upstream files first. Then we can update here.

[mkatliar]

@gavanderhoorn what is the upstream?

[gavanderhoorn]

The EGM developers @ ABB Robotics.

[jontje]

Perhaps @jontje can clarify where EgmClock comments come from.

They were added in #32, which copied the files distributed with RobotStudio.

If I remember correctly, then EgmClock was added to the EGM protocol in RobotWare 6.07, but the release notes don’t mention it at all as far as I can see.

[gavanderhoorn]

@mkatliar: would it be OK to close this issue?

Have you reached out to ABB on the RobotStudio fora?

We could potentially add a clarifying comment here, but if it's not necessary that would be great.

[gavanderhoorn]

Closing.

[mkatliar]

@gavanderhoorn the issue is not present on the real robot, so it is probably a RobotStudio bug. I started a discussion on the ABB forum: https://forums.robotstudio.com/discussion/12743

[mkatliar]

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.
"

[gavanderhoorn]

That's a very interesting response, as both @jontje and me use RobotStudio to test and work with EGM.

@jontje ?

[mkatliar]

@gavanderhoorn I was also surprised. If it "doesn't do anything with EGM", why does it support EGM commands and even send EGM data.

[gavanderhoorn]

Perhaps a lost in translation? Perhaps "doesn't do anything with EGM" actually means: "RobotStudio does not influence any of the internals of EGM".

As I wrote in #119 (comment):

I could imagine that RobotStudio uses a non-wallclock internally for the virtual robot controller, and the timestamps you show are relative to when the virtual controller was started.

For 28397 specifically, that would be about 8 hours ago.

perhaps that's what's meant by "RS doesn't do anything with EGM", as in: RS uses some internal clock, doesn't adjust anything in EGM so EGM just reports whatever clock RS happens to use.

But this is all (wild) speculation by me (and I don't work for ABB).

[mkatliar]

"EGM is not supported by RS" also sounds interesting.

[gavanderhoorn]

Yes, I agree.

That's the first time I hear that stated about RS.

But then again, I'm just "a user".

[jontje]

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.
"

I think there has been some misunderstanding somewhere in the support chain, and that response is very vague.

When you simulate a robot "in" RobotStudio, is is technically a background process that emulates RobotWare. And it is the RobotWare process that, for example, interpret RAPID code and manages EGM clients and communication.

But this is not something users generally don't know about, so it is reasonable to send bug reports etc. via the RobotStudio channels.

So the question should have been passed along (by the support people) to the RobotWare R&D, and not RobotStudio R&D.

[gavanderhoorn]

So the question should have been passed along (by the support people) to the RobotWare R&D, and not RobotStudio R&D

yeah, that's in summary what I was trying to say in #119 (comment).

@mkatliar: you could perhaps rephrase your question to ABB support and see whether it ends up at the right people?

[mkatliar]

@gavanderhoorn I will.

[mkatliar]

@gavanderhoorn this is what I got from ABB support:

Regarding EgmClock : I don’t know. But usually we don’t care on that. The time from the first sequence is the reference time “Time 0”, then time difference from next sequence is calculated.

[gavanderhoorn]

Seems to confirm what I suspected in #119 (comment).

thanks for reporting back.

Was this in a thread on the RobotStudio forum, or a private email?

[mkatliar]

It was in a private email.

[mkatliar]

They agreed though that this is not consistent with the documentation:

Anyway I agree regarding documentation.

[gavanderhoorn]

Was there any indication the documentation / comments will be updated?

[mkatliar]

Was there any indication the documentation / comments will be updated?

No

[mkatliar]

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

[gavanderhoorn]

Nice, so even if they stated this wouldn't be fixed, it has now been fixed?