Fanuc diagnostic file decoding timer values don’t match

[binary_gru12]

I'm working with my cousin's older Fanuc-controlled lathe and trying to reverse engineer the timer settings from a saved diagnostic file. The machine shows 600000 ms for the M06 timer but the binary values from D0300 to D0303 don't add up to anything close. I've tried BCD, straight binary and even byte-shifted math, but nothing explains the conversion. We don't want to load the file into the machine just to read it. Is there a reference or method for decoding these values offline?

 

[JakeBugg44]

Nice project! I helped a friend with a Fanuc 0i lathe last year, those timer values can be tricky. Some are packed and change based on the control version.We used the Fanuc Diagnostics Table and a tool online, i think it was Inventcom to read them offline. Just make sure the control type matches. Hope it goes smooth!

 

[Gimm3gimlet]

I'm working with my cousin's older Fanuc-controlled lathe and trying to reverse engineer the timer settings from a saved diagnostic file. The machine shows 600000 ms for the M06 timer but the binary values from D0300 to D0303 don't add up to anything close. I've tried BCD, straight binary and even byte-shifted math, but nothing explains the conversion. We don't want to load the file into the machine just to read it. Is there a reference or method for decoding these values offline?

The numbers don't add up is usually bcs of a scaling factor. The value isn't stored in milliseconds. For a 600,000ms timer (10 minutes), the actual stored value could be 60000, and the control's display is just multiplying it by a factor of 10 to show you the milliseconds.
You should check your binary output for the number 60000 or 6000 and then work backwards from there. Also, try swapping the byte order, Fanuc can be a little particular about how it stores long words.
You're on the right track man, it's just a matter of finding that hidden scaling factor

 

[binary_gru12]

Both replies flagged the packed format and byte order as key, which lines up with what I've been wrestling with. I hadn't tried reading D0303 down to D0300 as a full 4 byte block yet, so I'll test that next. If the value's in ticks or scaled units, that'd explain the mismatch with the 600000 ms display. I'll run another pass through the file this weekend and see if the numbers line up better.