Thinking out loud again.
At the moment the Master sends a simple Interrupt style (Pull Slave Input High) data request signal to the first Slave, which sends it's Cell V data to the Master, that Slave then sends the same (Pull Slave Input High) data request signal to the next Slave in the Pack which transmits it's data and so on.
Now we have nice opto isolated comms, why not send commands rather than a simple send data/interrupt signal.
So now the Master sends the Interrupt style (Pull Slave Input High) data request signal to the first Slave followed by a Command/Data byte.
The command/data byte can tell the Slave to do anything, but let's assume if we send a 1 then the Slave sends it's Cell V data as before on the Master Bus. However instead of just passing the wake up signal it passes the command/data byte as well to the next Slave and so on.
So now we can send commands/data to the whole pack which may be very useful for calibration etc.
A few commands spring to mind
Send 1 = Slave transmit cell V (As now basically)
Send 2 = Slave adjust oversampling rate +1
Send 3 = Slave adjust oversampling rate -1
Send 4 = Slave adjust adc temp compensation (Not implemented yet!)
Send 5 = Slave go into sleep/low power mode
Send 6 = Slave adjust CPU speed
Send 7 = Slave adjust Cell V Max setting +.01v (Move balancing point up)
Send 8 = Slave adjust Cell V Max setting -.01v (Move balancing point down)
Blah Blah etc etc Anything else?
Anyhow I have incorporated this code/idea into Slave and Master software
Also been thinking about how I can send a specific command to a single Slave amongst the entire pack, whilst keeping all the Slave software identical 
If you had 50 different versions of the Slave Software, each with an ID number hard programmed in, say 1-50 then sending a command to the specific cell within the pack is quite easy.
1) Send Slave ID 1-50
2) Send command you want executed.
Each Slave receives and passes on the above but only acts on it, if it's ID matches the ID byte. However it's a nightmare to keep 50 different versions of the Slave Software updated and bug free
I could add some hardware to each slave board, perhaps some simple potential divider dip switch type arrangement so each Slave has a hardware code of sorts.
The answer I think is add the cell number of the target Slave to 128 (Say Slave 30 in this example) 128 + 30 = 158
1) Send 158, this tells the 1st Slave message is for onward transmission, but not for it because number > 128. The slave then deducts 1 from 158 and transmits 157 to next Slave along with the command that follows it.
2) Next Slave again tests number, and if > 128 then not for it, so deducts another 1 from total 157 - 1 = 156 and transmits to next Slave. etc etc
3) When it eventually reaches Slave (30) and number is 128, that Slave knows following command is to be executed.
So we now have two methods to update the Slaves on the fly.
A) Updates all Slaves in series by sending one command/data byte along Bus.
B) Update individual Slaves by sending target byte and command/data byte along Bus.
I'll incorporate this as we go along if I need to do individual Slave updates.
The BMS can cope with 128 cells per Master. This new scheme gives us 128 potential messages/commands to choose from, which can be sent to all or any one of the 128 Slaves now.
Pretty pleased with that
I've added a data bus testing/burn in routine to the Master Software.
This sends test values out through the Slave Data Bus and counts/checks each byte as it is received back on the Master Data Bus. For my 50 Cell pack each value should be received back by the Master 50 times as it propogates through the Slaves.
Latest Software as of 11:00 290708
http://www.solarvan.co.uk/bms/Master290708_v85.txt
2048 bytes out of 4096 available
http://www.solarvan.co.uk/bms/Slave290708_v66.txt
100 bytes out of 256 available
http://www.solarvan.co.uk/bms/Watchdog290708_v04.txt
24 bytes out of 256 available
There are quite a few ways to configure the Slaves as we can see.
We could also parallel all the Slave Data Bus opto's like the Master Data Bus but drive them simultaneously with a high current driver from the Master. Commands could be sent in a fraction of the time, responses would be problematic as each Slave would have to have a unique ID and different Software so it could respond with out all the Slaves jaming the Master Data Bus. In the cascade arrangement we have now the next Slave does not send the Interrupt style (Pull Slave Input High) data request signal to the next Slave until, it has finished transmitting itself.
I'm probably re-inventing the wheel with all this, but I'm enjoying it and learning a hell of a lot
Any Proteus guru's want to make me up the component or show me how!!
