All algebraic grouping in Maple is done with round parentheses ( ), not square brackets [ ]. No matter how deeply they're nested, they must be parentheses. Since the square brackets can be used for a variety of other valid purposes, they aren't usually flagged with an error when they're inappropriately used for algebraic grouping.

I'm not guaranteeing that correcting the brackets will get you to the final answer. Rather, I'm telling you that you must correct the brackets regardless. If you then still cannot get the final answer, post a Reply and someone will look deeper into it.

@José Goulart 

Regarding your "just wondering why it's so hard to rewrite expressions like that": For any operation, you need to tell Maple whether it should perform the operation or simply represent it inertly. Otherwise, how could it know? If the default action were to represent it inertly, then you'd just as well be saying "just wondering why it's so hard to to get Maple to expand products automatically." It's actually not that hard: Almost every operation has an inert form that can be made active with command value. The inert form uses % prepended to the operator.

restart;
interface(imaginaryunit= IU): #Make it any symbol other than I.
Ke:= (2*I*E/l^3) %* #Inert scalar multiplication
   <6,   3*l,   -6,   3*l;
    3*l, 2*l^2, -3*l, l^2;
    -6, -3*l,   6,    -3*l;
    3*l, l^2,   -3*l, 2*l^2
   >;

#When you want to expand the multiplication, use value:
value(Ke);

The above works in 1D input (aka Maple Input) in Maple 2018. I don't know about 2D Input. If it doesn't work for you, let me know, and I'll give you another form of the %* operator that's just a few more characters to type.

If eqs is a system of rational-function equations, as is the case here, then the simple command (numer@(lhs-rhs))~(eqs) will reduce it to an equivalent polynomial system. That alone is likely to give a boost to most solvers. If the system is equivalent to a linear system, as is the case here, then it's very likely (although not 100% guaranteed) that those polynomials will be linear. This will almost certainly improve the performance of any solver. Thus:

eqs:= {(T[1]-T[0])/(10000-T[1]+T[0]) = -2.000000000,
        (T[2]-T[0])/(20000-T[2]+T[0]) = 0,
        (T[3]-T[0])/(50000-T[3]+T[0]) = 50,
        .1*T[0]+.3*T[1]+.55*T[2]+0.5e-1*T[3]-.5 = 0}:
Sol:= fsolve((numer@(lhs-rhs))~(eqs));
        Sol := {T[0] = -8450.48039, T[1] = 11549.51961, T[2] = -8450.48039, T[3] = 40569.12746}
To be rigorous, we must verify that the solution works in the original equations because there is a
possibility of a 0/0-type undefined, which'd be flagged with a divide-by-zero error during the 
verification.
eval(eqs, Sol);
      {-2.000000000 = -2.000000000, 0. = 0, 0.000003 = 0, 50.00000036 = 50}

@Rariusz You need to translate the phrases "time", "input signal", "position of rotor", and "speed of rotor" into the variable names that you've used in the code. My guesses would be time = t, input signal = V, position of rotor = theta. I don't know about "speed of rotor"; perhaps that is diff(theta(t), t).

If V is a function of t, then V can't be used in a parameters option to dsolve. The syntax will allow it, but the results will be meaningless. You need to construct a function to interpolate V. This function can be symbolic or purely numeric. If it's purely numeric, than you'll need to declare it with dsolve's known option.

Your parameters should be [J, b, k, R, L]. These variables should not be assigned values prior to the dsolve call. By using Statistics:-Fit with procedure-form input and using the given values as initial values for these five variables, you can fit the parameters to the data in your file.

Unlike its ancestral language Algol, Maple's syntax doesn't allow a for-do statement in place of an expression sequence. Instead, use the seq command to create expression sequences inline. Replace your

for a in 'solve(diff(func, x) = slp, x)' do 'MMLV1'='MathML[Export]('y'=Tangent(func,x=a))' end do

with

seq('MMLV1'='MathML[Export]('y'=Tangent(func,x=a))', a= solve(diff(func, x) = slp, x))

You'll also need to adjust the unevaluation quotes, but I don't know enough about Maplets to fully correct them.

There are many methods to do this. I think that the one that is closest to what you were thinking is

map(eval~, [a*x, b*x], x =~ [p, q, t]);
 

While it is totally true, as Acer said, that do is not part of an if statement and that you don't want a loop in that position, that is not the proximate cause of your error. The cause is that every do needs to be matched with an end do (or od, or until (in Maple 2018)). If you replaced do return a with do return a end do, then your procedure would work, although there is no good reason to do this, and it makes your code confusing to read.

Note that your entire procedure (without the remember table) could be replaced by the one-liner: 

GCD:= (a::integer, b::integer)-> `if`(b=0, a, thisproc(b, a mod b)): 

The degree of a polynomial with  respect to x is analogous to its base-x logarithm. The logarithm of 0 is -infinity. Also note the exact correspondence between the identity stated by VV and log(f*g) = log(f) + log(g).

Here's a procedure that does all the constants in an expression at once, representing the result in the current system of units:

`combine/Constant`:= e-> 
   combine(
      evalf(
         subsindets(
            e,
            And(name, satisfies(x-> ScientificConstants:-HasConstant(x))),
            ScientificConstants:-Constant, 'units'
         )
      ),
      'units'
   )
:

Then, to use it on an expression such as your Rb, do

combine(Rb, 'Constant');

I realize that this is not an ideal solution; there ought to be an easier way, but I don't think that there is.

As far as I can tell, the convention is that when any Maple command returns a global name whose form has not been specified by the user, that name begins with an underscore _. The example that you show does follow that convention. If you find any command that deviates from that convention, it would be worth posting about it. The names beginning with underscore in any expression e can be extracted by

indets(e, suffixed(_));

What makes you think that your command  didn't work? The number returned by Export is the number of bytes written to the file.

Here's another way:

restart:
T:= table(sparse):
#Recast the permutation vector as a 3x3 matrix:
pm:= ArrayTools:-Alias(output((P:= Iterator:-Permute(1..9))), 0, [1..3, 1..3]):

#Then conversion to base-10 and summing can be done as a single vector-matrix-vector 
#product:
(o,t):= (<1|1|1>, <100, 10, 1>):
in P do T[(v:= o.pm.t)]:= T[v]+1 od:

#Group each number of occurences by the sums that attain it:
sort(
   [indices((lhs~)~(ListTools:-Classify(rhs, [indices(T, 'pairs')])), 'pairs')], 
   'key'= -lhs
);

#This is useful for further analysis:
X:= Statistics:-RandomVariable(
   EmpiricalDistribution(
      [indices(T, 'nolist')], 'probabilities'= [entries(T, 'nolist')]/~9!
   )
):

Statistics:-DensityPlot(X);

This shows both an early stage of convergence via the Central Limit Theorem and an amazing fractal pattern.

Here's one way to do it:

restart:
macro(DT= DocumentTools):
DT:-Do(%TextArea2 = eval(DT:-Do(%MathContainer0), [x= %TextArea0, y= %TextArea1])):

I am not very familiar with DocumentTools, and I suspect that there are numerous simpler ways to do this.

Of course there is no algorithm for that. That's light-years beyond the capability of any human or computer mathematician.

You should use the parameters. One reason is that if there's a bug in your code that's caused by misspelling a parameter, it can be easily found with maplemint. Why quibble about typing a hundred words, which is like a medium-length paragraph on MaplePrimes? This one has about fifty.

If I were writing the code, I'd put a comment, just a few words, after each parameter. The code will behave better if you respect it rather than mistreat it. Respect your code!