BSII Networking
Archiver
Posts: 46,084
On Fri, 14 Jul 2000, steve tatum wrote:
> Hello all,
> I'm working on an application that involves sequencing HVAC systems
> on a train. By this I mean that they can not all turn on at once b/c
> of the inrush current. There is one BSII controller per unit and I
> have 28 units (one unit per train car). I am using an RS485 data
> loop.
>
> Now here's the problem. I can't network
> using "Larry", "Curly", "Moe" or the "ping", "pong" topology that is
> described in the manuals b/c the "nodes" will be taken out of service
> and replaced with a new node that is not in any of the original 27
> (28-1=27) unit's program. Reprogramming the original 27 with this
> new node is not feasible. For the same reasons a master/slave
> network cannot be implemented either.
>
Why not assign each car's stamp with an address for that car and let the
units communicate using their addresses. You could have a "key" ( hard
wired header to simulate a dip switch pack ) that plugged into the unit in
each car that assigned the stamp an address upon power up. If you needed
to change out a stamp, the new one would assign itself the correct address
for that car upon power up after reading the "key". We used this back in
the early 80's to configure the controller boards in our network nodes.
Just a thought,
Dale Harwood [noparse][[/noparse] N4VFF ]
internet> dale@h...
ax.25> n4vff@n4vff.#cha.tn.usa.noam
#include <std_disclaimer.h>
> Hello all,
> I'm working on an application that involves sequencing HVAC systems
> on a train. By this I mean that they can not all turn on at once b/c
> of the inrush current. There is one BSII controller per unit and I
> have 28 units (one unit per train car). I am using an RS485 data
> loop.
>
> Now here's the problem. I can't network
> using "Larry", "Curly", "Moe" or the "ping", "pong" topology that is
> described in the manuals b/c the "nodes" will be taken out of service
> and replaced with a new node that is not in any of the original 27
> (28-1=27) unit's program. Reprogramming the original 27 with this
> new node is not feasible. For the same reasons a master/slave
> network cannot be implemented either.
>
Why not assign each car's stamp with an address for that car and let the
units communicate using their addresses. You could have a "key" ( hard
wired header to simulate a dip switch pack ) that plugged into the unit in
each car that assigned the stamp an address upon power up. If you needed
to change out a stamp, the new one would assign itself the correct address
for that car upon power up after reading the "key". We used this back in
the early 80's to configure the controller boards in our network nodes.
Just a thought,
Dale Harwood [noparse][[/noparse] N4VFF ]
internet> dale@h...
ax.25> n4vff@n4vff.#cha.tn.usa.noam
#include <std_disclaimer.h>
Comments
I'm working on an application that involves sequencing HVAC systems
on a train. By this I mean that they can not all turn on at once b/c
of the inrush current. There is one BSII controller per unit and I
have 28 units (one unit per train car). I am using an RS485 data
loop.
Now here's the problem. I can't network
using "Larry", "Curly", "Moe" or the "ping", "pong" topology that is
described in the manuals b/c the "nodes" will be taken out of service
and replaced with a new node that is not in any of the original 27
(28-1=27) unit's program. Reprogramming the original 27 with this
new node is not feasible. For the same reasons a master/slave
network cannot be implemented either.
I am trying to implement a "broadcast" type network. Meaning that,
let's say, node 1 would send the $FF serial output to alert any other
nodes listening that it is about to turn on its HVAC. The other
nodes would be Polling periodically, timing out if no data is on the
line and continuing with the program. However, this does leave a
window of opportunity for another HVAC to turn on when a node is not
listening and therefore they could both turn on at the same time.
Would the flow control pin be the answer?? What if the other nodes
are not listening at that particular time when you pulse the fpin??
What happens if several nodes try to transmit data at the same time.
An interrupt would solve the problem, but I do not believe that the
BSII this capability.
Any ideas out there??
>Hello all,
>I'm working on an application that involves sequencing HVAC systems
>on a train. By this I mean that they can not all turn on at once b/c
>of the inrush current. There is one BSII controller per unit and I
>have 28 units (one unit per train car). I am using an RS485 data
>loop.
>
>Now here's the problem. I can't network
>using "Larry", "Curly", "Moe" or the "ping", "pong" topology that is
>described in the manuals b/c the "nodes" will be taken out of service
>and replaced with a new node that is not in any of the original 27
>(28-1=27) unit's program. Reprogramming the original 27 with this
>new node is not feasible. For the same reasons a master/slave
>network cannot be implemented either.
>
>I am trying to implement a "broadcast" type network. Meaning that,
>let's say, node 1 would send the $FF serial output to alert any other
>nodes listening that it is about to turn on its HVAC. The other
>nodes would be Polling periodically, timing out if no data is on the
>line and continuing with the program. However, this does leave a
>window of opportunity for another HVAC to turn on when a node is not
>listening and therefore they could both turn on at the same time.
>Would the flow control pin be the answer?? What if the other nodes
>are not listening at that particular time when you pulse the fpin??
>What happens if several nodes try to transmit data at the same time.
>
>An interrupt would solve the problem, but I do not believe that the
>BSII this capability.
>
>Any ideas out there??
>
>
Hi Steve -
Take a look at the S.N.A.P. protocol [noparse][[/noparse] www.hth.com/snap/ ] . It is a
freeware, open,
scalable, networking protocol originally developed for use with the PLM24
system which can be found at the same web site [noparse][[/noparse] ... (as above) /PLM24/ ] .
It adapts very nicely to other uses.
A small subset of this protocol might be exactly what you are looking for.
Examples, suggestions, complete documentation, as well as code segments are
all downloadable from that site. This is also the home site of L.O.S.A.
which is the List Of Stamp Applications, an effort HTH to provide a place
for documenting Stamp Applications [noparse][[/noparse] www.hth.com/losa/ ] .
Hope that helps.
Regards,
Bruce Bates
you are thinking about one where the data lines are in parallel (i.e. all
nodes get the data at the same time). What if the data were serialized,
using a token based topology?
Here's my idea:
When a unit wants to turn on its HVAC, it sends out a token corresponding to
its unique number (1,2,3,etc).
The token gets passed from one node to another in the chain.
Once the token comes back, the unit turns its HVAC on.
Case where another unit wants to turn its HVAC when another unit is already
sending around a token:
If a unit receives a token while waiting for its own token to arrive, it
compares the token received to itself. If the received token is less in
priority (you decide what constitutes less priority), it will discard the
incoming token. Each unit would have a specifed time out waiting for its
token before sending out another token.
Case where the unit turns its HVAC on and waiting for inrush to die down:
In this mode, unit will indescriminately discard ALL tokens until specified
time when in-rush has died down.
One of the advantages I see is that this system is scalable. Also, worst
case scenerio is that if a unit is not "listening" when it receives a token,
the original unit wont turn its HVAC on (fail safe). However, there may be
some unique logic situations I may be missing, so be sure to step through
this carefully.
Also, I am a newbie to Basic Stamp programming, so I am unsure how this
would be implemented.
Hope this helps..
--Craig
Original Message
From: steve tatum [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=TilB6lXI6XH-4N76ZdyetVMy2bSARZLNk1o2hbkgwjlwXortzU5UJ7NEqdvQ44v1t6NjUgWoKsQW4j0]swt@p...[/url
Sent: Thursday, July 13, 2000 9:35 PM
To: basicstamps@egroups.com
Subject: [noparse][[/noparse]basicstamps] BSII Networking
Hello all,
I'm working on an application that involves sequencing HVAC systems
on a train. By this I mean that they can not all turn on at once b/c
of the inrush current. There is one BSII controller per unit and I
have 28 units (one unit per train car). I am using an RS485 data
loop.
Now here's the problem. I can't network
using "Larry", "Curly", "Moe" or the "ping", "pong" topology that is
described in the manuals b/c the "nodes" will be taken out of service
and replaced with a new node that is not in any of the original 27
(28-1=27) unit's program. Reprogramming the original 27 with this
new node is not feasible. For the same reasons a master/slave
network cannot be implemented either.
I am trying to implement a "broadcast" type network. Meaning that,
let's say, node 1 would send the $FF serial output to alert any other
nodes listening that it is about to turn on its HVAC. The other
nodes would be Polling periodically, timing out if no data is on the
line and continuing with the program. However, this does leave a
window of opportunity for another HVAC to turn on when a node is not
listening and therefore they could both turn on at the same time.
Would the flow control pin be the answer?? What if the other nodes
are not listening at that particular time when you pulse the fpin??
What happens if several nodes try to transmit data at the same time.
An interrupt would solve the problem, but I do not believe that the
BSII this capability.
Any ideas out there??
> ...I'm working on an application that involves sequencing HVAC
> systems on a train. By this I mean that they can not all turn on
> at once b/c of the inrush current. There is one BSII controller
> per unit and I have 28 units (one unit per train car). I am using
> an RS485 data loop... Any ideas out there??
An intriguing problem. Here's a concept-level potential solution you
may wish to consider and develop:
- Give each of your Stamps a unique number ID in EEPROM (DATA
statement) say from 1 to 30. Each Stamp's number remains the
same regardless of its position or presence in the train.
- After the cars are assembled, initialize your network to include
determining the IDs of all Stamps on board. You could conceivably do
this with a master that polls for Stamp #1, then #2, then #3 etc.
- When polled, the Stamp answers back with its ID or the complement
of its ID or whatever to announce its presence
- After being polled, it listens to see which ID responds next, if
any. It remembers which comes next (or, in the case of the last to
respond, the first Stamp ID).
- After initialization, the master could poll the Stamps in sequence
to permit HVAC switching. Or, the master could be removed and the
Stamps could do token-passing from then on to pass HVAC-switching
permission from one to the next. The trick here would be effective
token passing so it doesn't get dropped...
Steve
> I am new to token passing. Could you please send me a quick few
> lines of code to give me an idea of how this works. I can't use
> the master/slave topology b/c the master could be taken out of the
> loop at any time.
In this instance it could be described as simply taking turns, in a
round robin fashion, at taking care of any required switch actions.
The Stamp with the "token" is allowed to turn things on--all others
must wait until they are passed the token.
Imagine that Stamps #2, #5 and #8 are on the loop (I know your real
requirement is larger, but this illustrates the point). During the
initialization I described in the prior msg, it is known that Stamp
#2 is the first (lowest numbered) on the network. It gets the token
first. If it has switching to accomplish, it does so. Then it
passes the token on to #5. #5 similarly does/doesn't switch as
needed, then passes the token to #8. #8 does the same and passes the
token back to #2, etc. It's a virtual token we're talking about.
Controlling the passing of the token would be the crux of the
problem.
For starters in the example above, I'd try #2 broadcasting '5' on the
net when #2 is ready to pass the token. Until it receives a '5' in
reply (presumably from #5), it repeats sending '5'--#5 may have been
busy doing other things and missed its queue. When #5 responds with
'5', consider the token passed. To make the scheme more robust, add
a timeout feature (e.g., #2 decides it's been too long since anybody
passed the token, so it starts things over) or other error
detection/correction goodies.
FWIW, token passing is normally used to control which of several
peers is allowed to transmit to the network at any time. This is
much like your requirement, since it involves singular access to a
common resource.
Steve
code to give me an idea of how this works. I can't use the master/slave
topology b/c the master could be taken out of the loop at any time.
Thankx for your help so far.
Original Message
From: S Parkis [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=27YJtwwwVYff7Z6GD6fjfQnXBAir8CDC-s2N2QtcmpITvvzv5D8npT-p3K2LLL7zLhmnnbS4NTGHsvgstBR8Og]parkiss@e...[/url
Sent: Friday, July 14, 2000 3:52 AM
To: steve tatum; basicstamps@egroups.com
Subject: Re: [noparse][[/noparse]basicstamps] BSII Networking
On 14 Jul 00 at 1:34, steve tatum wrote:
> ...I'm working on an application that involves sequencing HVAC
> systems on a train. By this I mean that they can not all turn on
> at once b/c of the inrush current. There is one BSII controller
> per unit and I have 28 units (one unit per train car). I am using
> an RS485 data loop... Any ideas out there??
An intriguing problem. Here's a concept-level potential solution you
may wish to consider and develop:
- Give each of your Stamps a unique number ID in EEPROM (DATA
statement) say from 1 to 30. Each Stamp's number remains the
same regardless of its position or presence in the train.
- After the cars are assembled, initialize your network to include
determining the IDs of all Stamps on board. You could conceivably do
this with a master that polls for Stamp #1, then #2, then #3 etc.
- When polled, the Stamp answers back with its ID or the complement
of its ID or whatever to announce its presence
- After being polled, it listens to see which ID responds next, if
any. It remembers which comes next (or, in the case of the last to
respond, the first Stamp ID).
- After initialization, the master could poll the Stamps in sequence
to permit HVAC switching. Or, the master could be removed and the
Stamps could do token-passing from then on to pass HVAC-switching
permission from one to the next. The trick here would be effective
token passing so it doesn't get dropped...
Steve
the unit (e.g. 0001 for 1, 1111 for 15). This bit stream would be passed
from one unit to another, much like a "bucket brigade". Ever see how people
put out fires without firetrucks and pumps - passing a bucket of water from
one person to another?
I can give you a quick pseudo-code example..
Example with a total of three units: Each unit has a data in and data out
pin. The pins of each unit would be wired to one another in series - e.g:
Data out of unit 1 would be wired to data in of unit 2, Data out of unit 2
would be wired to data in of unit 3, Data out of unit 3 would be wired to
data in of unit 1; competing the circuit.
If a unit wants to turn the HVAC on, it sends out its unique token on its
data out pin.
It waits for that token to return on its data in by polling its data in pin.
When the token returns, the unit turns its HVAC on.
When a unit is idle it polls for tokens on its data in pin
When it receives a token it merely echos the data received onto its data out
pin.
Now, here is where the logic gets a little messy:
If a unit has already sent a token and is waiting for its token to return,
but receives a token from another unit.
You could pass the token if it is a higher value than itself, but not pass
it if it is lower or vice-versa depending on your application.
If a unit has recently turned its HVAC on, the unit would not poll the data
in pin for a preset time (until in-rush died down). Hence, any tokens
passed at that time, would not get passed along in the chain; preventing
another HVAC from turning on.
Each unit would also have a preset timeout waiting for its token to return
before retrying.
No master slave relationship used here, and units can be pulled out and
replaced at will - the only caveat here is that the data circuit can not be
broken and each node must have a unique number.
--Craig
Original Message
From: Steve Tatum [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=zPQ2e0bs4tUka2DBT7ZDj58rSmfR1TxRk_9Ck8tP5HYsA9N2pD6QvB--sAxd1H1qgDlN5mDZngQF57g]swt@p...[/url
Sent: Friday, July 14, 2000 9:46 PM
To: basicstamps@egroups.com
Subject: RE: [noparse][[/noparse]basicstamps] BSII Networking
Importance: High
I am new to token passing. Could you please send me a quick few lines of
code to give me an idea of how this works. I can't use the master/slave
topology b/c the master could be taken out of the loop at any time.
Thankx for your help so far.
Original Message
From: S Parkis [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=Pwl-lFVcvAnlu3LsgoK_a7_zC2ZVGNmDvic242Z-4icv4GpWtBdeZKa6QtD3A7nZw8DFraFIrpuZD6cJ]parkiss@e...[/url
Sent: Friday, July 14, 2000 3:52 AM
To: steve tatum; basicstamps@egroups.com
Subject: Re: [noparse][[/noparse]basicstamps] BSII Networking
On 14 Jul 00 at 1:34, steve tatum wrote:
> ...I'm working on an application that involves sequencing HVAC
> systems on a train. By this I mean that they can not all turn on
> at once b/c of the inrush current. There is one BSII controller
> per unit and I have 28 units (one unit per train car). I am using
> an RS485 data loop... Any ideas out there??
An intriguing problem. Here's a concept-level potential solution you
may wish to consider and develop:
- Give each of your Stamps a unique number ID in EEPROM (DATA
statement) say from 1 to 30. Each Stamp's number remains the
same regardless of its position or presence in the train.
- After the cars are assembled, initialize your network to include
determining the IDs of all Stamps on board. You could conceivably do
this with a master that polls for Stamp #1, then #2, then #3 etc.
- When polled, the Stamp answers back with its ID or the complement
of its ID or whatever to announce its presence
- After being polled, it listens to see which ID responds next, if
any. It remembers which comes next (or, in the case of the last to
respond, the first Stamp ID).
- After initialization, the master could poll the Stamps in sequence
to permit HVAC switching. Or, the master could be removed and the
Stamps could do token-passing from then on to pass HVAC-switching
permission from one to the next. The trick here would be effective
token passing so it doesn't get dropped...
Steve