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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C++ API and Abstract classes #681

Open
abogani opened this issue Apr 10, 2019 · 3 comments
Open

C++ API and Abstract classes #681

abogani opened this issue Apr 10, 2019 · 3 comments
Assignees
Labels

Comments

@abogani
Copy link

abogani commented Apr 10, 2019

Why doesn't UPM use the abstract classes to improve code portability between devices (i.e. for Stepper Motors)? Is it a choice made by design? If yes why?

@Propanu
Copy link
Contributor

Propanu commented Apr 14, 2019

Hi @abogani, and thanks for raising this question. We do include a good number of interfaces to help with portability for sensors of the same type. About 10 of these have been around for quite some time in order to collect developer feedback and determine what's the best way to handle them via SWIG. We have since increased the number to over 30 and now, many UPM sensors implement them. The best part about this is that the new interfaces are useful even with the other languages (Java, JS & Python).

Actuators are a bit more complicated and this is were we continue to ask for developer feedback and help. Let's use the stepper motor as the example. There are 2 popular generic implementations (step and direction or "direct" coil control via gpio). Add to this hundreds of very custom industrial controllers or weird combinations of the generic methods. I could easily say that step and dir functions will make for a good interface for stepper motors, but then you will come in and say speed control is also very important and should be part of the abstraction rather than user code. And this is where it gets challenging, because setting the speed needs utility classes and the implementation will now vary substantially based on the target device, going against what the abstraction was meant to do.

So to summarize, we did abstract a lot of sensors types, but actuators are a different story and we invite the community to take the initiative for them. Hope this helps clarify things but please let us know if you have additional questions or suggestions on this!

@abogani
Copy link
Author

abogani commented Apr 15, 2019

@Propanu Thanks for detailed explanation!

What do you suggest me to do then? Should I propose the code of an asbtract class for stepper motors or should I implement an abstraction layer for that type of actuators at user level code (my application)?

Thanks again!

@Propanu
Copy link
Contributor

Propanu commented Apr 19, 2019

Hi @abogani, sorry for the delay. If you want to open a PR with a new iStepper interface, I will be more than happy to help shape it and get it integrated with the rest of the UPM. With 2 pure virtual functions for step and direction it should be possible to cover most if not all of the steppers in the project.

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

No branches or pull requests

2 participants