Software release, 13/01/2016

Post Reply
JuKu
Site Admin
Posts: 1110
Joined: Thu Feb 14, 2013 3:06 pm
Location: Tampere, Finland
Contact:

Software release, 13/01/2016

Post by JuKu »

Build date 1/13/2016

New features
* Added "Check now" button for updates
* Better logging: Added color and log for button clicks (helps user support)

Bug fixes
* Sometimes large XY movements were done with slow settings (side effect from previous fix)
* Homing, CNC errors and some other cases now invalidate measurements
* More robust camera startup, false starts are eliminated ("Keep active" mode is now recommended)
* Video measurement does not hang if camera is not running
* Brought back "Disable log" feature (better performance on some systems)

Comments:
It is a good thing to have a system where the software fails reliably. That allows to fix bugs. What is not so nice is that in this case, a couple of these systems have been customers'. :-(

More robust camera start is contributed by a customer. Many thanks! This was one of those "why didn't I think of that" cases, I should have seen the trick myself. The "Keep active" camera mode is now highly recommended and should be usable on all systems. If not, I'd like to hear from you.

I am starting to share thereza's view for GitHub. I use two computers, and somehow, managed to loose the "Disable log" feature.
mrandt
Posts: 407
Joined: Mon Apr 27, 2015 10:56 am
Location: Stuttgart, Germany

Re: Software release, 13/01/2016

Post by mrandt »

Hello Juha and happy new year (still)!

Thanks for the update and the bug fixes.

I have to play git's advocate again - don't blame the system for user error :-P

Most likely you either did not sync with remote on one of the computers or you issued checkout command instead of pull... Happened to me before but we learn best from our mistakes, don't we?

By the way - the best git tutorial I have found so far is this one which I have stumbled across recently. Especially the graphs they use to illustrate the concepts are simple but brilliantly helpful:
https://www.atlassian.com/git/tutorials/

The collaboration features of git bring me to another concern: I believe we are not leveraging the power of collaboration as good we could.

Several forks of the LitePlacer software which people work on independently have emerged. Some are publicly available on git, others are distributed among people's private computers and some are available as ZIP-files linked to somewhere in the depths of this forum.

I think it is absolutely great that people are devoting their time and skills to make LitePlacer better. There is also nothing wrong with adjusting the software for your personal needs.

I only wished there was more convergence in the end!

If somebody implents a nice feature or architecture change, why not put the changes into a nice and small (!) commit, issue a pull request and ask Juha to merge it back to his trunk version?

So far I have seen the opposite happening - the code seems to diverge more and more with every change; to the point were it becomes incompatible to the base version, thus making it almost impossible for Juha to merge back.

As a result, any LitePlacer user now has to make a choice between many flavours of more or less the same software, each version with their own advantages and tradeoffs:

Juha's seems to be the most stable but lacks some features which thereza's mod (now more or less taken over by knas) already have. Thereza added a lot of auto calibration, CV stuff and pressure sensor support and knas is currently eliminating many of the bugs in that version. So even in that branch, we also have to choose between original "ver-2" and Karl's additions.

I know that some people went off to work on improving UI / UX and internal architecture which leads to major refactoring. However, any feature added to ver-2 or main branch in the meantime will not be included in that new version unless manually incroporated either.

I think one of the causes is that we have no clear and public roadmap for the software. Why not have a list of desirable features and ask users to vote which should get highest priority? Or Juha just sets priorities. Either way people could better help if they knew the common goal and tasks at hand.

Maybe I am too much of an idealist - but I truly believe that 3-5 individuals working togehter and on the same piece of code can and will achieve more than each individual working disconnectedly on their own piece of software!
Knas
Posts: 53
Joined: Thu Jul 16, 2015 3:07 am

Re: Software release, 13/01/2016

Post by Knas »

mrandt wrote: I think it is absolutely great that people are devoting their time and skills to make LitePlacer better. There is also nothing wrong with adjusting the software for your personal needs.

I only wished there was more convergence in the end!

If somebody implents a nice feature or architecture change, why not put the changes into a nice and small (!) commit, issue a pull request and ask Juha to merge it back to his trunk version?

So far I have seen the opposite happening - the code seems to diverge more and more with every change; to the point were it becomes incompatible to the base version, thus making it almost impossible for Juha to merge back.

As a result, any LitePlacer user now has to make a choice between many flavours of more or less the same software, each version with their own advantages and tradeoffs:

Juha's seems to be the most stable but lacks some features which thereza's mod (now more or less taken over by knas) already have. Thereza added a lot of auto calibration, CV stuff and pressure sensor support and knas is currently eliminating many of the bugs in that version. So even in that branch, we also have to choose between original "ver-2" and Karl's additions.
I totally agree. At the time i started on Rezas version because i found it to be more stable, but that was many, many months ago and i haven't looked at Juhas original since.

I will check the original software out and see if i can slowly introduce some of the features i've added to Rezas version, most of the major additions i've done are class-based so it shouldn't be too hard i think.

I might still use Rezas version as a "prooving ground" for new features though. Again when i started on that piece i had never been part of an open source project before so i did far too many updates and too few commits, i also know the inline commenting is lacking so i'll fix that before i do any updates too.

Karl
mrandt
Posts: 407
Joined: Mon Apr 27, 2015 10:56 am
Location: Stuttgart, Germany

Re: Software release, 13/01/2016

Post by mrandt »

Knas wrote:I will check the original software out and see if i can slowly introduce some of the features i've added to Rezas version, most of the major additions i've done are class-based so it shouldn't be too hard i think.
Karl, that would be absolutely great :D
Post Reply