Code Contributions to the software

[mrandt]

I have tested release 7 (from Reeza's SVN) and just updated to release 9 - will test again.

First of all let me say that, without any intention to diminish Juha's excellent pioneer work, Reeza has significantly enhanced and improved both the functionality and UI in my opinion! Thank you very much, your work will make the machine even more useful to me. I do appreciate your hard work and can only admire your programming skills and devotion

During my tests, I took note of potential bugs, issues, suggestions to further improve etc - naturally there are quite a few.

How should we track feedback, bugs and feature requests for LitePlacer RMod?

I think it would make sense to put the current codebase into another major version or even a separate repository, given the amount of code and architectural changes.

If Juha created a new github repository for it, we could easily use issue tracker to record issues and feature requests - but I would also be fine with a Google docs spreadsheet or any other bugtracker, as long as it works and is accepted by everyone involved in the programming.

I think more important than format is ownership and management of said list - I suggest that Juha be one to do that as ultimately LitePlacer is his project and he also has a commercial relation to users who are customers.

Juha, Reeza - please let me know what you think works best and I will put down my findings in a structured way.

Thanks!

[mawa]

As we have see,n GitHub is not therezas favorite version mananger.

Thereza has established a well functioning SubVersion site.

And I must admit I am using SVN since many years and "enjoy" the VS extension.

So why not stay on his SVN site for his version and stay on GitHub for Juhus Version?

We need to find a way to "simulate" pull requests with thereza if anybody wants to contribute to therezas version.

These pull requests are IMHO the charm of using Github because the "master" decides what he wants to merge and what not. SVN is an kind of "hot" add an replace of all commited file content. That can lead to some heavy side effects.

BTW: format and braces.... With the help of the great VS "AStyle Extension" everybody can reformat the source code to his individual taste. The guy who wrote that extension did a real good work and brought together almost all variants you can think of. All with a single click. Well not the whole project but at least a whole document.

[JuKu]

"Reeza has significantly enhanced and improved both the functionality and UI in my opinion! Thank you very much, your work will make the machine even more useful"

Let me second that; I wholeheartedly agree, Reza's version is better. I am really thankful for it.

About Malte's points:

Ownership: On one hand, it kind of makes sense to have me as the code owner. Reza is at least for now much more active on the development and it will take me a while to be familiar with the new code, so it makes sense also to have Reza as the owner. I haven't looked, but it should be possible to set a repository so, that more than one person can accept merge requests and make commits to the public branch.

Where, under what version control: I don't really care. Reza's chosen place and SVN is fine for me, Github and Git is also ok for me, but Reza hates it (and that is reason enough to look for something else). It should be cheap*, reliable and something that it is ok to link from the website to. *Cheap: Imo, it is ok for team members (people who own the code and can do merges etc) to need an account on a paid site, as long as it is free to fork and submit contributions. It is not ok to need an account on a paid site to get a copy of the code or submit fixes.

Code organization: Yes, this should be separate. I'm ok to call this LitePlacer v2 (or whatever) and archive the current as v1. Also, we should have a release and dev branches or repos, at least once the RMod is considered release worthy. (Imo, already there or very, very close).

Bug tracking: Again, whatever works. This will not be that big project, so a spreadsheet or anything above that has enough capabilities. The function is important: Someone finds an issue, it should be easy to make a note of it in a way that it is not forgotten. (I will get into Github issue list! Soon.) Assembla seems to need an paid account to be able to submit a bug report. That doesn't really work: Submitting reports must be free and ideally, not requiring an account anywhere, just fill a form. (I just looked, and Bluehost (that hosts liteplacer.com) supports Mantis, which has anonymous issue reporting.)

I guess I'm not very helpful, as I don't rally suggest anything. On the other hand, I'm not much against anything either.

[mrandt]

Manfred, let's please not go into a battle about SVN vs. GitHub vs. everyones favourite tools. The first two in my list were designed with different goals and for different circumstances. GitHub has always been intended for distributed, diverse teams who clone, fork and branch code a lot and only merge back selectively - if at all. This fits the nature of many open source projects and this is what git is good at. I also like the simplicity of SVN (or CVS prior too that), but once you use it with a larger team it requires much more discipline and control. I also used many other versioning and revision control systems - IBM CMVC, Rational Clear Case, Synergy, Team Concert and many proprietary ones - each had pros and cons.

I don't mind to keep the code in SVN or whatever versioning control works for Reeza, Juha and others - as long as the people using LitePlacer can obtain a copy and contribute if they like to and have the ability

My post was more about finding a way to document and track bugs, suggestions and ehancement requests, etc. for Reeza's version. I started to make a list and take notes during testing but would like to use some structured approach so my efforts are not wasted and contributions can be coordinated.

I think that posting all bugs and potential enhancements here in the forum will become a nightmare in terms of managing, tracking and updating.

Juha already uses GitHub Issue Tracker for the base version:
https://github.com/jkuusama/LitePlacer/issues

Thus my suggestion to simply create a secondary repo - does not need to contain the sources - and track issues there.

I am open to other suggestions, be it BugZilla, Trac, Jira or just a Google Docs Spreadsheet we all have access to. To me it is more important that contributors (so far Reeza and Juha for most part) happily accept the tool than which one it is.

[thereza]

woah, a burst of unexpected activity on the forums.

thanks for the complements on the code. my main goal was to make it functional for me (by adding code to detect arbitrary fiducials) then it became a slippery slope where i ended up rewriting the bulk of it. but with the current code, it's easy to add all sorts of things -- i just added code where it will search the entire tape and figure out which components are there and which are not - took about 15 lines to implement.

the code is also a huge departure from JuKu's style - and the way certain things are done is not fully consistent across the code as I came up with better ways and never went back to change all the code. I want to maintain control of the 'API' of the code until time that it's sufficiently consistent throughout the codebase. For example, I want to have an API for accessing objects from tables - that's not consistent currently.

That being said, I think it's logical if JuKu & I manage control of the repository. I was fine trying git, but when the sync stopped working, that was the final straw and I gave up. I'm hosting the files here - https://www.assembla.com/code/liteplace ... sion/nodes - which seems to have some git like functionality (i.e. merge requests). Can someone with more experience with this stuff look to see how well that would work for code submissions? I'm fine using whatever for bug tracking.

And for the record (as it's all over the place) my name is 'Reza'

Once some of the more egregious bugs are sorted, I'll break it out into a prod. and devel. version.

Also - is anyone opposed to my getting rid of the box size inputs for the mm per pixel scaling? the auto calibrate works great for me.

Reza

[JuKu]

> is anyone opposed to my getting rid of the box size inputs for the mm per pixel scaling? the auto calibrate works great for me.

If the autocalibrate does not work, then there is no workaround. On the other hand, then the system has other major problems anyway...

[JuKu]

> I'm not a fan of methodselectionform. thinking of just making it a combobox instead in the job table.

The form is kind of rude at the moment. Still, it does allow for setting method for several rows at the time. I was thinking that it might grow to something more that does require a form, and it still might; we might at some point separate the pick and place operations and have separate methods for both. Using the form is as easy as a combobox anyway (in terms of mouse clicks), so we might want to keep the option of being able to add more controls or parameters to each method. For this, a form is the way to do it.

Btw, I was using strings mostly because it make early stages of development so easy, as I cold see on the fly the numbers and other data. In that angle, I was thinking that a string as a method parameter might grow to something more than just the tape ID. So far, it hasn't, and Reza's table access method is better anyway.

[thereza]

>
The form is kind of rude at the moment. Still, it does allow for setting method for several rows at the time. I was thinking that it might grow to something more that does require a form, and it still might; we might at some point separate the pick and place operations and have separate methods for both. Using the form is as easy as a combobox anyway (in terms of mouse clicks), so we might want to keep the option of being able to add more controls or parameters to each method. For this, a form is the way to do it.

My biggest issue is I accidentally click on the field and bring up that form all the time when I don't mean to . A combobox would make that not a problem. If there are more than one type of pick and place operation, then we should be able to distinguish them in the combox and we can bring up the relevant form when they click on the methodparameters cell when the combobox is set to a specific value. I also want to change it so that it goes from place to placed when it is placed - and an option to reset them back - that way it's easier to keep track of what you placed if you're doing it incrementally.

To support multi-selection you can just detect a change to the combobox and apply the change to all selected cells. Shouldn't be too hard to implement. The other thing I added was a crude way to auto match components with tape IDs assuming that there is some text that overlaps between them. It's faster than selecting them one at a time.

Have you had a chance to look over the architecture changes? Anything you don't like or would want changed?

I've noticed a strange issue - when I first start the app, the gantry starts moving really slowly. If I issue a move command, it stops and works normally. What commands are issued on startup which could cause that?

Reza

[JuKu]

> I also want to change it so that it goes from place to placed when it is placed

Good idea, and makes much more sense in a combobox. that allows you also save a partially done job.

> Have you had a chance to look over the architecture changes? Anything you don't like or would want changed?

Yes, to some extent. So far, I like what I'm seeing.

> when I first start the app, the gantry starts moving really slowly.

I haven't seen that, but I'm not running Rmod currently. As far as I can tell, nothing in the startup phase should cause a move. The startup reads in the axis settings and status, but does not issues any moves. Just in case, could you send me the log of your startup?

Juha

[mrandt]

Sorry, Reza for incorrectly spelling your name - I promise to read and type more carefully going forward

Juha, could you just create a new repository on GitHub - LitePlacerV2 or something like that? I would then start immediately to record bugs and enhancement suggestions on the new repo's issue list.

You could use labels to mark issues accordingly as bugs or enhancements, assign them to people to work on if desired and add a milestone for a first release of the new and improved "Reza" version.

We could all use the issues-list feature without using the code versioning on git - or maybe put the code there from time to time as an archive as long as we continue to use SVN for development.

Would that work for you and Reza?

Regarding the recent feature discussion:

- I like the idea of changing the job table to be less modal, so thumbs up for dropdown / combo instead of popup. The idea of introducing a "placed" state IMHO is also a good one. On a side note, if you currently hit "Place all" on an unconfigured job, you cannot tell to which line the modal dialog corresponds. So we either fix that as well or do away with running "place all" for incompletely configured jobs - i.e. you have to select somtehing for each line before the button is enabled.

- I would like to keep the box size iputs (mm / pixels). Auto calibration works great most of the times, but there are occasions when I need to put in values manually:
1. on first start of software the default value (20mm) leads to an overshoot of the optical homing mark which is so large that cam can never home in. I have to set something between 5 and 10 mm but that will differ per camera and lense used and it's distance from table.
2. in case auto calib fails (optical mark detection not working, machine in wrong position, etc.) it sets 0 for the ratio and to rerun auto calib I need to set another value
3. I like the feedback of seeing the measured values - especially if I run auto calib repeatedly.

So long and thanks again
Malte