Shop OBEX P1 Docs P2 Docs Learn Events
Nice project, but is it possible ... — Parallax Forums

Nice project, but is it possible ...

HenkieDHenkieD Posts: 8
edited 2008-01-03 18:17 in BASIC Stamp
Your opinions please ..

Next week meeting an old friend to investigate what and especially how he can monitor his machine park.
At this stage all machines are stand alone app's so there is no network.
The idea is to capture production specific data, like running hours, downtime, speed, etc..
To try to keep it as simple as possible (because we speak about approx. 100 machines) the stamps (one for each machine) should only send about 9 bytes to the master (4 analogues as two bytes each, 4 digitals as single byte), and of course a few for the protocol.
My question now, because there are different ways to get to Rome... What is the best one.
One more detail, the area we speak about is industrial, quiet hot and humid in summer (40 degrees and more), and around 100m by 50m.
Total lenght in cabling from node to node would be around 1000m.
Each machines details will be send 'raw', and interpreted (scaled and calculated) on the PC side and stored into a (SQL) database.

RS485 with the SN7516 (for example) and spread it over 3 to 4 networks (32 nodes maximum I think).
Wireless with each node a RF transceiver?
Personally, I prefer the second one because of the cabling, but how can I overcome the distance, can some nodes act as repeaters?
Your input will be much appreciated.

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2008-01-03 15:56
    It sounds like the various readings don't change quickly and you don't need speed. RS485 is probably the cheapest solution even though it requires wiring. Any kind of twisted pair cable should work and ethernet cable is readily available and suitable for industrial environments. You could use the RJ45 connectors. With two twisted pairs, you could dedicate one to transmission from the master and the other for transmission from the slaves.

    Simple polling would work. The master would transmit a request containing a slave number. If there's no response within some timeout period, the master could try again immediately or simply wait for the next cycle. The slave would normally wait for a request. If addressed, it would read its sensors and send back the data, otherwise it would just listen for a poll.

    You would want some kind of checksum on the poll and the returned data. Again, it might be easiest to just throw erroneous data away and wait for the next cycle. If a slave doesn't provide a valid response within a certain number of cycles, it would be flagged as inoperative and would need to be repaired.

    I would keep the Baud low, 2400 to 9600 Baud to reduce sensitivity to noise. Even at 2400 Baud, you could query all 100 slaves within 15 seconds.
  • FranklinFranklin Posts: 4,747
    edited 2008-01-03 15:57
    For the rs485 take a look at Jan08 nuts and volts article by Jon Williams. For the rf take a look at zigbee from several sources. xbee being the one I am experimenting with. If you go with the xbee make sure you get the series 2 as maxstream seems not to be supporting mesh networking on the series 1.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    - Stephen
  • steve_bsteve_b Posts: 1,563
    edited 2008-01-03 18:17
    I agree with Mike...RS485 and polling is pretty simple. Cheaper too!

    An RF version means you need a transceiver on each machine for polling.
    You Could "Time Slot" each one, but with 100 machines you'd probably have some issues with data resolution (assign 1second per unit and that's 100seconds -- good math eh!).

    X10 perhaps? Although it's still cheaper to buy the rs485 IC's AND run cable than to output 100 machines with an X10 device....it'd take longer to wire them all...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    <FONT>Steve



    What's the best thing to do in a lightning storm? "take a one iron out the bag and hold it straight up above your head, even God cant hit a one iron!"
    Lee Travino after the second time being hit by lightning!
Sign In or Register to comment.