Closed tukusejssirs closed 2 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
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:
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.
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
}
}
}
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 (inconfig.yml
) what information should be gathered. We might have some data groups (likealarms
,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.
@MRIIOT, I think this issue is resolved in develop
.
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 offanuc-driver
is a C# programmer, they might not necessarily know the code offanuc-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 (inconfig.yml
) what information should be gathered. We might have some data groups (likealarms
,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 inconfig.yml
.