Another slew of updates to the RMOD software

[Knas]

I've been trying to get the RMOD up to par for production and i believe i might finally be there. Most of the issues reported in juhas repo are fixed at this point, including the tape orientation error. This has not been thoroughly tested yet as i don't use it myself, the set last / set first is so much faster. Anyway things i've added / fixed:

Full nozzle changer support with an option to use different video filters for different nozzles during calibration. All components are now bound to a nozzle (if the nozzle changer is enabled) and the machine will automatically change nozzle if necessary during placement and recalibrate. I've also added simple functions to move around the job order so that one can optimize for as few nozzle changes as possible.

Simple obstacle avoidance - this currently only works reliably on obstacles that are set at the edges of the machine, i needed this as the machine will bump into the feeders otherwise - not sure if it's useful to anyone else.

Pressure sensor averaging - because of the possibility of erroneous values coming from the ADC due to the immense filth in the powerlines the software takes 10 readings and averages the value. This will soon be replaced with a median routine instead so i can weed out values that are obviously wrong.

Feeder error setting - if the machine fails at picking up from a feeder 3 times in a row the feeder is taken out of commission and marked as having an error, this will need to be reset by the operator before the feeder will be used again.

Check for redundant moves - the machine won't try to go to a location where it's already at since the software can't understand the reports it's getting back in that case.

Added an automatic movement to Y 0 at the startup of the software, this is necessary in order to avoid the "creeping" that happens if the software is being restarted without the TinyG being reset.

Z axis cannot be joggedd below the table anymore.

Quit menu works.

Null pointer check in the camera detection routines.

Added a message if up camera zeroing fails.

The code can be found here; https://github.com/Knaster/LitePlacer-ver2

Please let me know if you have any issues, i'll probably do a pull request against Juhas master shortly.

I have also done a bunch of hardware upgrades that i'm soon to post about, one of them being a separate power supply and simple line driver for the pressure sensor - in my opinion it simply wasn't possible to get reliable results from the sensor using the TinyG's supply. However the sensor is amazing, placed my first complete board without a single missed component the other day - and that's ~200 components.

-Karl

[WayOutWest]

Pressure sensor averaging - because of the possibility of erroneous values coming from the ADC due to the immense filth in the powerlines the software takes 10 readings and averages the value. This will soon be replaced with a median routine instead so i can weed out values that are obviously wrong.

I'm sure you've already done this, but for anybody else reading, you definitely need a "pneumatic capacitor" in the vac line in order to get usable readings from the ADC. Malte explained how here.

I have also done a bunch of hardware upgrades that i'm soon to post about, one of them being a separate power supply and simple line driver for the pressure sensor - in my opinion it simply wasn't possible to get reliable results from the sensor using the TinyG's supply. However the sensor is amazing, placed my first complete board without a single missed component the other day - and that's ~200 components.

I've got a new headplate on order that includes an AVR ATTINY88 so that the analog signal only travels a few centimeters along a nice clean PCB far from the motor wires before being sampled -- instead of having to run through a meter or two of noisy cablechain.

Full nozzle changer support with an option to use different video filters for different nozzles during calibration.

Cool! Any chance you'll share the STL files for your incredible nozzle holder?

- a

[s_sergiu]

Hello Knas and other forum members,

I compile your source code same way as I'm doing with source from https://github.com/jkuusama/LitePlacer-ver2.git/
However Immediately after left window opens, program crashes.

I also removed both usb cameras (Andostar and C270) but it keeps crashing. I compiled as release, both x86 and x64 with same result. I use VS 2015.

Other issue regarding calibrationsheet.png : when I open with irfanview (the program I currently use for pictures) or devCad, the image is completely black . However I can open with MS Words and print at laserprinter with 600x600dpi.
When checking with ruler, "149" and "150" marks are at 1mm distance (I suppose that ".1mm" means 1mm and not 0.1mm). This way, distance between dots on X axe is 185mm and between bottom left dot and top left dot is 185mm as well.
During calibration, machine seems to travel 175mm. Even I jogging the camera on top of each dot and software is auto aligning exactly on center of dots, next step when is going back from top left dot to bottom left dot, will stop about 10 mm shorter than real position.

Any advice will be appreciated.

Sergiu

[Knas]

Hi Sergiu

I compile your source code same way as I'm doing with source from https://github.com/jkuusama/LitePlacer-ver2.git/
However Immediately after left window opens, program crashes.

That's strange. How do you compile it? I haven't honestly try to run the program as a binary yet, only as a debug under visual studio.

Other issue regarding calibrationsheet.png : when I open with irfanview (the program I currently use for pictures) or devCad, the image is completely black . However I can open with MS Words and print at laserprinter with 600x600dpi.
When checking with ruler, "149" and "150" marks are at 1mm distance (I suppose that ".1mm" means 1mm and not 0.1mm). This way, distance between dots on X axe is 185mm and between bottom left dot and top left dot is 185mm as well.

The issue with irfanview might be due to local decoders since you can actually print the image in the end, it looks right to me if i view it in firefox directly from the repo.

I should explain though; the way the calibration sheet works is that in between "1" and "150" there should be exactly 150mm obviously. However in order to make a .1mm scaling that's usable the restoring numbers are spaced 1.1mm extra (following the same scheme as on these 1940s calipers i have) so .1 should be at 151.1mm, .2 at 152.2mm etc.

Now printers are notoriously bad at actually printing to scale, so you might have to experiment with your x/y DPI numbers in order to really get it *perfect*.

During calibration, machine seems to travel 175mm. Even I jogging the camera on top of each dot and software is auto aligning exactly on center of dots, next step when is going back from top left dot to bottom left dot, will stop about 10 mm shorter than real position.

Could you elaborate on this a little? I'm not sure i follow exactly. The X and Y dots are located 185mm from the center dot. The very first calibration however is not trying to find the dots but you are supposed to jog the machine to the outer edge of the circle.

Karl

[Knas]

I'm sure you've already done this, but for anybody else reading, you definitely need a "pneumatic capacitor" in the vac line in order to get usable readings from the ADC. Malte explained how here.

So i'm not entirely sure on how this works. I understand that the capacitor would build up a pressure and that once opening the valve the suction should be much greater than what's there without it. But the way the current implementation works is that it measures the pressure by opening the valve and let it suck "freely" and measures the pressure, then after it picked up a component it measures the pressure again and calculates the difference. I cannot fully wrap my head around how to implement this with a capacitor, any hints much appreciated.

I've got a new headplate on order that includes an AVR ATTINY88 so that the analog signal only travels a few centimeters along a nice clean PCB far from the motor wires before being sampled -- instead of having to run through a meter or two of noisy cablechain.

That is obviously a much better way to do it, i just didn't feel like diving into that much of hardware modifications

Cool! Any chance you'll share the STL files for your incredible nozzle holder?

Absolutely. I am going to make a new version of it today or the next few days, i'll post files after that!

Karl

[s_sergiu]

Hi Karl,

I'm doing following steps:

1. Build - Clean solution
2. In Solution explorer build Video.DirectShow
3. Build - Build solution.

Same error in both debug and release mode.
See attached pic.

Sergiu

[Knas]

Sergiu

I just committed a new version, the error you're getting should be fixed in it - let me know if it still doesn't work, and if so, as many details as you can give me is always good.

I've done two boards with the machine in the last two days, the new error reporting of feeders (based on the vacuum sensor) is *really* helpful when doing complex boards. When having ~200-300 components it's time consuming to try and find any components that didn't place right. With this you can just check the job list afterwards and see if anything is marked "ERROR" under method, if so fix whatever the problems are and re-run the job.

The automatic nozzle changer based on the nozzle-part association is also really really helpful, especially when going back and fixing a few missed components - no more manual labour or clicking to change & calibrate - just press place and it'll all be taken care of.

I also did a debug info on/off as well as a optional line limit since the textbox is slowing down performance considerably.

In fact, performance is one of the biggest problems i'm having with the software - i'm using a simple netbook and there are a lot of unnecessary delays where no real processing is being done, i believe the software is just updating the interface with the Application.DoEvents() method a whole lot more than is necessary. I will check into this.

Another issue is that since there's no message queue in the CNC controller it's possible to confuse the machine by sending two or more different operations at once - an example would be to calibrate the nozzle and pick up a component at the same time. Granted this is something that one can avoid very easily, nevertheless it would be nice to be able to "queue up" different commands through the user interface. I also think that an internal queue would be able to make the software perform much better since methods wouldn't have to do a wait loop - but i'm not sure about all that.

Karl

[s_sergiu]

Karl,

Is compiling and running fine. I will start over with all calibrations.
Will post results back here once done.
Thank you for help.
Sergiu

[s_sergiu]

Karl,

I loaded Juha's example to test some placement.
Fiducials are identified correctly.
I went also on top of the 1st hole of one tape and added that tape.
However when I try to place some resistors I got the error"Tape is not yet calibrated (see pic.).
I'm also trying to place the SO8 and get error "Placement operation failed.Revirw job status".
Sure I'm missing some preparation steps.

I will appreciate if you can describe summary few steps on how to run a simple job.

Sergiu

[Knas]

Karl,
Fiducials are identified correctly.
I went also on top of the 1st hole of one tape and added that tape.
However when I try to place some resistors I got the error"Tape is not yet calibrated (see pic.).
I'm also trying to place the SO8 and get error "Placement operation failed.Revirw job status".
Sure I'm missing some preparation steps.

Sergiu, it's possible that when i modified the software to do set first / set last i accidentally overrode the original behaviour of only setting the first hole and have the machine visually try to find each component - i can fix this in coming updates. However, the reason i did the set first / set last is because of a number of things. First off, finding each hole in between each component is painfully slow, it also does not improve accuracy in my opinion. With the set first / set last you do exactly that; focus on the first hole of the tape and set it, then focus on the last hole and set it. This routine does not need to use the "tape orientation"-setting since it can calculate the exact rotation of the tape around 360 degrees without any issues, as long as you remember to keep the holes the "feeder standard"-way; with holes on the left hand side. The first hole should be the hole closest to the middle of the machine and the last is the one furthest out. I guess if your tape is aligned right-sided you could just swap the first and last hole but i haven't tried it. Anyway i find that the accuracy is in fact better (as long as you make sure that the first and last holes are found precisely) since it avoids any possible hole-finding errors during placement.

Karl