[fujisan]

Hi all,

I'm new to FANUC macro programming and wondered wether it is possible to keep a macro running in the background, whilst other NC code is being executed?
What comes closest for me, is to call the macro at every speed changing command, but it's still not exactly what I need.

Does any one know, wether the C language executor can do that? I haven't found a lot of information about it, so I'm not sure what the differences are except using another language.

Thanks a lot for your help!!

[sinha_nsit]

Macro calculations do continue in advance while the preceding NC statement is being executed.

[christinandavid]

Look up info on 'realtime' macro commands, they may suffice - sorry, never used them myself...everytime I try to get my head around them all the Zs make me feel tired :tired:

DP

[fujisan]

what are real-time commands? i have the book fanuc cnc custrom macros from peter smid. it has got a few years on its back, so i'm not sure wether it's too old, but i can't find any info in it.

are there any good resources on fanuc macro programming? because also on the net, i couldn't find any.

[christinandavid]

From what I can gather you can use them to interrupt current cycle when a condition is met (don't ask me what the typical use is, but from the examples my guess is probing). The format seems to involve a //Z before the normal phrases, with a distinct notation for the RTM variables used.

Hopefully, someone else can chip in who has actually used them...I don't know how extensively they are used, I only know they are mentioned in my 31i manual.

DP

[psychomill]

It might help for us to know ..... What do you need the macro to run while code is running? What is the macro tracking?

[MysticMonkey]

Can you use the while command and program a while for each condition you might need in a program?

[fujisan]

i want to monitor values as servo/spindle speed, position, load etc. and create a history of the machines usage.

G66 is not that bad, because it can call the macro at every axis moving command, but still it requires each program to include the command to have all data of the machines history

[psychomill]

What machine is this? You would be far better off to look into Data Collection software. This type of software can pull such data from the machine every second it is running or not running and create graphs, history, charts... whatever you want. This is commonly used for what we call OEE.
Then you don't need to write any macros or use up variable to store the data or have to print it out constantly.

Some machine controls monitor this anyway so it's just a matter of you setting up the outputs accordingly.

[fujisan]

thanks for the reply.

its not for a factory machine, but for a research machine. i guess that such a data collection software costs money, right? or is there one freely available?

it would be nice to monitor all data, but its not necessary to save everything. i only need to store a few variables (<10) so it shouldn't be too much of a problem.

[BobWarfield]

fujisan, not clear you can monitor everything you want in g-code, but let's assume you can. In other words, if you go through the programming manual for your machine's controller, everything you want to see is accessible either directly (e.g. you know the spindle speed is 6000 rpm because you executed an "S6000") or indirectly via a # system variable.

If you controller has a means of monitoring these variables directly, great. OTOH, a lot of data collection is done using a DPRNT statement in the g-code. You see this for monitoring cycle times or for tool life management, for example.

DPRNT just writes out whatever you want it to via the serial port. You use DNC software that has the ability to collect this information to gather it into a file. You can then analyze the file using Excel, a Basic program, or whatever tool is most convenient.

For example, let's say you want to monitor which programs ran, which tools in the changer where accessed, how long each was accessed, and at what feeds and speeds the tool ran. You can get all that by instrumenting the "O", "S", "F", and "T" words.

What I mean by instrumenting, is you'd go through the g-code and for each of those words you'd add a DPRNT that sends the value out the serial port.

This is not too hard to do with search and replace (well, you'd better have regular expression capability!). But, some g-code editors can do it too. For example, G-Wizard has a "Monitor Revision" that lets you add a particular string to the g-code after a particular word, or a particular word followed by a particular address.

The output might look something like this:

Program O0100
Spindle S6000
Feed F110
Tool T12
...
etc.

Hopefully you can get a timestamp on those entries or output one as part of the DPRNT.

So, that's another way to go about it. Several of the machine data collection software programs are based on this kind of approach.

Best,

BW

[stevo1]

This is commonly used for what we call OEE.

Wow.....you don't hear that very often. Operating Equipment Efficiency. We got a new CI guy a few years ago and have been doing this for some time. It is hard to really use the data as the standards for most jobs are not that accurate.

We looked at software like this thru a company called Enet DNC and it was not cheap. I don't know what is out there but this required some additional hardware in the machines.

Stevo

[fujisan]

BobWarfield, that's about what I'm trying to achieve. I hope that I can read the data from machine parameters. I think it should be possible to achieve the data.

What's bothering me though is that, as I'm not the operator of the machine, how to make sure that really every part program that is run, is monitored e.g. when I want to check tool life. I would have to rely that the operator starts the macro in every part program. As this is not always possible, I want to automatically have it running at all times in the background.

[psychomill]

OEE software does cost money... really good ones cost more. You can get DEMO versions or even speak with some DNC companies to set up a test machine and you will see how powerful and/or useful for you. The amount of hardware you need is dependant on what the control monitors and has I/Os for to begin. Certain controls like Haas's newest control, Mazak Matrix, FANUC 3 series and such are already set up for data collection. The hardware needed is very limited to maybe an interface but even then, the USBs or ethernets already exist. Older machines need additional hardware depending on what types of data you want to collect (requiring external PLCs).

Being that you're looking for a "free one", I'd say that a data collection system is probably not within your "budget". Doing this yourself is possible but will still require a little bit of money, PLC programming and hardware set up, some software set up and writing for the collected data.

With that said, as a couple have posted here, yes you can grab some data using macros. What you can read will be limited to the controls system outputs to begin with. The problem you're going to run into is the frequency you want to collect this data. You can't grab this data "at every move". If you were to try, you would tax your control so bad your operations would slow down considerably. Even if the control did handle this, the macro would be so fast you will likely miss a lot of inputs and outputs even though it's programmed. This forces you to slow down the macro which in turn also slows down your control and programs.

So if you do choose to create a macro to capture data, do so sparingly. Trying to capture "every moment" will be trouble. There's a number of ways to capture data and a couple have been posted. It doesn't have to be with While/Do loops but it you're capturing the same data all the time, a seperate program is a good idea and you can simply set up a custom G or M code for it. G66 or 66.1 will also tax your machine for this application. Lastly, you may need to consider data points anyway if you're running macros for other reasons in a part program and many machines, run certain system related macros that may cause disruption.


Stevo,
You don't have to be "that good" for data collection. Properly set up OEE will inherently get you to be "that good". The more you set up the base system and code to remove the human intervention, the simpler this gets. Then all you're doing is improving your throughput by working with the compiled data.

Additional note: As MT Connect gains more acceptance through the MFG Industries and associated OEMs, this would also be another avenue for OEE accessibility and a host of other benefits.