@Mac Dude 

Thank you Mac Dude, the Digits was a great suggestion.  At the end of the day it was a combination of strategies that proved a sufficient work-around: first, using fractions instead of floats until the absolute-last possible moment that you need them, and second: increasing digits to .. well, 20, since that's the example on the support/help page so why not.

Ultimately I was getting things like this for my solution to a homogeneous system of ODEs:

x53 = -500000*(1/1000*irc + r13)/irc/r26*(-1/10000000000000000000000000
00000000000000000000000*r38^2*irc^12*r26*r32*r33*r35*r36*r37 - 1/
1000000000000000000000000000000000000000000000*r38^2*irc^11*r26*r
32*r33*r35*r36*r37*r6 - 1/500000000000000000000000000000000000000
000000*r38^2*irc^11*r26*r32*r33*r35*r36*r37*r5 - 1/50000000000000
0000000000000000000000000000*r38^2*irc^10*r26*r32*r33*r35*r36*r37
*r5*r6 - 1/1000000000000000000000000000000000000000000*r38^2*irc^
10*r26*r32*r33*r35*r36*r37*r5^2-1/1000000000000000000000000000000
000000000*r38^2*irc^9*r26*r32*r33*r35*r36*r37*r5^2*r6)/(200020100
01/2000000000000000000000000000000000*r7*irc^8*r8*r16*r31^2*r37*r
32*r6 + 20002010001/2000000000000000000000000000000*r7*irc^7*r8*r
16*r31^2*r37*r32*r6*r13 + 20002010001/200000000000000000000000000
0000000*r7*irc^8*r8*r16*r31^2*r37*r32*r13 + 20022012011001/200000
0000000000000000000000000000*r7*irc^7*r8*r16*r31^3*r37*r6*r13 + 2
0022012011001/2000000000000000000000000000000000000*r7*irc^9*r8*r
16*r31^2 + 20022012011001/2000000000000000000000000000000000*r7*i
rc^8*r8*r16*r31^2*r13 + 20022012011001/20000000000000000000000000
00000000*r7*irc^8*r8*r16*r31^2*r6 + 20022012011001/20000000000000
00000000000000000*r7*irc^7*r8*r16*r31^2*r6*r13 + 20022012011001/2
000000000000000000000000000000000000*r7*irc^8*r8*r16*r31^3*r37*r6
+ 20002010001/2000000000000000000000000000000000000*r7*irc^9*r8*
r16*r31^2*r37*r32)

where the r's are parameters that span 1e0 to 1e-7.  It's an onerous system and seems to quickly overwhelm the default floating point precision used by Maple.  Everyone's suggestions were most appreciated! Thank you. Live and learn..

@Axel Vogt 

Thank you. I suppose calling it an "error" was inaccurate.  Maybe I just expected better from Maple for a substitution that I can do myself in my head.  I'll try using fractions instead, but I'm worried that in my specific case they'll blow up after calling simplify().

@Carl Love 

Two good suggestions, thank you.  In reality I'm substituting numerical values that span 1e0 to 1e-7 into a rather lenghty polynomial.  I'm worried that it might be difficult to find an appropriate epsilon for fnormal(), but it's worth a shot.  Using 1/10 (or 1/10000000) instead of a float is a good idea too.

What I'm trying to do is to substitute in parameters that I don't intend to monkey around with in subsequent numerical simulations.  The substitution would ideally reduce a polynomial that currently has several thousand terms down to something manageable.  I don't know how smart Maple is when simplifying polynomials with fractional elements.  As I recall the numerators and denominators just get bigger and bigger.  But also definitely worth a shot.