Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could you publish fanuc-driver on nuget.org? #40

Open
tukusejssirs opened this issue Oct 30, 2021 · 7 comments
Open

Could you publish fanuc-driver on nuget.org? #40

tukusejssirs opened this issue Oct 30, 2021 · 7 comments

Comments

@tukusejssirs
Copy link
Contributor

tukusejssirs commented Oct 30, 2021

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. 馃槈

@MRIIOT
Copy link
Contributor

MRIIOT commented Feb 1, 2022

Would I be versioning the entire codebase?

@tukusejssirs
Copy link
Contributor Author

Well, I鈥檇 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鈥檇 like fanuc-driver to work. It does not talk about the implementation. You can dismissed it at will.

@MRIIOT
Copy link
Contributor

MRIIOT commented Feb 1, 2022

I agree on all of the above.

@tukusejssirs
Copy link
Contributor Author

tukusejssirs commented Feb 1, 2022

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
Copy link
Contributor

MRIIOT commented Feb 2, 2022

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
Copy link
Contributor

MRIIOT commented Feb 8, 2022

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).

b967944

@MRIIOT
Copy link
Contributor

MRIIOT commented Feb 11, 2022

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants