Could you publish `fanuc-driver` on nuget.org?

[tukusejssirs]

It might be a good idea to publish fanuc-driver on nuget.org for easier installation.

At the same time, you might want to create GitHub Releases too. :wink:

[MRIIOT]

Would I be versioning the entire codebase?

[tukusejssirs]

Well, I’d version fanuc-driver itself.

However, now that I think about it, IMHO you created collectors/strategies/vendors/handlers (or at least some of them) as they could/should be configurable by fanuc-driver user. If that is the case, fanuc-driver they should be removed from the codebase.

Actually, even nlog.xml and config.yml should not be in the codebase (examples could be there, e.g. in an example/ folder or with .example extension).

I suggest to publish it on nuget.org so that we could simply install it without manually building it (unless we want to modify some code). Versioning would help us install a specific version (or even latest stable, dev, rc).

As I see it, fanuc-driver is an adaptor (it adapts all the different FOCAS libraries, as well as makes them working even on platforms not supported by Fanuc) and a microservice (it gathers, processes and provides some data from machines). Maybe the code should be split; although you already have base-driver, however I think the code should be split as follows:

• fanuc-adaptor:
  • it could include current base-driver, all FOCAS libraries;
  • it would provide low-level stuff like get machine data and small amount of pre-processing (like transforming array of letters into a single string);
  • think of this adaptor like a database driver;
• a microservice:
  • it would use fanuc-adaptor;
  • it would include current higher level processors (veneers and strategies?), run sweeps, process the data more intensively (like diffing two consequent sweeps), puplish the data via MQTT;
  • I think that the entire configuration (like what should be gathered and/or published) should be outside of it, so that the user could change it either using a config file or runtime using a CLI command or using some kind of API call (or publishing a particular topic with a specifically structured message);
  • think of this like an ORM.

Note that is how I’d like fanuc-driver to work. It does not talk about the implementation. You can dismissed it at will.

[MRIIOT]

I agree on all of the above.

[tukusejssirs]

Even MQTT should be removed from the adapter.

It should be used as an external library/package, but IMHO it should be utilised by the microservice (not fanuc-adaptor).

[MRIIOT]

Even MQTT should be removed from the adapter.

It should be used as an external library/package, but IMHO it should be utilised by the microservice (not fanuc-adaptor).

I was thinking about the different consumers of the data. Some people will want it in SQL, some will want an HTTP endpoint, some will want something else. I think MQTT, although external to the adapter, should be the primary mode of transmission of the data from fanuc-driver to another process.... unless a pattern is defined for 'output plugins'.

I reviewed the concepts of base-driver across the FactoryIO and OPCXMLDA drivers.

https://docs.ladder99.com/en/drivers/base-driver

I guess I meant for the handler to maintain the connection to an external system.

Even looking at the latest ThreeWay handler... it is the final touch point for the collected and transformed data. The handler is when Focas data leaves the driver.

https://github.com/Ladder99/fanuc-driver/blob/main/fanuc/handlers/ThreeWay.cs

So maybe the MQTT configuration should be moved the handler section in YML like here.

https://github.com/Ladder99/opcxmlda-driver/blob/8c13187a2e6ee4ef904f462e876a3c73dc1a0b24/opcxmlda/config.yml#L66-L79

This way, dependency on MQTT would be removed from the driver.

[MRIIOT]

Even MQTT should be removed from the adapter.

It should be used as an external library/package, but IMHO it should be utilised by the microservice (not fanuc-adaptor).

https://github.com/Ladder99/fanuc-driver/commit/b9679448a203f04f216bee73058bc99a3cbb6777

[MRIIOT]

• it could include current base-driver, all FOCAS libraries;

https://www.lostindetails.com/articles/Native-Bindings-in-CSharp https://stackoverflow.com/questions/66669315/is-there-an-equivalent-of-adddlldirectory-in-linux-and-mac

I was looking at moving the Focas DLLs to a subfolder. Will need to test adding a search path on Linux.