LitePlacer-rmod Updates
Re: LitePlacer-rmod Updates
I cloned your commit ed3c797509 and tried running it. Compiles and can be started.
I might be missing something, but the buttons to trigger camera pixel-mm calibration are no longer there?
Also, many GUI elements you introduced are have property Visible = false.
Any trick I need to pull to test your new features?
I might be missing something, but the buttons to trigger camera pixel-mm calibration are no longer there?
Also, many GUI elements you introduced are have property Visible = false.
Any trick I need to pull to test your new features?
Re: LitePlacer-rmod Updates
Sorry, used the wrong branch and ended up testing Juha's code again - stupid me.
Your code does not compile though, errors are as follows:
Your code does not compile though, errors are as follows:
Code: Select all
1>------ Rebuild All started: Project: LitePlacer, Configuration: Debug x86 ------
1>C:\Users\Malte\Documents\git\LitePlacer\LitePlacer\TapesClass.cs(103,25,103,42): error CS1061: 'LitePlacer.TapeObj' does not contain a definition for 'isFullyCalibrated' and no extension method 'isFullyCalibrated' accepting a first argument of type 'LitePlacer.TapeObj' could be found (are you missing a using directive or an assembly reference?)
1>C:\Users\Malte\Documents\git\LitePlacer\LitePlacer\TapesClass.cs(249,15,249,32): error CS1061: 'LitePlacer.TapeObj' does not contain a definition for 'isFullyCalibrated' and no extension method 'isFullyCalibrated' accepting a first argument of type 'LitePlacer.TapeObj' could be found (are you missing a using directive or an assembly reference?)
1>C:\Users\Malte\Documents\git\LitePlacer\LitePlacer\TapesClass.cs(264,23,264,40): error CS1061: 'LitePlacer.TapeObj' does not contain a definition for 'isFullyCalibrated' and no extension method 'isFullyCalibrated' accepting a first argument of type 'LitePlacer.TapeObj' could be found (are you missing a using directive or an assembly reference?)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
Re: LitePlacer-rmod Updates
Making progress, nearing an alpha release of the revamp of the code.
Migrated all the locations into a location manager so the code is much less cluttered with textbox related stuff and removed a lot of stuff from the properties.settings.
Also it now supports an unlimited number of arbitrary locations so the mark code is all gone
The location code is quite elegant and i'm happy with the way it looks aesthetically. This code will populate pull down menu items with one line functions to set or update the locations
and I've added event handles that trigger whenever anything changes so it synchronizes the pulldowns with the locations (in a table, databound) and saves using xml serialization on any change with just 3 lines of code
The xml serialization (once setup) is very simple way to synchronize data. For example, _locations is a type of list of locations. This is all the code you need to save it - and it works for any type of data structure.
As the componens and job data have been migrated in a similar way, once the job list is saved, it includes all the relevant component - so the job file will contain everything you need (no need for pick and place once thtat's setup).
The only issue/question I have is that I see no need for the job offset as the offset will be captured in the machine coordinates. I'm just going to remove support for that as well (the fewer lines of code, the easier it is to manage and extend it).
I need to finish integrating my vacuum pressure detection and figure out a way to mechanically align my new upcamera (the logitec one that was recommended). It's just taped into place now and I can't imagine that'll be accurate. Alternatively, I'm considering implementing something like this http://www.pyimagesearch.com/2014/08/25 ... m-example/ to compensate for misalignment of the camera.
Migrated all the locations into a location manager so the code is much less cluttered with textbox related stuff and removed a lot of stuff from the properties.settings.
Also it now supports an unlimited number of arbitrary locations so the mark code is all gone
The location code is quite elegant and i'm happy with the way it looks aesthetically. This code will populate pull down menu items with one line functions to set or update the locations
Code: Select all
private void UpdateGoToPulldownMenu() {
goToLocationToolStripMenuItem.DropDownItems.Clear();
setLocationToolStripMenuItem.DropDownItems.Clear();
foreach (var name in Locations.GetNames()) {
var x = new ToolStripMenuItem(name);
var y = new ToolStripMenuItem(name);
x.Click += (s,e) => { Cnc.CNC_XY_m(Locations.GetLocation(s.ToString())); };
y.Click += (s, e) => { Locations.GetLocation(s.ToString()).SetTo(Cnc.XYLocation);};
y.BackColor = Color.Orange;
goToLocationToolStripMenuItem.DropDownItems.Add(x);
setLocationToolStripMenuItem.DropDownItems.Add(y);
}
}
Code: Select all
//setup location jumps
UpdateGoToPulldownMenu();
Locations.GetList().ListChanged += delegate { UpdateGoToPulldownMenu(); }; //update if list changed
Locations.LocationChangeEvent += (s, e) => { if (e.PropertyName.Equals("Name")) UpdateGoToPulldownMenu(); Locations.Save(); }; //update if name on list changes
Code: Select all
Global.Serialization(_locations, FileName);
The only issue/question I have is that I see no need for the job offset as the offset will be captured in the machine coordinates. I'm just going to remove support for that as well (the fewer lines of code, the easier it is to manage and extend it).
I need to finish integrating my vacuum pressure detection and figure out a way to mechanically align my new upcamera (the logitec one that was recommended). It's just taped into place now and I can't imagine that'll be accurate. Alternatively, I'm considering implementing something like this http://www.pyimagesearch.com/2014/08/25 ... m-example/ to compensate for misalignment of the camera.
Re: LitePlacer-rmod Updates
git broke and stopped letting me sync code. i hate git
Re: LitePlacer-rmod Updates
Honestly Reza, you are a great software developer and I simply do not get your hatred for Git...thereza wrote:git broke and stopped letting me sync code. i hate git
Can I do anything to help you overcome the problems?
Last resort: If you gave me access to your code, I would be more than happy to handle updates to git for you, so Juha can still include your code via pull-requests.
Do you have a publicly accessible SVN? Or simply FTP maybe?
You could also send me a ZIP or Diff via e-mail, dropbox or whatever means.
Re: LitePlacer-rmod Updates
Or just send a zip file of your sources to me - I have a diff tool and can do copy/paste; no need to go through Malte.
And let me say again that I appreciate enormously your contributions!
And let me say again that I appreciate enormously your contributions!
Re: LitePlacer-rmod Updates
it has been more of a time sync than I would have liked, but i'm happy with the direction the code is moving. I'm very close to a usable version and will put a zip file someplace when I'm ready.
So I was thinking more about the needle wobble vs different heights so I ran a quick test -
I did a up camera mm/pixel calibration at the PCB height and at 10mm above the PCB height. I performed wobble measurements at both heights. After subtracting out the mean, I ended up with this
As you can see, the points are almost on top of each other. As suspected, the wobble measurement can occur at any height and will yield the same results. All you would need to do is apply a height specific offset compensation which can be detected by measuring the needle at different Z heights. In my test case, there was a .103,.9153 offset different between the two measurement sets.
This is relevant to me because I've mounted my camera flush inside the table (the logitec one) and I can't focus on items that are super close anymore (i.e. PCB height) while being able to fit much into the field of view - in the case of larger item that need offsets calibrated. This lets me calibrate the wobble at a higher point, and add an additional offset term that's height-dependent. Also, we can measure the needle length to take this into account. I'll have to think about how to best implement it.
I also modified the code to set the camera to the highest resolution (the code currently defaults to the default resolution independent of the camera resolution.
You just need to save the index for use in the frame measurements (currently assumed to be 0).
So I was thinking more about the needle wobble vs different heights so I ran a quick test -
I did a up camera mm/pixel calibration at the PCB height and at 10mm above the PCB height. I performed wobble measurements at both heights. After subtracting out the mean, I ended up with this
As you can see, the points are almost on top of each other. As suspected, the wobble measurement can occur at any height and will yield the same results. All you would need to do is apply a height specific offset compensation which can be detected by measuring the needle at different Z heights. In my test case, there was a .103,.9153 offset different between the two measurement sets.
This is relevant to me because I've mounted my camera flush inside the table (the logitec one) and I can't focus on items that are super close anymore (i.e. PCB height) while being able to fit much into the field of view - in the case of larger item that need offsets calibrated. This lets me calibrate the wobble at a higher point, and add an additional offset term that's height-dependent. Also, we can measure the needle length to take this into account. I'll have to think about how to best implement it.
I also modified the code to set the camera to the highest resolution (the code currently defaults to the default resolution independent of the camera resolution.
Code: Select all
public void SetMaxResolution() {
videoCapabilityIndex = VideoSource.VideoCapabilities.Length - 1; //the last one is the highest resolution for my cameras. not sure it's generalizable
VideoSource.VideoResolution = VideoSource.VideoCapabilities[videoCapabilityIndex];
Global.Instance.DisplayText("Setting Camera " + cameraType + " to resolution " + VideoSource.VideoCapabilities[videoCapabilityIndex].FrameSize);
}
Re: LitePlacer-rmod Updates
i finally got around to testing out my modified firmware for the tinyg to support ADC input from the \SS2 input. Seems to work with my preliminary trials.
Here's the .hex file : https://www.dropbox.com/s/beru9dte1clwb ... g.hex?dl=0
Here's the source in case someone wants to re-git-up-the-diff : https://www.dropbox.com/s/r3h3beglrjg3h ... e.zip?dl=0
Upgrade instructions are on tinyg's site.
and to query the ADC use the command syntax
{"adc0":""}
it returns a 12-bit value.
Here's the .hex file : https://www.dropbox.com/s/beru9dte1clwb ... g.hex?dl=0
Here's the source in case someone wants to re-git-up-the-diff : https://www.dropbox.com/s/r3h3beglrjg3h ... e.zip?dl=0
Upgrade instructions are on tinyg's site.
and to query the ADC use the command syntax
{"adc0":""}
it returns a 12-bit value.
Re: LitePlacer-rmod Updates
Brilliant Reza!
Which air pressure sensor are you using?
And will you also upload a diff of the LitePlacer software or is it not ready yet?
I would like to help test and debug - and start to benefit from your enhancements
Which air pressure sensor are you using?
And will you also upload a diff of the LitePlacer software or is it not ready yet?
I would like to help test and debug - and start to benefit from your enhancements
Re: LitePlacer-rmod Updates
almost ready - i'm actually rushing to finish so i can assemble some PCBs I got in. I've added support so that you can specify a focal height above the upcamera for calibration. This means that you really don't need to cut a hole in the table *shrug*. I can't imagine any reason that it will not work perfectly fine by performing the optical & wobble compensation at any arbitrary height. I was thinking that it would require more work to compensate for the additional height but I don't think so.
so i hooked it up, and it's working (pressure detection).
the part is http://cache.freescale.com/files/sensor ... X4250A.pdf - perhaps not optimal but works best of the sensors I had laying around.
here is how i have it attached :
and connected to the tinyG here with a 1uF cap to reduce noise (required as the wire I used has no shielding) :
The output of the ADC is ~2500 with the pump off, ~2200 with the pump on, and ~2090 with the needle occluded - though there is a few second delay as the pressure builds up so it will add some delay to the sensing unless you use a more powerful pump.
so i hooked it up, and it's working (pressure detection).
the part is http://cache.freescale.com/files/sensor ... X4250A.pdf - perhaps not optimal but works best of the sensors I had laying around.
here is how i have it attached :
and connected to the tinyG here with a 1uF cap to reduce noise (required as the wire I used has no shielding) :
The output of the ADC is ~2500 with the pump off, ~2200 with the pump on, and ~2090 with the needle occluded - though there is a few second delay as the pressure builds up so it will add some delay to the sensing unless you use a more powerful pump.