automatic routing
Are the green Lines what you want a routine to draw? All of them at once for an entire pair of BGAs, or [see the description in Post 1] just a single selected dot in one BGA? If a single dot on one BGA, are you also picking a single one on the other, or the entire other BGA for the routine to find the closest dot on? If picking a single dot on the second BGA, might it sometimes not be at the same level as the one on the first BGA, so that a straight Line between them would not be horizontal? If so, should it connect diagonally, or make a jogged path with orthogonal segments? What criteria would there be for how that path should run? Should a routine somehow forbid selection of an internal dot inside a BGA? Might you ever pick a dot on the top or bottom edge, or even the opposite edge, instead of the edge closer to the second BGA? Should the connectors be Lines, or perhaps Polylines so they can be given width [since I assume you're talking about traces on printed circuit boards]?
What kind of object is a BGA? An unassociated array of separate objects? An Array object? A MINSERTed Block? A single Block containing all the dots? Are the separate dots [however they relate to each other] Blocks, or Polylines [e.g. Donuts with zero inside radius], or Circles with Solid Hatching in them [or perhaps Solid Hatching without the defining perimeter Circles], or maybe 3D Solids, or....?
Would you have Snap turned on, and the BGA's positioned by means of it, so that you can pick at a dot right in the middle, and a routine could just use that pick point regardless of the nature of the dots, or would you be selecting an object for which the routine would need to find the [again, an assumption] center of the dot(s)?
These kinds of questions are why a sample drawing file would be much more helpful. It should show before and after conditions, and have some notes with arrows, saying "User picks this point / Array object / Minsert / Block / location" and "then picks this / here..." and "routine draws this / these," etc.
Kent Cooper, AIA 
@stevor wrote:
1. The function 2PL_NearTL is a function, not a command.
2. To use it, supply the 2 lists of coordinates to be matched;
....
I'm getting a syntax error when I run that, and also with a different approach I was trying -- I suspect it may have something to do with nesting (foreach) functions, but I'm not sure, and haven't dug very deep yet.
But if I understand what yours is meant to do, I have a question:
Say it looks at the first point in the PL1 list -- I'll call it ptA. And it steps through the PL2 list and compares the distance from ptA to each point in PL2, and finds the closest one -- I'll call that ptZ. So a list that pairs ptA with ptZ goes into the NATL list.
Now, it goes on to later points in the PL1 list. If it finds one -- I'll call it ptB -- that's closer to ptZ than ptA was, it looks like it removes the list that pairs ptA with ptZ, and puts in its place a list that pairs ptB with ptZ instead. Fair-enough -- if it's closer, that should be the pairing.
But it doesn't look like anything else is ever done with ptA after that. So there's no pairing of ptA with [presumably] the next-closest point to it from the PL2 list. Am I correct that it's meant to work that way, and that ptA will not get a partner? Or am I misunderstanding how it works? [I wanted to test it and check the result, but haven't been able to diagnose the syntax error yet.]
In the OP's case, I would think every point in one list wants to end up paired with one from the other, but not having gotten answers to most of my questions about it, I'm not sure of that, either.
Kent Cooper, AIA