@Earl A good starting keyword for researching this may be "catenary". See the Wikipedia article with that title. In particular, see its last section "Chain under a general force".

As is well known, a static uniform chain supported by two uprights of equal height assumes the shape of a simple hyperbolic cosine function.

It's not clear from your worksheet what the direction of gravity is. Is it parallel to or perpendicular to the axes of rotation of the gears? The shape of the chain will depend on that.

@lcz I just posted an application of breadth-first search in graphs in the Posts section.

By the way, I don't think that you understand the proper English usage of re in a title. One may use (but is not obligated to use) the title "Re: X" if one is responding to something titled "X". It doesn't make sense to put "Re" on an original title, such as at the beginning of a Question thread.

@Axel Vogt Is it perhaps the case that the reason that int doesn't do this straightaway is that the constant of integration is not just a constant but rather a function that depends on y but not x? If so, then this probably shouldn't be considered a bug.

@Kitonum Yes, it is simpler and easier to understand; however, the following illustrates why I chose to use AllPairsDistance rather than Distance:

G:= GraphTheory:-SpecialGraphs:-HallJankoGraph():
CodeTools:-Usage(AllEdgesDistance(G,1)):
memory used=488.23KiB, alloc change=0 bytes, 
cpu time=0ns, real time=7.00ms, gc time=0ns

CodeTools:-Usage(Dist~(1, convert(GT:-Edges(G), list), G)):
memory used=249.29MiB, alloc change=0 bytes, 
cpu time=1.80s, real time=1.59s, gc time=437.50ms

There is nothing special about the chosen graph; any sufficiently large graph will serve.

If I modify my procedure as follows, then it'll look more like your procedure but still retain its efficiency. Note that I also sort the output wrt [distance, edge] as requested by the OP. Most of the perceived complexity of the last line of my procedure comes from including the edge in the sort criteria.

AllEdgesDistance:= proc(G::GRAPHLN, v)
uses GT= GraphTheory;
local 
    VL:= GT:-Vertices(G), V:= table(VL=~ [$1..nops(VL)]),
    D:= GT:-AllPairsDistance(G), 
    Distance:= (u,v)-> D[V[u],V[v]], 
    Dist:= (v,e)-> min(Distance~(v,e))
;
    sort((E-> `[]`~(Dist~(v,E), E))([GT:-Edges(G)[]]))
end proc
:    

@vs140580 Both the error message and the help page ?GraphTheory,Distance are very clear on this point. You need to change Distance(e[1], v) to Distance(g, e[1], v).

If I define DistE(v, {u,w}) to be the distance from vertex v to edge {u,w} and DistV(v, u) to be the ordinary distance between vertices, then isn't it always true that DistE(v, {u,w}) = min(DistV(v,u), DistV(v,w))?

@Carl Love Although the TableInverse procedure that I gave above is quite efficient, inverting tables is an important enough operation that it's worth having a dedicated procedure for it, and some small extra efficiency can be gained that way. Anyway, the new procedure is still quite short:

TableInverse:= proc(t::table)
local x, T:= table();
     for x in indices(t, ':-pairs') do T[rhs(x)][lhs(x)]:= () od;
     {indices}~(T)
end proc
:

Very important: The time required to invert an entire large table by this procedure can be less than the time required to find the inverse of a single entry by the select method (as proposed by Kitonum). Here's an example of that:

#Example and timing comparison:
T:= table():
R:= rand(0..2^5):
#T will have 2^18 (~1/4-million) indices:
for i to 2^9 do for j to 2^9 do T[i,j]:= 'R'()$2 od od:

TI:= CodeTools:-Usage(TableInverse(T)):
memory used=52.03MiB, alloc change=2.00MiB, 
cpu time=547.00ms, real time=537.00ms, gc time=0ns

#Get an arbitrary entry:
j:= (6,7):
x:= T[j];
                             9, 11

#Get its (setwise) inverse from inverse table already constructed:
S1:= TI[x]:
#Verify that that inverse set contains the known index:
member([j], S1);
                              true

#Get one-point setwise inverse with select:
S2:= CodeTools:-Usage(select(i-> T[i[]]= x, {indices(T)})):
memory used=24.00MiB, alloc change=6.01MiB, 
cpu time=703.00ms, real time=716.00ms, gc time=0ns

#Verify that it's the same inverse set:
evalb(S1=S2);
                              true

Efficient use of tables is one of the most important things to learn for writing efficient Maple code.

@lcz In your procedure, you need to change Distance(P, u, j) to Distance(G, u, j). It was only due to an unlucky coincidence that your example worked with P.

@mapleatha Thanks, and a Vote Up for the Answer would be appreciated.

Apparently, in more-recent Maple, D has been updated to handle procedures containing symbolic operations such as convert (an arrow expression is considered a form of procedure). This is an impressive achievement. Nonetheless, it's still important to use unapply where appropriate. I'm glad that you've been able to put it into widespread use.

From decades of teaching and explaining Maple, I've noticed that understanding when to use unapply is usually a major milestone in one's learning of symbolic programming.

@David Sycamore 

Regarding your listplots error: You have a small spelling error: The command is plots:-listplot, not plots:-listplots.

Regarding your multiple-assignment error: I need to know which command line gave the error. It's either this one

(S,B):= CodeTools:-Usage(A(N)):

or this one

(i1,i2):= selectremove(k-> B[k], [$1..nops(S)]):

Please download and execute this worksheet. Do you still have errors?
BacktrackSeq.mw

Here's an updated plot showing 2^15 entries, with those that violate that inequality highlighted (this is precisely the contents of the attached worksheet):

restart:

A:= proc(N::And(posint, Not({1,2})))
local 
    n, m, p, U:= table([HFloat(1)= 1]), 
    B:= rtable(1..N, [false$2], datatype= truefalse), 
    A:= rtable(1..N, [1,0], datatype= float[8])
;
    for n from 2 to N-1 do
        p:= A[n];
        m:= U[p];
        B[n+1]:= type(m, posint); 
        A[n+1]:= `if`(B[n+1], n-m, min(abs~(p -~ A[..n-1])));
        U[p]:= n       
    od;
    ([seq](trunc(a), a= A), B)
end proc
:
N:= 2^15:
(S,B):= CodeTools:-Usage(A(N)):
memory used=2.19GiB, alloc change=0 bytes, 
cpu time=7.53s, real time=6.58s, gc time=3.20s

#Separate the indices by provenance of the entry:
(i1,i2):= selectremove(k-> B[k], {$1..nops(S)}):

#Find the indices that violate an inequality:
i3:= remove(n-> S[n]+S[n+1] <= n, {$1..nops(S)-1});
  i3 := {521, 1792, 2377, 3670, 4332, 5767, 6786, 7442, 29083}

#Fraction of entries generated by the "repeat rule":
evalf(nops(i1)/N);
                          0.8138732910

#Check whether all the inequality violations come from the repeat rule:
i3 subset i1;
                              true

#For the purpose of plotting only, separate out the violators:
i1:= i1 minus i3:

plot(
    [(i-> `[]`~(i, S[[i[]]]))~([i||(1..3)])[], [[0,0], [N,N]]],
    style= [point$3, line], 
    legend= [`Repeat  `, `Novel  `, `Large  `, y=x], 
    color= [red, blue, green, black], 
    symbolsize= [1,9,9], symbol= [point, diamond, solidcircle],
    thickness= 0, axes= boxed, axesfont= [TIMES, ROMAN, 8],
    axis[1,2]= [tickmarks= 8]
);

Greg, I agree with Tom: Definitely don't use implicitplot3d to plot balls. The error message that you got is unfortunate, and some people at Maplesoft may be interested in tracking it down. This is something that probably can't be debugged by a relatively inexperienced user. In particular, implicitplot3d is mostly externally coded, so you certainly wouldn't get very far looking into that. However, I wouldn't be surprised at all if the error was simply due to the massive amount of data contained in your balls. Using Tom's balls may be all you need to fix the problem. 

@ I don't see any attached file. Please try again. 

The following symbols are used in your PDF without the slightest definition, not even an equation; nor are they used in your worksheet, so that can't be used to figure out their meanings either: x, y, a, v__f, w, C, T, N.

"In the ... absence of lambda" makes no sense me, unless perhaps by "absence" you mean lambda=0.