LitePlacer.com forums

Here is a weird one: I've been trying to place parts on the bottom layer (see the EAGLE ULP thread), and by hand editing the csv file and using the Bottom check, and setting an X offset of the board width I was able to place parts on the bottom, EXCEPT for 0402 parts.

When it goes to find the tape hole it goes to hole 10 or 11 which doesn't have anything there since I'm only using a strip with about 10 parts (5 holes). It doesn't do this when placing 0402 parts on the top of the board. I'm using EXACTLY the same tape definition for both so it can't be something with that. The only two things different are the "Bottom" box checked and a non zero X offset.

This seems really strange, I tried both top and bottom several times with turning the machine on and off and restarting the software and I get exactly the same results.

BTW 0603 and 0805 do exactly the same thing on top and bottom, it is JUST the 0402 that behaves differently.

Thanks,

John S.

What is the "next" part in your tape table? I assume you did check that and it is 1 or another small number. This might have to do with the calculation of odd/even part, but I doubt that, as the pickup should not care for top/bottom. Of course, you might have found a bug that would show on top side as well, if the conditions happen to be the same. Also, if the software somehow things there are more 0402s than 10, fast method would go finding the start and end hole, getting too far. This would be an issue with the csv file. Other than these, I have no immediate ideas.

And I agree, this sounds strange. I can try to reproduce, but it might be difficult. For that, I need your tape definitions file, your csv file and a 1:1 scale PDF or your board bottom side.

Yes the "next" is 1.

OK I think I have it. The csv file has 23 of these 0402 parts on the bottom and 2 on the top. I wanted to just try the accuracy of a few parts before putting paste on the board, so I checked the placed box for most of the instances and left 3 unchecked. So it looks like it is using the number of instances in the CSV file not the number of unplaced instances to calculate the length of the tape. Since there were only two on the top there was not an issue with using a short piece of tape.

John S.

it is using the number of instances in the CSV file not the number of unplaced instances to calculate the length of the tape.

Good find, thank you! I consider this a bug; I’ll fix it.