Problems with "solve" Mathcad 10

The symbolic solver normally doesnt know about units, treats them as undefined variables.

You may want to switch on the Calculation Option "Units/Constants in symbolics".

Success!

Luc

Turning on the option "Units/Constants in Symbolics" sure is a good idea and you should have turned on on per default.

But it doesn't tell the symbolics the meaning of predefined constants and relationship between units, it just lets the symbolics retain the labels "Unit" and "Constants".

Without this option enabled:

Note on the right hand side that the symbolics turned the unit m to a  normal variable m (its not set in bold blue anymore).

That way you would run into troubles if you try to evaluate the 'result' numerically:

This is what turning on the option cures:

Note that the 'm' on the right hand side now is still correctly labeled as unit and so the numerical evaluation works OK:

But even with the option active, the symbolics knows nothing about the relationship between different units or the definition of constants.

You see that the symbolics does not know how seconds and minutes are related or how the gravitational constant is defined. It regards all these quantities as independent unknown variables. But since the labelling as a unit is not lost when the appropriate  option is activated, the result expression can at least still be evaluated numerically (or saved in a variable).

The shortcoming that the symbolics cannot handle units is not new in Prime 10. It was exactly the same in all previous versions and was no different in real Mathcad (version 15 and before)!

So concerning your problem #1 it should be now clear that the symbolics is not able to come up with 672 N as result, but you simply could numerically evaluate the symbolic result to get the desired display

or assign the result to a variable and evaluate it numerically

And of course you don't need the symbolics at all for this simple equation and can use either a solve bock with "find" or the "root" function as already suggested by Luc.

You may use the "root" function either by providing an initial guess value

or by providing two values, one to the left and the other to the right of the expected zero

Of course you could also teach the symbolics how to handle the constant of gravity and how different units are related so that it could arrive at the desired result, but I would consider this too much effort for a a very modest achievement:

According your problem #2:

---

This one is supposed to give 0,87kN

---

No! Sure not! Where should the unit kN stem from? The unit meter cancels, no other unit is in play and so of course the result must be a dimensionless number!

The symbolics does not know anything about the definition of "deg" or its alias "°".

So either define your angle in radians

Or you may also (re)define the 'unit' "deg" before you use it the first time, so that the symbolics knows how to deal with it:

The symbolics returns an exact result if possible and if you rather prefer a numeric result from the symbolics you have to use the modifier "float,...".

If you wish to see the result as a force, you would have to define the first factor "3" as being a force

There is also one way to get the desired result without having to use radians or redefine "deg". You may use a numeric inline evaluation when defining the angle. That way the variable is assigned that numeric value and the symbolics will use it. But doing so you won't get the exact result.

And as you are just dealing just with numeric results, you also could do without the symbolics at all and use Primes numeric methods, e.g. again the "root" function

Using the symbolic engine most of the the times is not necessary when just dealing with numeric results.
Advantage of the symbolics is that it can handle unknowns, undefined variables.
So you could set up a function for B.y which depends on the force (3kN), the two lengths involved and the angle. This should be done before any of these variables are defined.
You can now use this function (numerically evaluated) to immediately see the effect different input values may have:

But to make it clear once more, both problems you experienced aren't new - its the very same in older versions as well.
It has nothing to do with a new version of Prime or with the new computer you are using now.