Timer variable on Fanuc 16TT

[aj]

Greetings, everyone.

Years ago I wrote a macro that relied on reading the #3001 variable (milliseconds since power up) to do some time related tasks automatically. It runs well enough on our 18i, 21i and Oi machines, but on the 16TT (older) control #3001 counts up to 65535 and rolls back to zero.

I've tried getting data from the 6750-6758 addresses but I get an "ILLEGAL VARIABLE NUMBER" error when I try to read them.

I've looked in the manuals but can't seem to find what I'm looking for.

Anyone have an idea where else I might look?

Thanks in advance guys.

 

[LockNut]

Greetings, everyone.

Years ago I wrote a macro that relied on reading the #3001 variable (milliseconds since power up) to do some time related tasks automatically. It runs well enough on our 18i, 21i and Oi machines, but on the 16TT (older) control #3001 counts up to 65535 and rolls back to zero.

I've tried getting data from the 6750-6758 addresses but I get an "ILLEGAL VARIABLE NUMBER" error when I try to read them.

I've looked in the manuals but can't seem to find what I'm looking for.

Anyone have an idea where else I might look?

Thanks in advance guys.

What are you trying to get with the 6750-6758 variables. Sounds like they don't exist on the 16. You need to give more info on what you are trying to do.

 

[LockNut]

Greetings, everyone.

Years ago I wrote a macro that relied on reading the #3001 variable (milliseconds since power up) to do some time related tasks automatically. It runs well enough on our 18i, 21i and Oi machines, but on the 16TT (older) control #3001 counts up to 65535 and rolls back to zero.

I've tried getting data from the 6750-6758 addresses but I get an "ILLEGAL VARIABLE NUMBER" error when I try to read them.

I've looked in the manuals but can't seem to find what I'm looking for.

Anyone have an idea where else I might look?

Thanks in advance guys.

After digging a little deeper, those "variables" are not variables. They are parameters and can't be read like variables would be. What, exactly, do you want to do?

 

[aj]

After digging a little deeper, those "variables" are not variables. They are parameters and can't be read like variables would be. What, exactly, do you want to do?

I'm doing something like #147=#3001/1000 to give me seconds, storing that, comparing it to a previous end of cycle read to see if it's been an hour then storing parts per hour, average parts per hour, that kind of thing.

#3001 is a millisecond timer. On all the other Fanucs it counts to some outrageous number, but on the 16TT it resets every 65535/1000 seconds, and with cycle time over 2 minutes it's useless.

 

[wmpy]

You can use the #3002 system variable instead. It is an hour timer with max hours being 114543.612. To get seconds, just multiply by 3600 instead of dividing by 1000.

 

[aj]

You can use the #3002 system variable instead. It is an hour timer with max hours being 114543.612. To get seconds, just multiply by 3600 instead of dividing by 1000.

#100=#3002 gives me an answer of -6893.9344 which slowly increases by 0.0001 every second.

I really think the timers I'm looking for aren't in the 3000 range like they are on the rest of the Fanucs here.

 

[wmpy]

Hey aj. That's weird to get a negative value in that timer. I have no explanation for that.

I tried the code below on a machine with a 18T controller, and it worked fine. I think it should be the same as a 16TT.

#3002=0;
G04U4.;
;
;
;
#500=[#3002*3600];

#500 showed a value of 4.026

Does this work on your control?

 

[aj]

Hey aj.
I tried the code below on a machine with a 18T controller, and it worked fine. I think it should be the same as a 16TT.

#3002=0;
G04U4.;
;
;
;
#500=[#3002*3600];

#500 showed a value of 4.026

Does this work on your control?

Nope. I get 0.0160. I even chased it with an M99 and let it run for a bit. Still 0.0160 after half a minute or so.

 

[wmpy]

Weird. I don't know.

What about system variable #3012 ? This should give you the time (that is set by the clock) in the format HHMMSS. Is this working normally? Can you do anything with that?

Otherwise, I'm out of ideas. Maybe angelw can shed some light on the situation.


Congrats on your Lions, by the way.

 

[wmpy]

Did you get this figured out?

When you tried the bit of sample code I posted, did you include the extra EOBs? Without those, the block lookahead makes it so that a value is written to #500 before any time has passed. Your block lookahead may be different than mine, so you may need more EOBs. Or just post the timer reset line at the top of your program and the timer reading line at the bottom.

Having that sample code loop won't change anything because the timer gets reset every time.

Here's the code re-posted with comments.

#3002=0;(reset hour timer to zero)
G04U4.;(wait 4 seconds to simulate time going by in a program)
;
;(extra EOBs so that block lookahead doesn't let the program jump ahead)
;
#500=[#3002*3600];(read hour timer, convert to seconds, and write to #500)

Sorry if I'm beating a dead horse here, but it bugs me that this isn't working on your control.

 

[aj]

Did you get this figured out?

Yep. That'll work. I even put it in a loop and let it run long enough to make sure it would count past 60 seconds.

Thanks!