Ladder99 / fanuc-driver

Configurable Fanuc Focas data collector and post processor.
Apache License 2.0
74 stars 25 forks source link

Configure what should be gathered in `config.yml` #8

Closed tukusejssirs closed 2 years ago

tukusejssirs commented 3 years ago

As I understand it, the collectors are used to defined what should be gathered on a particular machine, however, this is not very user-friendly. Even if the user of fanuc-driver is a C# programmer, they might not necessarily know the code of fanuc-driver.

I suggest that there should be only one collector which should have the potential to collect all available information from machines (of course, by all I mean all that is fanuc-driver capable to gather ATM). Then the user should be able to configure (in config.yml) what information should be gathered. We might have some data groups (like alarms, production, status, metadata, …) to minimise the configuration size, but also let the user to gather any individual information.

It might be also a good idea to let the user collect some specific parameters using rdparam. These parameters (numbers) and their user-configurable name should be also configurable in config.yml.

MRIIOT commented 3 years ago

I understand what you are asking and I disagree. The reason will become evident when you are trying to collect data from a wide range of controller models. So just wait...

I might have a better solution by leveraging Lua.

fanuc/collectors/NLuaRunner.cs

tukusejssirs commented 3 years ago

I might have a better solution by leveraging Lua.

I’m awaiting an explanation on that, i.e. how does it, why it better, etc. Take your time ofc. :wink:

MRIIOT commented 3 years ago

We'll come back to this and I will show you when I see it, but what I have seen is that static configurations can get out of control and start polluting the codebase.

I would rather document the available Focas calls and the approach and give users the flexibility to add or remove calls for the data they need as an embedded Lua script without recompiling. So kind of a configuration but more of a live configuration through script.

MRIIOT commented 3 years ago

Look at cnc_rdsyssoft, cnc_rdsyssoft2, cnc_rdsyssoft3. And look at which model supports which function. We could build intelligence into selecting which one is called based on the return value of cnc_sysinfo.

{
  "observation": {
    "time": 1624154806926,
    "machine": "sim_lua",
    "type": "source",
    "name": "sys_info",
    "marker": {
      "path_no": 1
    }
  },
  "source": {
    "method": "cnc_sysinfo",
    "invocationMs": 0,
    "data": {}
  },
  "state": {
    "time": "00:00:01.9078127",
    "data": {
      "loader_control": false,
      "i_series": true,
      "compound_machining": false,
      "transfer_line": false,
      "model": "MODEL D",
      "max_axis": 32,
      "cnc_type": "Series 0i",
      "mt_type": "Machining center",
      "series": "D4F1",
      "version": "30.0",
      "axes": 3
    }
  }
}
MRIIOT commented 2 years ago

I suggest that there should be only one collector which should have the potential to collect all available information from machines (of course, by all I mean all that is fanuc-driver capable to gather ATM). Then the user should be able to configure (in config.yml) what information should be gathered. We might have some data groups (like alarms, production, status, metadata, …) to minimise the configuration size, but also let the user to gather any individual information.

The new strategy type supports individual collectors to be added/removed.

https://github.com/Ladder99/fanuc-driver/blob/f9cb5bc9273e10613f940cd6e2e895ee45c56991/fanuc/config-example.yml#L19-L30

tukusejssirs commented 2 years ago

@MRIIOT, I think this issue is resolved in develop.