MTConnect – FANUC Macro Variables

Updating the FANUC Adpater for Stable Macro Variables

The current edition of the FANUC MTConnect adapter as of this writing was unstable on my platform.  Any time a macro variable was entered in the adapter.ini file, the adapter crashed shortly after connection.  This seems to be related to threading and access to the datum.  To rectify this I rewrote the getMacros() function of fanuc_adapater.  It no longer supports the multipath macro’s and is less efficient, however it works consistently without any errors.  Additionally, I was feeling lazy and included the <math.h> header to properly calculate the decimal point in the variable.

fanuc_adapter.cpp,  rewritten getMacros():

#include <math.h>
 void FanucAdapter::getMacros()
 {
    if (!mConnected)
    return;
    for (int i = 0; i < mMacroSampleCount; i++)
    {
       ODBM macro;
       short ret = cnc_rdmacro(mFlibhndl, mMacroSample[i]->getNumber(), sizeof(ODBM), &macro);
       if (ret == EW_OK)
       {
          double rational = macro.mcr_val;
          double decimal = macro.dec_val;
          double exp = pow( 10, decimal );
          double resultant = rational / exp;
          mMacroSample[i]->setValue(resultant);
       }
       else
       {
          printf("Could not retrieve PMC data at %d for %s: %d\n", mMacroSample[i], mMacroSample[i]->getNumber(), ret);
       }
    }
}

Now if we put a macro variable in the adapter.ini file as such:

adapter.ini

[adapter]
port = 7878
service = MTC Focus 1
 
[focus]
host = 192.168.82.15
 
[macros]
whale = 500
cabbage = 501
 
[pmc]
SspeedOvr = 30
Fovr = 12

the adapter will correctly pass on the named macro variables:

http://adapter.ip.address:7878/

2014-07-14T17:04:00.057Z|avail|AVAILABLE|part_count|7|whale|1.23456789|cabbage|2|SspeedOvr|0|Fovr|0|turkey|0|tool_id|0|program|3.0|line|0|block|O0000%|path_feedrate|0|path_position|0.0000000000 0.0000000000 0.0000000000|active_axes|X Y Z|mode|MANUAL_DATA_INPUT

2014-07-14T17:04:00.057Z|servo|NORMAL||||

2014-07-14T17:04:00.057Z|comms|NORMAL||||

2014-07-14T17:04:00.057Z|logic|FAULT|100|||PARAMETER ENABLE SWITCH ON
2014-07-14T17:04:00.057Z|motion|NORMAL||||

Which matches our FANUC FS0iD control:

macro screen

Cool Eh?  Macro variables are a critical part of any modern CNC shop, and being able to read them via MTConnect opens tremendous possibilities.  Custom parts counts can be made, operation conditions can be read,  etc.  The possibilities are endless.

6 thoughts on “MTConnect – FANUC Macro Variables”

  1. Hello.
    Good to see these posts interesting.

    Could I ask something?
    Do you happen to try to input some value system variables.

    I’m trying input some value in #3000 to create alarm by Focas but it doesn’t happen.
    I could put some vaule #3001, #3002 but in case of #3000… failed.

    Do you know the solution?

    1. Hi Donny,

      Unfortunately, you won’t be able to cause a macro alarm by writing system variable #3000. Only an executing part program can do this… instead, you will need to “flag” the alarm. For example, Write macro variable #500=1 using FOCAS and then periodically check in your program if this is equal to 1. IF (#500EQ1) GOTO 20; N20 #3000=1 (My Alarm);

      Generally speaking, you don’t want loosely coupled computing devices causing alarms on your CNC… I would look at having your alarm process be more internally driven if possible. If this is a purpose built embedded device, then look at a combination ladder/FOCAS solution with appropriate bypass when needed.

      Best of Luck!!!
      Mike

  2. Hi, thanks for building this website, it has been extremely helpful and I have a working adapter on my 32i-b control now! I now have a new task. I have a machine that runs unattended for days, and we are at risk of creating lots of scrap when a tool goes bad. I have an external system that can monitor the tooling, but I have no way of stopping the machine. The IO is completely used and the machine builder is unhelpful (no ladder changing). Would it be possible to pass a value from an external computer into the macro variable on the CNC control with focas? I would then check that variable in the CNC G-code at each tool change and issue an M0 with an IF statement. So far I have not seen any way to use focas to make a change to the control, only read status.

    Thanks!

    Tom

    1. Hi Tom, Focas is completely open and can write variables and just about anything else. However once you introduce control of a machine, there are many safety considerations. I would strongly recommend working with the builder on a ladder based solution. If that fails, I would recommend an opc based solution to incorporate external automation. Finally, if you are prepared to support a proprietary pc based solution for the next 25 years, you can use cnc_wrmacro2() on this fs32iB to write a macro variable via Focas.

  3. Thanks for your reply, I’m trying to understand the risk involved in using Focas to stop a machine. I would think that loading a number into a Macro variable and checking that variable at each tool change before deciding to continue would not be dangerous. I use Macros all the time in IF statements in G-code. Would I be correct in assuming you’re concerned about the local network reliability? I could see a situation where someone installs a printer and happens to choose the same IP and the agent. Then when our system tries to stop a machine the message does not get through. So the risks I can see are related to network reliability and lost messages. Are there other things I should worry about?

    thanks!

    Tom

    1. Hi Tom, it’s a good question. Surprisingly it has very little to do with network stability. Instead, it has to do with the fact that macro variables can be changed by many sources making it possible to ‘start’ the machine without input from the PC. The other methods are far more robust and loosely standards based giving them an edge over changing a macro. I have used the method you proposed many times… It works great, but there are better, more professional ways in my opinion.

Comments are closed.