o1bigtenor:
> My initial problem is a weighing 'cell'
> where I'm weighing liquids being deposited in a 'jar'.
> (A second would be items deposited (and then removed in stages) from a
> 4 wheel cart.)

So you will have, I guess:
one analogue in for weighing
a few buttons
perhaps a simple 7-seg. lcd for presentation

...
> Both of above systems will be connected to databases for information
> storage or is that just a data logger with subsequent not only storage
> but analysis.

A simple serial port will suffice unless you need it to be wireless.
On the receiving box with the databases you can use a usb-serial dongle
if you don't have any serial ports available.

> Guidance would be greatly appreciated.

For that, check how many pins you need for the lcd, and pick a smallish
arm M3 mcu with enough pins for the io above.

If you design you own electronics, then you can include all if. for
the weighting circuits on the same card, helps minimize the clutter.

Simple card examples are test.sch test.pcb in:
http://aspodata.se/git/openhw/boards_arm_aspo/stm32f100_test_board/

More complex, the .sch and .pcb files in:
http://aspodata.se/git/openhw/boards_arm_aspo/stm32f105_can/

You could also use arduino, beaglebone, rpi et. al. but you must
still handle the i/o, so not much would be gained by that.

////

> How does one decide when a RTOS is more appropriate than an OS?

You can program it:
. barebone
. with a rtos
. with a os

With the project you outlined above, programming this barebone would
suffice.

The step up to rtos is needed when you plan to have multiple processes
running. The rtos is actually just a lib you compile in.

The step up to an os is needed when you need to have protection between
processes, for that you need a mmu (memory management unit) and the
your cpu can run in some priviliged mode which is usually reached via
some trap mechanism so that the user processes cannot interfere with
the supervising os.

Regards,
/Karl Hammar