Variable out of range Fanuc 31i

[markkirby]

I am trying to investigate cycle time elements from a large programme consisting of say 100 toolpaths. It's running on a Mazak Vortex with Fanuc 31i control and according to the Fanuc manual parameter 6758 is the accumulated cycle time in minutes (manual says it is a 2-word path, valid data range 0-999999999) and I can see it ok on screen, however if I insert #700=#6758 to try and write the cycle time at end of each toolpath I get variable out of range error. #700 is definitely an allowable macro variable, any ideas what I am doing wrong?

[stevo1]

That’s odd. I don’t have a 31i manual so I can’t really read up on it but I would think there should be no issue reading the data out of it. Have you tired using a different variable like #1 or #100 instead of #700? #699-#999 are option D for usable variables from Fanuc. Have you checked to make sure that you physically have access and can view #700?

Stevo

[dcoupar]

What is the alarm number? I think stevo1 might have hit the nail on the head. I found the following, but couldn't find one that was "Variable out of range".

[christinandavid]

Yea, I tried that - those are system parameters you are trying to read. I ended up having to use #3001 and #3002 from the exec macros. As far as I know the only way to overwrite those values is at the settings/handy screen and there is no way to read them.

DP

[markkirby]

Variable #700 is definitely ok, I use it regularly on this machine, so I don't think that is the issue. I'm not at the machine now and don't remember alarm number, but could have been 115. Attached is screenshot showing the parameter page variable I am trying to capture, 6758, cycle time in minutes...

[christinandavid]

It's a system parameter. It can't be read. Stupid I know. I think there is software out there that can use the data from a system dump and give you what you want. I'm not going to get that software so I ended up using the millisecond counter #3001 and the decimal hour counter #3002.

I created an M-code which I plonked in at the end of each sequence which converted these to hh.mmss format so I could make sense of them. The formulas required are not pretty. If you end up going down this road I can post them for you.

DP

[markkirby]

christandavid in New Zealand (we are all over the World aren't we - i was in UK before Canada) - you tried 6758 with no joy? So you read the cycle start time via 3001 or something clever likethat - I was thinking I could just capture the system time (somehow?) at end of each programme in my main programme, but since the control appeared to offer me elapsed time to date that would save hacking data around later on in Excel or something....

[stevo1]

If that is the case then you will have to use the #3001millisecond counter or #3002hour counter.

Stevo

[christinandavid]

I too was astonished that these values cannot be used. I'm hoping someone out there knows otherwise - it would save us all a lot of hassle...


Could you use the simulation to time the program? Mind you, if it is a long program it often takes longer to simulate than to run


DP

[christinandavid]

FYI the clock time and date is stored in #3011 & #3012. I use those to covertly check when the machine was powered up/warmed up in the morning (I work afternoons).


The system I am developing will involve a G-code at start of cycle to initialise macros, M-code at end of every sequence to manipulate and store the cumulative time as necessary. I have modified the ATC/APC macros, as well as B-axis indexing, to extract this time from the 'axis motion' time. It can get complex pretty quick, depending on how far you want to take it.

For instance my macro will check to see if a sequence has been repeated, and update tool times/sequence times seperately so I can see where time has been lost reworking. If a measuring device (probe/pointer/clock) is in spindle, the continuous millisecond counter is used rather than the decimal hour timer (which only stores automatic operation time) so I can see how long we spend faffing around and not running...

I have used up #500-#700 already...

[markkirby]

faffing around - haven't heard that for a while, but yes, there is lots of that. Guys used to code any experiments to MAFA on our time cards - took me a while to decode it....
As for simulating the time, that's the entire point of the excercise here, that the simulated times and actual times are quite different, due to machine AICC parameters. I'm trying to focus on the programmes where actual time is much more expensive than predicted/CAM time.

[christinandavid]

Let us know how you get on...

Note, that 'automatic operation time' #3002 may still be counting time when machine is 'waiting' at an M0/M1. That's why I needed to define the extra M-code to capture the time before the stop command. Obviously, if you use the continuous timers it don't matter...

DP