@digerdiga The problem here is that the indefinite integral of fc is wrong. That surprised me.
 

restart;
f := ((1/2-I*t)^(-s)-(1/2+I*t)^(-s))/(2*I);
fc:=evalc(f);
## Checking that fc = f for s=2 on t=0..5:
plot(eval(f-fc,s=2),t=0..5); #OK zero
##
Fc:=int(fc,t) assuming s>1, t>0;
Fcdiff:=diff(Fc,t);
## Now Fcdiff and fc ought to be equal:
plot(eval(Fcdiff-fc,s=2),t=0..5); # Not zero
## ftoc and ftocms uses the Fundamental Theorem of Calculus.
## Thus the erroneous result is due to Fc being wrong:
limit(Fc,t=infinity) - limit(Fc,t=0,right) assuming s>1;
simplify(%);

The following session where printlevel is just the default 1 also makes the result 0:
 

restart; 
interface(typesetting=extended); 
debug(`shake/shake`);
evalf(frac(Pi^20)); # 0
printlevel; # 1

Also here the result is 23 if typesetting = standard instead.

Since the second session shows an error from Typesetting:

Error, (in j) invalid subscript selector

<-- ERROR in \`shake/shake\` (now in \`evalr/shake\`) = unexpected result from Typesetting}

I tried suppressing output as in
 

restart;
interface(typesetting=extended);
printlevel:=40:
evalf(frac(Pi^20)):
%;

The error didn't show up and the result was 23.

@farah adanan I tried your worksheet as given in the link. I used Maple 18.1. I found no problem.
I also checked Maple 15, 16, and 17.
The only problem appeared in Maple 15. It didn't like the local declaration at the start. That feature wasn't introduced yet.
The way you and Kitonum are using parameters via e.g. eval(eq1, fixedparameter1), the local declaration can be left out anyway since gamma is being replaced by the value 1 given in fixedparameter1.

Very nice.
Two comments on the worksheet itself:
1. You are apparently setting kernelopts(opaquemodules=false). Otherwise `pdsolve/BC`:-EvaluateBCAtSolution wouldn't work.

2. You have a line which in my downloaded version looks like simplify( Equality - Equality), which to the uninitiated obviously is zero and should be without simplify. Apparently some labelling is going on which I don't see, probably because I don't use labels ever.

@mmcdara Actually the result of dsolve(sys) doesn't look bad if the RootOfs are replaced by aliases (or just by names).
It seems that Im can decide if the roots areal.
 

restart;
sys := {
diff(tau__1(t),t)=phi__1(t),
diff(tau__2(t),t)=phi__2(t),
diff(phi__1(t),t)+2*phi__1(t)+3*phi__2(t)+4*tau__1(t)+5*tau__2(t)=6,
diff(phi__2(t),t)+8*phi__1(t)+7*phi__2(t)+9*tau__1(t)+10*tau__2(t)=11
};
sol:=dsolve(sys);
RO:=indets(sol,specfunc(RootOf));
Im~(RO); # {0} so all roots are real
Re~(RO); # Just returns the input consistent with all roots being real

I don't use alias very often, but here it might be useful:
 

alias(seq(alpha[i]=RO[i],i=1..4));
sol; # Short
evalf(sol);

Be aware of the following point in the help for alias:

"Because aliases are resolved at the time of parsing the original input, they substitute literally, without regard to values of variables and expressions.  For example, alias(a[1]=exp(1)) followed by evalf(a[1]) will replace a[1] with exp(1) to give the result 2.718281828, but evalf(a[i]) will not substitute a[i] for its alias even when i=1.  This is because a[i] does not literally match a[1]."

This implies that the following attempt to find floating point values for the roots won't work:
 

seq(alpha[i],i=1..4);
evalf(%); # no floats, just names
## The simple way works
RO;
evalf(%);

Ordinary names could be used instead of aliases as done here:
 

alias(seq(alpha[i]=alpha[i],i=1..4)); #Removing the aliases first
RO; 
#sol; # Now big
sol2:=subs(seq(RO[i]=alpha[i],i=1..4),sol); 

sol2 is as short as sol with alias, but of course evalf won't do anything about the roots in sol2.

A last comment: I tried evalc  in order to get an expression that also on the surface looks real:
 

r1:=allvalues(RootOf(_Z^4+9*_Z^3+4*_Z^2-19*_Z-5, index = 1));
r1a:=evalc(r1);

I succeeded in some attempts (after restarting) and other times it took too long for my patience.
By using indets(r1a,function) I found these:
{arctan(3/3268*sqrt(10275765)), cos((1/3)*arctan(3/3268*sqrt(10275765))), cos(2/3*arctan(3/3268*sqrt(10275765))), sin((1/3)*arctan(3/3268*sqrt(10275765))), sin(2/3*arctan(3/3268*sqrt(10275765)))}
All very good, but indets(r1a,radical) brought some square roots of not oviously positive quantities.

@annarita To get that error you must be using 2D input.
In 2D input a space is interpreted as multiplication. My code had a space between RGB and ( R() , R(),R() ).
While that is fine in 1D input (aka Maple input) it isn't in 2D input.
Just remove the space so that you have
 

 RGB( R() , R(), R() )

I tested your code in Maple 12 and Maple 15 besides in Maple 2018 and didn't run into any problems. I don't have Maple 13 on this machine.
The 3 results agreed after simplification.

@Carl Love odetest works fine on the implicitly given solutions regardless of the names or values of the constant.
On the explicit solutions having the RootOf odetest converts to an implicit form, which is seen by setting infolevel[odetest] to 2 or higher:
 

restart; 
ode := diff(y(x), x) = x*ln(y(x)):
sol:=dsolve(ode, implicit);
odetest(sol,ode); # 0
odetest(subs(_C1=C1,sol),ode); # 0
odetest(subs(_C1=1,sol),ode); # 0
explicit_sol:=op(solve(sol,{y(x)}));
infolevel[odetest]:=2:
odetest(explicit_sol,ode); # 0
odetest(subs(_C1=C1,explicit_sol),ode); # problem
odetest(subs(_C1=1,explicit_sol),ode); # problem

The procedure used for the job is `odetest/implicit`.

@pppc I used Q as a constant and should have mentioned it above.
The method still works for Q = (1/2)*q*(x-50)^2-1250*q, however, but you need to give q a value before plotting, e.g. q=1 as in

plot(eval(U, {C__1 = 0.12e9, C__2 = 0.2e10, C__3 = 0.2e9, C__4 = 0, C__5 = 0.3e8, q = 1}), x = 0 .. 100, size = [2000, default]);

@guto_vasques You simply forgot to write range = ... . Surely you meant to write:
 

p2b := dsolve(sys2, type = numeric, abserr = 1.*10^(-12), relerr = 1.*10^(-12), range=te .. tr);

@Carl Love In the help page dsolve, numeric, DAE we find the statement:
"The following options are also available for some or all of the DAE methods:
....
implicit = boolean
... "
I tried the first example given on the help page. It uses the methods rkf45_dae (the default), rosenbrock_dae, and mebdfi.
For the first two of these the option implicit=true was accepted and gave slightly different results than without thereby indicating that a different computation was made. With method = mebdfi and implicit=true the error message was

Error, (in dsolve/numeric) 'implicit' can only be used with the rkf45, ck45, rosenbrock, dverk78, lsode, classical or gear methods

@sherek The imaginary unit in Maple is by default named I (capital). You are using the letter i instead.
If you try
 

interface(imaginaryunit);

and the answer is I, then you have the default setting.
You can change to another name such as j if you wish (as some people in electical engineering do).
Just do
 

interface(imaginaryunit=j);

The response this time is the previous setting I. Don't let that confuse you.

As always an example of this error happening will help you get an answer.

It is easy enough to produce the error if you feed simplify with some nonsense as in this example:
 

simplify(xxx,a=yyy);

where xxx, yyy, and a are unassigned.
But I may assume you are not talking about nonsense like that?

@Christopher2222 As we agree (I think) the ball stops bouncing in a finite time.
When I said that if we don't stop at some finite number of hits, then dsolve/numeric will do it for us I was referring to that error/warning message. Also there is roundoff/truncation or whatever to take into account.
That the integration stops because of Event2 could be considered a more graceful stop than a stop due to maxfun exceeded, but it is probably not worth the trouble.

If we try 1000 hits and raise maxfun nothing much is obtained. Try e.g. maxfun=10^6. Then Event2 is triggered at 
t = 5.19806251391305  (try dsol(5.2)  ) .
Not a whole lot different from the setting of 100 hits, where Event2 is triggered at
t = 5.19790291862644. (again try dsol(5.2) ).
Note: If we try lowering abserr and relerr we easily run into warnings about a singularity.