LitePlacer.com forums

Hi Reza,

I had more success with your auto calibration this morning

There is some sort of circular reference though: For Juha's optical homing to work, the X / Y box size needs to have approximately correct values - otherwise the machine will not home in on the circle but move to far away to recognize it. This is why homing did no longer work after failed auto calibration (see my previous post).

I have set some approximate values for box size, tweaked the settings for homing mark visual filters and voilá - finally got auto calibration to work. Auto calibration now returns deterministic results, i.e. I get the same result for each run now

The measurements still did not match my own, but I found the cause and it was rather simple: My homing mark is on table surface, while I measured the box size on PCB level, which is table surface + 1.6mm.

As I use a standard lense, the closer objects are to the lense, the larger is their projection - alas the larger they appear on camera. Given the high resolution of my downward facing camera, this effect is quite significant and results in a change in box size of about 0.5 to 0.6 mm. I do use custom component trays which are even higher (table surface + 3mm), so the effect is also stronger and so the projected pickup locations do not match the camera picture.

I am not sure how to fix this yet and also not sure if I absolutely have to. I found some telecentric lenses for M12 (S-mount) which would solve the problem optically, but these are rather expensive. Also, the ones I found have a relatively long working distance (WD > 40mm) so I would have to mount the camera much higher. Another option would be compensation in software, but then I would need to "predefine" the height / Z-level of different spaces in the work area and measure pixel to mm ratio for each Z-level... Seems complicated.

For pickup, the box size / pixel-mm ratio has no effect: Even though your projected pickup locations do not fit the image, the locations are correct in reference to the machine's coordinate system. Once the sprocket hole is detected, the relative location of the component is found without a problem. And for placement, PCB surface will always be the same.

Uplooking camera does not have that problem as needle and components will always be lowered to the same Z-level (PCB surface level).

By the way, have you thought about implementing a similar auto calibration feature for the up looking camera? Optically center the needle, move the machine by a known distance, measure offset, calculate box size?

Thanks and regards
Malte

glad its working. implemented the upward camera calibration last night, untested. will update.

also what slack values do you see with slack compensation on and off?

Upcamera calibration is working, and I've made it provide more feedback so you can see what the source data is. Alas, even with the slack compensation turned on, there is some error in the first movement - will have to trace it down. I'll migrate the updated code to the downcamera calibration so you can see what's going on there too.

https://www.youtube.com/watch?v=-0smQFi ... e=youtu.be

I rewrote SelectCamera() - previously it would shut down a camera and restart it for every circle detection which is slow. I made it only do that if it's switching cameras and now it's much more quick. I'll probably push out the changes into an .exe this weekend, but I'll push out the changes to git now if you want to test.

Some instructions on using the template based fiducal finder

thereza wrote:Upcamera calibration is working, and I've made it provide more feedback so you can see what the source data is.

Awesome - I noticed you published the code to github. Are you making friends with git after all? Just kidding...

I will download and take it for a test ride.

As posted previously, down cam calibration is working on my machine now and I am happy with the results.

Thanks for your excellent work!

We are at the start of a hopefully very creative project and I see there are some very motivated and gifted contributors already at work to enhance this IMO very exiting project. Juha has developed a good start basis and a hardware with lots of freedom for enhancements and new features.

Taking a glance at thereza's extensive and creative contribution (Bunchofchanges) I found some irritating formating changes e.g. from the .NET standard Allman style braces
to K&R java style braces.
Working in a large code project with many individual contributors it is IMHO important to keep the coding as close to a given standard as possible.
I don't want to start a discussion on this C# style and coding standards here.

Juha has defined this standard which is in most parts compliant to Microsoft's design rules.

I would like to suggest that all contributors try to follow Juha's direction.
If somethings is added we should use the given "Juha" style.
That makes it easier to read when the code is homogeneous in style.
Even if it is sometimes a great temptation we should try not to reformat or rename existing code or change indentation or white space.

That all will help up to easier come the the heart of the matter and make an even better tool for all who bought a kit from Juha.

Visual Studio has automatic formatting, so the issue doesn't really matter: A couple of keystrokes and anybody can get the formatting best suited to his/her eye.

I actually can't read the code with all the extra spaces and lines, let alone code in that format. i understand that some people prefer it but i see it as very inefficient. you spend more time scrolling and trying to figure out what's going on vs. being able to look at the screen and understand what's going on quickly. that's one major advantage to python - it forces you to write compact code. i write based on my own aesthetic sense - the code has to look visually appealing to me. i honestly don't see any reason what that became a common standard - anyone know the story?

so i'm downloading visual study community. free to open source projects - will try it out to see if it fixes some of the issues i'm having with vs2010.

mawa wrote: I don't want to start a discussion on this C# style and coding standards here.

I still think we should not get too deep into that discussion here. Just this:

Having programmed and still programming in many common and uncommon languages (Cobol!, RPG, dBase III/IV, Clipper, FoxPro, Fortran, PL/1, Smalltalk!) during my IT career it's not the white space what disturbs me most but IMHO the inconsistent usage of formatting and naming.

There's a saying, also known as the IT boy scout rule : Always leave the code in a better state than you found it. (Opportunistic Refactoring / Clean Code developer).

Concerning VS 2013: I work with both: 2010 @ home and 2013 + CodeRush + DevExpress @ work (2015@ work next). So reza, don't be disappointed , there not too much difference for WinForms Apps like the Liteplacer UI. (except the IMHO ugly windows 8 inspired monochrome tool-bar icons). If I can help you with VS send me a pm with your issues.