Hi guys
Out of interest.... what does the LitePlacer software do that OpenPNP can not do (or vica-versa). Just wondering if anyone is sticking with the LitePlacer software, and if so, why?
I've had a quick look and it appears we've got 8 forks of the LitePlacer sw in github, but they are all up-to-date, so have people got mods that aren't commited?
Matt
OpenPNP vs LitePlacer
Re: OpenPNP vs LitePlacer
I'm currently "Sticking" with Liteplacer software due to my investment in "Learning Curve". At some point, I may look at OpenPNP, when I have some free time.
Why Liteplacer first? Because I wanted to understand the "Factory" offering before moving on.
As an aside, I am sort of curious about the forks of Liteplacer on Github. I have not (yet) looked to see if people just "headed off on their own" or if they were attempting to make a "pullable" improvement.
Summary: New builder, sticking with baseline stuff until I understand a LOT more.
Why Liteplacer first? Because I wanted to understand the "Factory" offering before moving on.
As an aside, I am sort of curious about the forks of Liteplacer on Github. I have not (yet) looked to see if people just "headed off on their own" or if they were attempting to make a "pullable" improvement.
Summary: New builder, sticking with baseline stuff until I understand a LOT more.
Re: OpenPNP vs LitePlacer
Hi Matt,
I guess it's you?!
As you might know, I am an "alpha customer" and built my LitePlacer even before the kits went on sale. Basically, I was involved since T = 0.
I have used both programs and will try to draw a quick comparison.
Features that LitePlacer (and the various forks) have over OpenPNP:
- Nozzle / needle "wobble" calibration and compensation
- Automatic calibration of camera pixel-to-mm ratios
- Automatic calibration of skew (non-squareness of machine)
- Sophisticated, integrated Z-probing and backoff for auto-setup of part heights, pickup and placement Z-levels
- Support for pressure sensor to detect missed picks or parts dropped inflight
- OOTB TinyG support, configuration (of TinyG controller) and debugging
- OOTB support for component trays (multiple feeders combined)
- last & not least: a basic one-stop-shop machine kit sold by Juha
Features that OpenPNP has over LitePlacer:
- Bottom vision and placement correction (!!!)
- Better vision (OpenCV) processing
- Multi-head support
- Support for several feeders
- Clean and modular software architecture + API which allow easier extension
- Multi OS support (Linux or Mac works)
- Active community of contributors who work towards a common branch (with pull requests & merge)
- Strong leadership and direction by Jason
Bottom vision is the killer argument for OpenPNP if one places 0402 or large parts (ICs, BGA, large caps) where a small rotational or displacement error leads to problems.
The biggest pro arguments for LitePlacer are currently the nozzle "wobble" calibration, camera pixel-to-mm calibration and Z-probing.
However, since I have started to use Samsung CP40 nozzles wobble is less of an issue and the other aspects can be "worked around". Bottom vision however is absolutely necessary IMHO.
So I am currently leaning towards OpenPNP; especially since Juha kind of "recommended" it in his latest e-mail newsletter.
Reasons (and background - sorry for the long read):
I don't mean to step onto Juha's turf; he designed and distributes an excellent kit which IMHO advanced the DIY community by quite a bit. I also admire all the work he put into the software which has many neat fetures. So thumbs up for Juha!
However, it's somewhat apparent that he is neither a professional software architect nor an open source evangelist, at least not in the sense of leading a community of developers working on a common software.
Juha is basically fighting all battles on his own and thus the progress is kind of slow. I have documented about 40 issues and feature requests but most of them are still open; some have been dangling on Github for almost a year.
C# is not my cup of tea; so I cannot really help with the coding. Also, I think Juha's architecture and coding style are somewhat unique and not too easy to understand. It seems they do not always follow best practices and design patterns.
Some more experienced devlopers liked to tear the codebase apart and rebuild many aspects. That lead to a situation where all the forks are disjunct and mostly incompatible; there are hardly any pull requests. Talented people here implemented great things, but those never made it back to the main branch
Probable reasons:
- Developers who just did it for themselves and did not care about merging back
- Perfectionism and unwillingness to share potentially incomplete extensions / rewrites
- Disagreement with the tools; some people refused to use / learn git
- Breaking code changes; some changed it to the point were it became completely incompatible with the main branch
- Lack of leadership; Juha is neither publising a roadmap and asking for help with the software nor does he provide guidance / governance
This is all fair and I totally understand Juha's position. He was generous enough to publish his sources and never intended this to be a community effort - so I cannot blame him for not fostering a open source community. Also, he has to support his paying customers so he will not take risks and merge "foreign" code into his branch unless he is 100% sure about the functionality and being able to maintain it.
Observing Jason's OpenPNP in contrast is quite interesting. Jason is actively reaching out for help, provides clear direction and governs the code. 53 merged PRs in his repo vs. 3 in Juha's are an obvious symptom
I think this led to impressive progress and the introduction of many new and cool features lately. If it continues at this rate, I guess OpenPNP will soon also have all the features currently unique to LitePlacer...
Maybe this is also a chance for Juha to focus on the mechanics (improved kits have already been announced) and a "LitePlacer" driver for OpenPNP instead of maintaining both HW +SW? Just my two cents.
TLDR: LitePlacer software has some unique features which OpenPNP does not (yet) have. Still, I intend to use OpenPNP in the future; bottom vision placement correction being the most significant reason, the prospect of significantly faster development progress being an important aspect as well.
Best regards
Malte
I guess it's you?!
As you might know, I am an "alpha customer" and built my LitePlacer even before the kits went on sale. Basically, I was involved since T = 0.
I have used both programs and will try to draw a quick comparison.
Features that LitePlacer (and the various forks) have over OpenPNP:
- Nozzle / needle "wobble" calibration and compensation
- Automatic calibration of camera pixel-to-mm ratios
- Automatic calibration of skew (non-squareness of machine)
- Sophisticated, integrated Z-probing and backoff for auto-setup of part heights, pickup and placement Z-levels
- Support for pressure sensor to detect missed picks or parts dropped inflight
- OOTB TinyG support, configuration (of TinyG controller) and debugging
- OOTB support for component trays (multiple feeders combined)
- last & not least: a basic one-stop-shop machine kit sold by Juha
Features that OpenPNP has over LitePlacer:
- Bottom vision and placement correction (!!!)
- Better vision (OpenCV) processing
- Multi-head support
- Support for several feeders
- Clean and modular software architecture + API which allow easier extension
- Multi OS support (Linux or Mac works)
- Active community of contributors who work towards a common branch (with pull requests & merge)
- Strong leadership and direction by Jason
Bottom vision is the killer argument for OpenPNP if one places 0402 or large parts (ICs, BGA, large caps) where a small rotational or displacement error leads to problems.
The biggest pro arguments for LitePlacer are currently the nozzle "wobble" calibration, camera pixel-to-mm calibration and Z-probing.
However, since I have started to use Samsung CP40 nozzles wobble is less of an issue and the other aspects can be "worked around". Bottom vision however is absolutely necessary IMHO.
So I am currently leaning towards OpenPNP; especially since Juha kind of "recommended" it in his latest e-mail newsletter.
Reasons (and background - sorry for the long read):
I don't mean to step onto Juha's turf; he designed and distributes an excellent kit which IMHO advanced the DIY community by quite a bit. I also admire all the work he put into the software which has many neat fetures. So thumbs up for Juha!
However, it's somewhat apparent that he is neither a professional software architect nor an open source evangelist, at least not in the sense of leading a community of developers working on a common software.
Juha is basically fighting all battles on his own and thus the progress is kind of slow. I have documented about 40 issues and feature requests but most of them are still open; some have been dangling on Github for almost a year.
C# is not my cup of tea; so I cannot really help with the coding. Also, I think Juha's architecture and coding style are somewhat unique and not too easy to understand. It seems they do not always follow best practices and design patterns.
Some more experienced devlopers liked to tear the codebase apart and rebuild many aspects. That lead to a situation where all the forks are disjunct and mostly incompatible; there are hardly any pull requests. Talented people here implemented great things, but those never made it back to the main branch
Probable reasons:
- Developers who just did it for themselves and did not care about merging back
- Perfectionism and unwillingness to share potentially incomplete extensions / rewrites
- Disagreement with the tools; some people refused to use / learn git
- Breaking code changes; some changed it to the point were it became completely incompatible with the main branch
- Lack of leadership; Juha is neither publising a roadmap and asking for help with the software nor does he provide guidance / governance
This is all fair and I totally understand Juha's position. He was generous enough to publish his sources and never intended this to be a community effort - so I cannot blame him for not fostering a open source community. Also, he has to support his paying customers so he will not take risks and merge "foreign" code into his branch unless he is 100% sure about the functionality and being able to maintain it.
Observing Jason's OpenPNP in contrast is quite interesting. Jason is actively reaching out for help, provides clear direction and governs the code. 53 merged PRs in his repo vs. 3 in Juha's are an obvious symptom
I think this led to impressive progress and the introduction of many new and cool features lately. If it continues at this rate, I guess OpenPNP will soon also have all the features currently unique to LitePlacer...
Maybe this is also a chance for Juha to focus on the mechanics (improved kits have already been announced) and a "LitePlacer" driver for OpenPNP instead of maintaining both HW +SW? Just my two cents.
TLDR: LitePlacer software has some unique features which OpenPNP does not (yet) have. Still, I intend to use OpenPNP in the future; bottom vision placement correction being the most significant reason, the prospect of significantly faster development progress being an important aspect as well.
Best regards
Malte
Re: OpenPNP vs LitePlacer
X-post for reference; there is discussion about the same topic over at OpenPNP group:
https://groups.google.com/forum/#!topic ... BR1Z8JNLYg
https://groups.google.com/forum/#!topic ... BR1Z8JNLYg