Pentair i-Link?
vining
Posts: 4,368
Does anyone know if a Pentair i-Link (serial adapter) requires a null modem adapter to cross over pins 2/3 when connecting to the master's serial port.
Does anyone know if we could connect directly to the Pentair's com bus via RS485 and not use the i-Link adpater?
Does anyone know if we could connect directly to the Pentair's com bus via RS485 and not use the i-Link adpater?
0
Comments
Disregarded i-Link pin out instructions:
I recall you do have to purchase the over priced iLink though. I didn't want to run the risk of damaging the controller and there does not appear to be any other way to connect to the keypad bus.
I have it communicating now and maybe if I used the cable specified in the module It would have just worked. Seems I should have been able to just connect straight into the master as it work connecting directly into my PC.
I'm using the standard netlinx module and if I find it works well and does everything I need I'll just continue using it.
I might be possible just to connect to the RS485 bus but I too don't want to waste time or fry the system but it doesn't hurt to ask if anyone has tried. It could be just a 232 to 485 converter they're selling us.
I've always used the adapter, and never connected to the 485 bus, so I don't know if that would work.
Maybe the note below from the i-Link doc is just them stating they've already shorted these pins together. At first I thought that meant they wanted me to connect to these pins but since it didn't make sense to do that I ignored it and went with my gut instinct which worked. Directly connecting to a DB-9 port on the master didn't nor did it work with a null modem adpater.
This had me baffled cuz I could query the system and recieve a correct respons but I couldn't issue commands, I would even tually receive a timeout error when trying to control the system. Given the explanation I received from the tech is quite possible my TX/RX lines are fine to the i-Link and my RX on the i-Link from the Pentair system is also god since I receive the correct value but my TX line to the Pentair from the i-Link might be bad or crossed. I had assumed since I was sending queries and received proper responces to the queries that comms had to be good but apparantely is wasn't that simple of an operation.
Mean while on another job the pool guys are telling me that I don't need an i-Link, that any 232-485 protocol adapter will work cuz that's what the Craptron guys use. Of course I never met a pool guy that knew what they were talking about and the tech did sound credable and it also makes sense that no one here as ever used the Pentair system directly via 485. Oy vey!
I did find in a pool forum that some software guy connected to Pentair's Itellitouch system direct to the rs485 bus and reverse engineered their protocol to make it work. He said there is some benefit to doing that since there are some parts of the Pentair system like the intelliflo pumps that aren't accessable and whose values aren't available to the i-Link interface.
I checked the wiring on saturday and put a keypad on the wire running form the i-Link to the Pentair and it worked. I still query various states ok and when I try to control something I get a response but it always the current state and not the state I'm trying to set. I'll have to make another call to Pentair this week and see what they recommend trying.
http://www.cocoontech.com/forums/index.php?app=downloads&showfile=173
It's a Canadian Security & Automation forum download page of the reverse engineered protocol. Unfortunately it will take some time for me to make sense of the files. Maybe I'll try this on the next pool but for now I'd be happy getting control of the system using the i-Link.
9600,n,8,1 485 enabled
The protocol ============ The protocol uses short binary packages for information exchange. The packages have variable size. The minimum length is 8 bytes and the theoretical maximum is 6+256+2=264 bytes. The largest I have seen on a live Pentair bus is 37 bytes. The format is: <ldb> <sub> <dst> <src> <cfi> <len> [<data>] <ckh> <ckl> <lpb> - leading packet byte, 0xa5 <sub> - ? <dst> - destination address <src> - source address <cfi> - command/function/instruction <len> - size of data field (may be 0!) <data ...> <ckh> - most significant byte of checksum <ckl> - least significant byte of checksum The checksum is a 16 bit unsigned sum of all bytes in the message up to the checksum field. Most packages are preceded by a preamble of 1 or more 0xff bytes and a 0x00 0xff sequence. Every device on the bus has an address: 0x0f - is the broadcast address, it is used by the more sophisticated controllers as <dst> in their system status broadcasts most likely to keep queries for system status low. 0x1x - main controllers (IntelliComII, IntelliTouch, EasyTouch ...) 0x2x - remote controllers 0x6x - pumps, 0x60 is pump 1 Apart from unsolicited broadcasts, information exchange is done by a device A sending a message to device B and device B sending an answer to device A. Messages for simple exchanges only differ in the fact that <dst> and <src> are swapped. For example: C: A5 00 60 10 04 01 ff 02 19 P: A5 00 10 60 04 01 ff 02 19 is a request from the controller to the pump to turn panel control off, which enables it to send other commands to the pump. The pump confirms the action in the answer. The following sequence will turn panel control back on: C: A5 00 60 10 04 01 00 01 1A P: A5 00 10 60 04 01 00 01 1A The interpretation of a <cfi> depends on the destination of a message, meaning a <cfi> for one device might mean something else for another. And there are exceptions to this protocol. The IntelliChlor C40 puts messages on the bus that start with a 0x10 0x02 sequence, a data field, a single byte checksum and a 0x10 0x03 trailer sequence... The checksum is the unsigned sum over the data field + 18. There are many <cfi>s I have seen in data dumps, the interpretation of the datafield is somewhat cumbersome without knowing the system, so my focus is more on messages to and from a pump. However, here are some basics I found: A <cfi> to a controller seems to work like this: bits <76543210> 00xxxxxx - ? 01xxxxxx - ? 10xxxxxx - transfer(write) <cfi>&0x3f to controller controller acknowledges the write with <0x01><0x01><cfi> 11xxxxxx - request <cfi>&0x3f from controller the controller broadcasts it in response My pump is an IntelliFlow VS, it does follow instructions from an IntelliComII controller, provided the external programs are setup and enabled. It has to be in FILTER mode AND Started to make it go. Unlike other controllers, which take over full control of the pump, the IntelliComII grabs control only for a short interval of time, every 30 seconds, to communicate what external program to run. If all inputs are off it does not even do that after it has had a respone from the pump. The sequence for input 1 active is: C: A500 d=60 s=10 c=04 l=01 FF <0219> SETCTRL remote P: A500 d=10 s=60 c=04 l=01 FF <0219> CTRL is remote * C: A500 d=60 s=10 c=01 l=04 03210008 <0146> WRITE (0x0008) to 0x0321 P: A500 d=10 s=60 c=01 l=02 0008 <0120> VALIS (0x0008) C: A500 d=60 s=10 c=04 l=01 00 <011A> SETCTRL local P: A500 d=10 s=60 c=04 l=01 00 <011A> CTRL is local * C: A500 d=60 s=10 c=01 l=04 03210000 <013E> is a stop * C: A500 d=60 s=10 c=01 l=04 03210010 <014E> is program 2 * C: A500 d=60 s=10 c=01 l=04 03210018 <0156> is program 3 * C: A500 d=60 s=10 c=01 l=04 03210020 <015E> is program 4 If one quits repeating the sequence for about a minute the pump stops. The IntelliComII is not aware of the status of the pump and will keep repeating the sequence as long as an input is active. You can stop and start the pump with the START/STOP button on the control panel anytime, unless, of course, you hit the period when it is in remote control. More decoding of binary data from an IntelliTouch controlled system with a VS pump surfaced that there is a status report from the pump. It is only obtainable when the pump is in remote control. C: A500 d=60 s=10 c=07 l=00 <011C> SEND status P: A500 d=10 s=60 c=07 l=0f 0A0602024A08AC120000000A000F22 <028A> RUN 0a Started MOD 06 Feature 1 PMP 02 ? drive state PWR 024a 586 WATT RPM 08ac 2220 RPM GPM 12 18 GPM PPC 00 0 % b09 00 ? ERR 00 ok b11 0a ? TMR 00 0 MIN CLK 0f22 15:34 The above sequence is embedded within the cyclic exchange of data between the controller and the pump. The full cyclic sequence is: C: A500 d=60 s=10 c=04 l=01 FF <0219> SETCTRL remote P: A500 d=10 s=60 c=04 l=01 FF <0219> CTRL is remote C: A500 d=60 s=10 c=01 l=04 02E40012 <0212> WRITE (18) to 0x02e4 P: A500 d=10 s=60 c=01 l=02 0012 <012A> VALIS (18) C: A500 d=60 s=10 c=05 l=01 06 <0121> SETMOD 06 (Feature 1) P: A500 d=10 s=60 c=05 l=01 06 <0121> MOD is 06 C: A500 d=60 s=10 c=06 l=01 0A <0126> SETRUN 0a Started P: A500 d=10 s=60 c=06 l=01 0A <0126> RUN is 0a Started C: A500 d=60 s=10 c=07 l=00 <011C> SEND status P: A500 d=10 s=60 c=07 l=0f 0A0602024908B1120000000A000F22 <028E> The controller never releases the pump as long as it is in AUTO mode. The display on the pump shows "Display not active..." and the LEDs above FEATURE 1 and START/STOP are on. Experiments with my pump showed that one can change the GPM setpoint 0x02e4 on the fly, it follows it! If the controller releases the pump the cyclic sequence changes to: C: A500 d=60 s=10 c=04 l=01 00 <011A> SETCTRL local P: A500 d=10 s=60 c=04 l=01 00 <011A> CTRL is local It is important for any serious controller implementation to know when a pump runs into trouble and the Pentair IntelliFlow VS is fully capable of doing that!Yeah, I agree, I have another side project I am working on first, but I would love to come back to this, you get a much higher level of control!
Aside from the little serial line reset-issue on the Jandy we have had pretty good success with them, but a new client is asking us to look at using Pentair (we avoided them 5 years ago); I had heard that Pentair is a bit troublesome; can you guys comment on how good the Pentair is compared to the Jandy?
Thanks!
Bump this up to the top...
I'll keep an open mind towards Pentair in the future.