I may think there may be some further comments regarding this topic, as follows:
- RS485 is supposed to be a two wire network, which isn't exactly true. Ground potential differences between connected devices may cause a lot of trouble. Both devices having different power supplies will do for this situation quite fast. Line termination and polarization, as already suggested, may not always help, as introduced potentials may be higher than the threshold potentials defined by the line transceivers. Best solution I found was running a third wire to level ground potentials of connected devices, and this shouldn't be using some eventual shielding available on the twisted pair, as this layout may produce so called ground loops, and remedy could be worse than illness. Having a third wire, may not be the only issue to solve a ground potential problem, and some depends on how the power supply layout is done. Best way to have no problems is having just one ground potential reference point and converging all shielding and third (controller ground) wires tied there, and giving the remote devices no local ground reference (difficult some times ...), or having opto coupled and more expensive 485-232 converters.
- From your writing I understand you used no FCS and so called wildcard FCS on commands you tested. I found this will not allways work reliably, probably for the multiprotocol capabilites TriLogi controllers have. Doing the real thing, to say calculate the FCS and add it to the string you are sending to your t100 will perhaps show something different and is in any case a good practice for reliability on results, even if you don't FCS check what is coming from the controller, later. In any case, something else you may try, is to copy the status of your inputs or outputs into a memory position with a function called by one of the timing flags available at the Special Bits area, and then read it with an RVD command. The direct input and output communication commands may behave quite particular under certain program layout conditions and responding to the fact that answering the command coming from your PC means an interrupt and some timing problem to solve by the controller. You may also give the SETPROTOCOL statement a chance to prevent your controller from understanding something wrong, to say, eventually limit your experiments to just one communication protocol.
- The last issue on this problem may be timing, as not all 485-232 adapters have some (smart ?) way to control this, and depend on the control lines (RTS, CTS, etc.), and not just the Rx and Tx signals coming from your PC. Besides, some strange interpretation on RS232 standards introduced by some component and PC accessory makers are doing some more in this sense. Posts at this forum regarding USB adapters tell lots about. I may most warmly recommend the suggestion, made by Support, earlier, on using the TriLogi's Auto485 adapter to solve problems in this sense. The adjustable timing feature (potentiometer) it has, while in Auto mode, may solve most problems you may find regarding timing issues on RS485, as long as packets coming and going are quite similar sized in length. In any case and if these packets may have quite different sizes, fixed timing may be problematic and other solutions, involving hardware handshake, and running out of the scope of this post, should be used.
Final note: do not try to communicate -and- monitor your controller over the same line and at same time ... nothing prevents from doing this, and you may think your pc and t100 have run into some higher state of mind on an overdose of electrons.
