Home AMX User Forum AMXForums Archive Threads AMX Hardware
Options

VSTAT ICSNet vs RS-422

I have a big job that will require 40 VSTAT thermostats and I am wondering which is the best approach: ICSNet or RS-422? I taked to tech support and they recommended the ICSNet. Any ideas which one is better? Here is what I have gathered so far:

ICSNet:
- Faster communications via CAT-5 (10Mbits)
- No need to address, all VSTs stay on ID 1, what is different is the DEVICE number under Netlinx.
- More expensive to implement

RS-422:
- Slower Communications
- Requires multiple dist-boards
- Cheaper to implement

I am going to have probably 30 Modero panels accesing the HVAC info and receiving feedback all the time on this project.

Any ideas and suggestions?

Thanks,

Ricardo

Comments

  • Options
    ICSNet vs 422

    In a 40 thermostat installation with 30 touch panels use the ICSNET version. The latency of 40 thermostats waiting to communicate on the 422 buss will make the system feedback very sluggish.

    One correction, ICSNET is 625 kilobits per second.

    Good luck,

    Rex
  • Options
    joelwjoelw Posts: 175
    ICSNet: Echelon Neuron chip connected to an RS-485 transciever.

    The Neuron handles the network arbitration etc. With RS-422 the MCU and software handles network arbitration etc. You're better off using the ICSNet version, it presents less load to the MCU, and provides higher bandwidth.
  • Options
    yuriyuri Posts: 861
    how are you going to use ICSNet? daisy chaining or each device on its on link? if you daisy chain them, failing of one unit kinda kills the entire network...
  • Options
    VSTAT ICSNet vs RS-422

    The ISCNet minivertor installed on the themostats does not have a passthrough connection. You must use ICSNet hubs.

    Rex
  • Options
    ericmedleyericmedley Posts: 4,177
    In your situation, the ICSNet seems the best advice. However, here's a warning I have about that solution. If one of the Minverters goes bad for any reason, it takes down the whole ISCNet and then the Master itself.. I'm experiencing this right now in an istallation we have that has 6 ViewStats.

    We suspect that the HVAC guy zaps the system when he comes a callin'. When one of the Miniverters gets zappped the ICSNet gets flooded with error messages. You'll not see those messages with your normal stuff like NetLinx Diagnostics. The Tech support folks can see it thier ND-Pro or whatever it is they have. The master gets bogged down handling the errors and eventually hangs. The only solution is pull the miniverter out. Bear in mind that all this time I get not one error or Offline event or anything to indicate that someting is wrong. My first indication is that the client says the whole system is acting sluggish.

    I'm actually considering going to an all RS-XXX situation because I can at least see and handle the errors myself. I'm not at the mercy of ICSNet errors that I cannot see or deal with.

    However, in your situation, 40-some thermostats is a bit much to handle with 40-some RS-XXX ports.

    Hope that helps.
    ejm
  • Options
    DHawthorneDHawthorne Posts: 4,584
    The RS-232/422 solution only requires one serial port. They buss together and report by address. With the neat little distribution panel you can get for them, I find it a much more service and installation friendly way to do it. Cheaper too, the ICSNET expansions get rather pricey.
  • Options
    alexanboalexanbo Posts: 282
    Perhaps if you do go RS-485 you'd want to break the TSTATs into sub groups, ie 5 groups of 8 so as to get around some of the latency problems with the RS-485. You'd use up some extra ports but you wouldn't have to wait the 40 only 8 timeslots every time you sent a command.
  • Options
    ericmedleyericmedley Posts: 4,177
    DHawthorne wrote:
    The RS-232/422 solution only requires one serial port. They buss together and report by address. With the neat little distribution panel you can get for them, I find it a much more service and installation friendly way to do it. Cheaper too, the ICSNET expansions get rather pricey.

    How does this system handle collisions between devices if they are on the same buss? Do the thermostats practice 'good manners' and not attempt to communicate if another device is sending/recieving? I assume it is done somehow since it seems to be a working solution.

    Just curious because, like I said earlier, the ISCNet thing is just not working for me due to the fact that the communication errors do not get reported to me. You can't even see them in NetLinx Diagnostic. AMX's reason for not reporting these errors is that it would give us too much info about under the hood. (This from one of the Tech Support guys who's name shant be mentioned here...)

    What you're decsribing is somewhat exciting to me as this has been a thorn in my side for some time and I've really been kluge-ing together things to get a grip on it.
  • Options
    DHawthorneDHawthorne Posts: 4,584
    ericmedley wrote:
    How does this system handle collisions between devices if they are on the same buss? Do the thermostats practice 'good manners' and not attempt to communicate if another device is sending/recieving? I assume it is done somehow since it seems to be a working solution.

    Just curious because, like I said earlier, the ISCNet thing is just not working for me due to the fact that the communication errors do not get reported to me. You can't even see them in NetLinx Diagnostic. AMX's reason for not reporting these errors is that it would give us too much info about under the hood. (This from one of the Tech Support guys who's name shant be mentioned here...)

    What you're decsribing is somewhat exciting to me as this has been a thorn in my side for some time and I've really been kluge-ing together things to get a grip on it.
    It's standard RS-422; collision management is built into the protocol. I'm not real up on all the finer points, but my understanding is that 422 devices wait for the buss to be inactive for a certain period of time (in milliseconds) before transmitting. But it's handled on the hardware level, so it's very fast, and the packets small enough that it doesn't represent any noticable delays.
Sign In or Register to comment.