[yaji63]

Hi,

I' am trying to automate monitoring functions on my Fanuc0iMD based VMC and right now I' am using common variables starting from #610 (incrementing from here) to enter the clock value before a program starts and then entering clock value into #611 when the program ends. I'am incrementing the start and end time variables by 2 (Eg.#610, #612, #614 etc).

Right now the user has to be manually note down the values in these variables before another component starts failing which the values will get overwritten as same variables are used with every new component. Is there a way (Other than Dprint into RS232) to output the common variable values into a program as text values so that it can downloaded from the controller at some later stage ? I use ethernet to transfer the programs into Data server and hence RS232 is not connected on my machine.

Cheers

[skm]

I do not think there is a way.
Fanuc controls treat each program space as inviolate, so you cannot write to other programs in the control.
And to write to within the same program would be to create self modifying code, which is not able to be done (works great in lisp on a computer, however) on a fanuc control.
The only things that I know you can modify are variables and using Dprint to send to a serial port.

A similar case is a probing program, the only way is to hook a computer to the serial port and send the coordinates from probing to that port.

The best you could do is save to a bunch of variables, one after the other, and batch-send them with Dprint. You said monitoring, so that is probably not helpful.

I don't know what you are monitoring--just if the machine is done? or which too it is on? Maybe something as simple as either an ethernet-camera pointed at the control, or a cheap EEEP netbook with a web cam, run VNC on it and login remotely to operate the webcam on another computer on your network (or from home).
Just an idea.

[yaji63]

I do not think there is a way.
Fanuc controls treat each program space as inviolate, so you cannot write to other programs in the control.
And to write to within the same program would be to create self modifying code, which is not able to be done (works great in lisp on a computer, however) on a fanuc control.
The only things that I know you can modify are variables and using Dprint to send to a serial port.

A similar case is a probing program, the only way is to hook a computer to the serial port and send the coordinates from probing to that port.

The best you could do is save to a bunch of variables, one after the other, and batch-send them with Dprint. You said monitoring, so that is probably not helpful.

I don't know what you are monitoring--just if the machine is done? or which too it is on? Maybe something as simple as either an ethernet-camera pointed at the control, or a cheap EEEP netbook with a web cam, run VNC on it and login remotely to operate the webcam on another computer on your network (or from home).
Just an idea.

By monitoring i mean keeping track of the actual cycle time for each component to understand where things are getting delayed. In a batch production scenario (where even as small numbers as 3 Qty is machined) i have observed that the cycle time varies from component to component which is invariably operator lethargy of some kind of fiddling around by the operator. If i can have the data for each component then i can ask the operator the reason for variation on time for a proven component.

[christinandavid]

Best method I could come up with was to dump the info into the tool table and punch it to dservr from there. Do the same with probe results. Works well. I went as far as storing each N sequence time, each tool cutting time, aux function times, time spent reworking, unknown time, efficiency, and to save variables I stored last forty cycles in format hhmmhhmmss.pp meaning cycle finish time, cycle time and cycle efficiency in one variable. You might say I have too much time on my hands....

DP

[dpuch]

It sucks you apparently can't just output dprnt via ethernet to a file, but you should be able to punch out your offset tables (tool or macro #'s) the same way you save programs to your file server.