So, what happens if you do

read lampstart;

after executing the script that you showed?

I think that you need to post the full code, because the following simple example works for me:

A:= <<10*Unit(m)>>:
B:= <<20*Unit(m)>>:
A+B;

This works for me regardless of whether I load a Units package.

@Carl Love Please see the last line that I added to the Answer about ToInert,

@Joe Riel You said that "Maple has a decent programming language." Is there a feature in any other language that you think is better? One thing that I'd add is the ability to set the precedence of neutral operators, but I don't know if any other language has that.

@Carl Love Does the above Answer do what you want?

@Carl Love The way that you worded the Question made it seem as if the dice were distinguishable---that there's a "first" die and a "second" die, possibly with different spot distributions. In that case, my Answer stands as is. However, Kitonum's Answer made me realize that your implication that they were distinguishable (by saying "the second") was perhaps unintentional. If that's the case, you could use

Implies(Or(And(d1::even, d2::odd), And(d1::odd, d2::even)), d1+d2 <= 9);

In either case, the purpose of my Answer, as per your request, is to generate an inert expression that prettyprints in standard logical notation; its purpose, unlike Kitonum's procedure, is not to evaluate the truth of that expression.

I haven't worked on your problem simply because I don't like its input format. I know (from your emails) that you've read my extensive Post on boundary layer flow problems, "Numerically solving BVPs that have many parameters", and that the output (plots) that you want are very similar to my output in that Post. Please download the worksheet attached to that Post. Following my format, edit the beginning of that worksheet to use your ODEs, parameters, and boundary conditions. Do this using the Maple Input (1D input) like I have used. If you don't use that format, I won't read it.

Then enter into that worksheet the specifications for the output that you currently have in your attached .docx file. You can enter these into ordinary text fields. Then upload the edited worksheet to this thread.

If you need to discuss anything, please put it in this thread rather than sending me email.

@nm I wonder why your simplify doesn't cancel the 2 in the second term. Mine does.

@Carl Love My procedure above places the denominator of a numeric fraction coefficient in the numerator, which probably isn't wanted. Here's an updated procedure that handles them:

Apparent_Numer_Denom:= proc(e::`*`)
local F,R,N,D;
    (F,R):= selectremove(type, e, fraction); 
    (D,N):= selectremove(type, R, anything^negative);
    (numer(F)*N, denom(F)/D)
end proc:

Apparent_Numer_Denom(expr2); #Acer's expr2

@Anthrazit Applying evalb to the condition in an if statement is superfluous; it's done automatically.

@Test007 I didn't "come up with" any of the constants. The symbolic work is all done by dsolve, evalc, and limit.

The same process could be applied to the constant-coefficient ODE that you propose. Below, I treat the monic case, which covers all the cases with a second derivative:
 

Download ConstCoeffODE.mw

@Test007 I suppose that the feeling is that that situation can always be handled with eval. 

@tomleslie A procedure's behavior should not rely on the user having issued a certain with command at the top level, simply because the user may not have.

@nm Simpler:

add(ArrayTools:-Diagonal(A)^~2);

@Scot Gould As you proposed in an earlier version of the above Reply, the potential problem of using global t can be corrected with quotes:

drdt:= t1-> eval(diff(r('t'),'t'), 't'= t1):

Without the quotes, the following would give an error message, even if the assignment to t were totally unrelated to its use with r (such is always the risk with global variables):

t:= 3;
drdt(0);