Mindboards

Doc Helmut requested some programs for NXTs to act like large motor and sensor multiplexers. Well, after maybe 15 hours, I have a test release ready. It has only gone through minimal testing (I didn't even test all the functions), and with only one slave.

In theory it supports up to 31 slave NXTs (multiplexers), and you can remotely configure analog sensors, and do some simple motor control.

For sensors, you can configure type and mode (or use the equivalent of SetSensor). You can also read the normalized values, as well as the RAW values. I have communication support for all four ports, but on the slave I disallowed it from over-writing the type and mode for port 4 (otherwise RS485 might get disabled).

For motors, you can use commands similar to OnFwd, OnFwdEx, OnRev, OnRevEx, Off, OffEx, Coast, and CoastEx. You can also set a desired position, and the slave will use the EFW implemented APR to try to achieve the position (not perfect, but it's good enough for me). You can read the MotorTachoCount, or issue the ResetTachoCount command. Take a look at the included example.

This is all taken care of in the APIs, but there is a command "register" for each of the motors. Here is a list of the values supported: Basically, all the functions keep the same API names, except I added the term "Mux" to the beginning of them all, and there is an extra parameter you must pass (the slave ID). Also, the motor commands (OnFwd, Off...) do not reset the encoders. You must use the Ex counterpart, and specifically tell it to reset the encoders.

Never pass a slave value of > 30 to any function. The valid range is 0-30, and the functions do not clip the value. You can either use the values 0 through 30, or RS485Mux1 through RS485Mux31. If you look near the top of the master library, you'll see a global variable named "RS485ActiveSlaves", initialized with the value of 0x00000001. That is a control for what RS485 slaves it will try to communicate with. Each bit represents a slave. being set to 1 would mean slave one is enabled. 2 means slave 2 is inabled. 3 means slave 1 and 2 are enabled...

Since the only thing the slave does is monitor RS485, and send and receive values I didn't think it was necessary to put the task in a "library". I might change that later though.

Make sure you #define RS485AddressMine to something like RS485AddressSlave1, and make every slave is unique (numerical value 1-31).

I have only done a little testing so far. Please let me know of any problems you find (there are bound to be a lot).

Included in the .zip file:
- the master library
- an example program for the master
- the slave program (its the only thing the slave does, so it is a program instead of a "library")
- my RS485 library, on which the programs rely heavily
- my math library

thx for your efforts, matt, I'll try it asap, possibly tomorrow afternoon and next weekend.
Is there also a way to pass e.g., an array[129]of byte from master to all slaves?
And how would it be possible to return back values other than sensor values from all slaves back to the master , e.g. 6-10 of char, int, or long ?

The way my RS485 library is setup, the master can only send to one slave at a time. Furthermore, the buffer size is limited to 128 bytes, and my library currently uses 3 or 4 bytes overhead. So, using my library you could send or receive up to 124 or 125 user-bytes. The multiplexer stuff uses 28 user bytes one way, and 27 user bytes the other way. I want to add NXT battery voltage support as well, which would be another 2 bytes.

If you need to implement more than the multiplexer communication, you have about 96 bytes available, but you are going to need to implement that into the Mux task (or else do some tricky stuff).

Or, I could add another command bit to the command byte, to specify it's a Mux message. The slave would only implement that data as a Mux if the bit is set, otherwise it would know it's a user-data message.

Or, I could revise the receive functions to not require to know how many bytes are being sent, and all messages could be dealt with in the user-code (not the RS485 library). This might take slightly longer (1-2ms), but maybe not.

I think I like the last of those three options the best.

Just curious, how soon do you need the master to have access to the 6-40 user bytes? I mean, is 250ms okay? or does it need to be more like 25ms?

hi matt,
if the remote sensor data come quickly (<=20ms) then the rest may take far longer (>=250ms)

ps:
as 1 sensor port will be missing at each NXT, and because there always is a lack of I/O ports at every NXT, for further deveopment also support for sensors attached to multiplexers (e.g., sensors at HT touch muxers or HT sensor muxers) would be desirable!

The HT Touch mux is analog, so that is already supported.

The HT sensor Mux is I2C, and my programs do not support any I2C sensor. There is a huge variety in digital sensors, so all I2C "multiplexing" will probably need to be implemented at a user-level. There is no way to predict what the user might want, so I won't even try.

However, I might add support for the lego ultrasonic sensor, since that is a very common sensor.

BTW, have you done any testing with it yet?

no, it's not Wednesday afternoon yet in central Europe ;)
(all my motors and sensors are installed in my robot constructions, it will not be easy to make a test platform out of it. I will have to incorporate your code into my chess code and then try to use my chess robot as a test platform for your rs485 headers then instead of my BT headers - which will require first of all lots of modifications and rebuildings)

You may handle sensor values just like user calculation data then it will make no difference if one reads an analog sensor, an i2c sensor or if one wants to pass a calculated intermediate variable value.
Multiplexers I surely will need, I already have applied or planned all sensors to all ports of all NXTs, so muxers and i2c support also for MS, HT, Dexter, and homebrewed sensors (like the MightyBoard) would be indispensable for future use (especially because now 1 sensor port each has to be dropped for rs485).
E.g., the MightyBoard uses 8 sharp sensors which I am using for object detection and claw control of my service bot on the 1st or the 2nd slave, and overall 8 touch sensors at 2 NXTs will now require touch muxers. A sensor muxer is needed for 1 US sensor plus 1 gyro plus 1 compass plus 1 accelerometer sensor at 1 NXT port.

I am working on rebuilding the base RS485 functions that the Mux stuff is built on. It should soon support user-data.

The problem with supporting I2C sensors, is that there are so many options (really, and infinite number). I might support some common stuff, but I will leave the rest up to the user-code.

starting to implement your examples...
what are these motor remote commands doing with the 1st line?