Replies: 1 comment 9 replies
-
|
I will have to go back and see if I can figure out where we got this empty payload from. I believe it was because the not releasing control back to its control panel. We did this for some reason specifically for VF pumps. Perhaps this was a misunderstanding because I do not have a VF pump. We did pin down the overcurrent in the previous post to the priming attributes on the pump. I removed the empty payload from the VF output so give this a shot. I also posted the rpm back to the poolState.json but I have examples of that data being incorrect on the payload. Perhaps this is more of a firmware version difference though. |
Beta Was this translation helpful? Give feedback.
-
|
The weird thing with this is that our original research states that when the drive state (byte 2) is 0 then there is a fault and the status bytes 11 and 12 contain a fault status. What we were unaware of is that the time schedule is being reflected into those bytes. Perhaps this little tidbit was missed in the coding of the state message. Bytes 9 & 10 have always been a mystery. I wouldn't be surprised if the 128 is actually a power outage alarm and we were just off by two bytes in the sequence. I absolutely believe that we got a bit turned around on the pump reporting so I will make a change here. Byte 13 & 14 are the total runtime for the pump but it will roll over. This kind of makes sense if one were trying to predict the off time for the pump using the minutes calculation from the schedule set on the pump. This is because there is no time clock on the pump only a timing circuit. One could record the pump time when it is turned on then determine when the pump will go off based on the schedule. However, we do not use the pre-programmed schedules in the pump so bytes 11 & 12 have no real meaning for us. |
Beta Was this translation helpful? Give feedback.
-
|
This is what we currently have documented for the pump status message including the changes expressed above.
|
Beta Was this translation helpful? Give feedback.
-
|
Confirming/clarifying a few items just for the documentation record (agreed none of these timing related fields should matter in the context of njsPC):
I can also confirm that the byte 2 drive state does not reflect a 0 when the power fault occurs. In fact, it would appear that the drive state does not update (probably isn't valid) when the pump is stopped (i.e. byte 0 = 4). For example, if the pump was priming and then interrupted, byte 2 will remain set to 1 for the duration it is stopped, likewise for system priming. So in the chart (at least as far as this VF pump with its version of firmware, no idea if the protocol might have changed between firmware versions) under byte 2, I would suggest removing the reference to 0 and the fault mode and adding in that 3 represents 'Primed' (which is momentary only, not latching, seems to match the way it appears on the LCD when running manually) along with a comment that the drive state is only valid when byte 0 = 10. If you do change any of the status reporting logic I would be happy to confirm that it is working on this pump. I really appreciate your time working through this with me and on the project in general- many thanks. |
Beta Was this translation helpful? Give feedback.
-
|
For posterity can I get a replay where the action 3 is being sent to the pump to include the response. |
Beta Was this translation helpful? Give feedback.
-
|
This replay reflects using action 3 to change the pump time from the ~current time to 12:34, waiting for a minute rollover then changing back to the current time: Nixie-VF_pump-clock_set-replay-20240724.zip |
Beta Was this translation helpful? Give feedback.
-
I am considering converting an IntelliTouch system to standalone Nixie. My system includes two Pentair P/N 011012 IntelliFlo VF pumps (which I understand are not that common and have been discontinued for some time) and having gathered from a few previous discussions that they are accordingly less tested with njsPC, I decided to setup a test instance to confirm pump operation including a single pump connected to a 485 gateway and everything else isolated.
Using this test setup, I discovered what I believe is one minor protocol issue and one nice-to-have missing item.
When the pump is commanded off (either by turning off the associated virtual circuit or entering service mode), njsPC appears to be repeatedly trying to send an 'action 5/Set[feature]' command with an empty payload which results in 'Error sending setPumpFeature' errors in the console log and an unexpected payload of '1' in the return message.
Although the VF pump is not designed to accept speed commands over the RS485 bus, it does report the current speed in the status request responses. With IntelliTouch/ScreenLogic, this actual speed is reported along with power and the commanded (vs. actual) flow. In my tests, while the rpm does appear to be updating as expected in bytes 5 and 6 of the pump status payload (as documented here: https://github.com/tagyoureit/nodejs-poolController/wiki/Pumps), it does not appear on the dashPanel pump status field nor does the poolState.json reflect these values (rpm is fixed at 0). Is it possible to configure/modify this so the reported rpm is available for integrations and dashPanel display, similarly to the VSF pump (although without the ability to set an rpm value of course)?
Here is a replay archive from the Nixie test setup described above containing a test sequence with a speed ramp up and down, then pump off and on commands and ending with auto->service and service->auto transitions:
Nixie-VF_pump-replay-20240719.zip
In addition, here is a packet log that I captured with the IntelliTouch OCP communicating with the same pump following the same general test sequence above. I have reviewed/compared both and while there are some timing and order differences (timing looks better to me on Nixie by the way) the only item of concern was the empty payload commands described in 1 above where in the case of IntelliTouch, all Set[feature] commands have a single byte payload of '6' and a corresponding acknowledgement from the pump, irrespective of whether or not the pump is running:
IntelliTouch-VF_pump-packetLog-20240719.zip
The Message Manager tool was sure appreciated- it made this analysis quick and pleasant, many thanks for the thought and time that went into implementing that!
Finally, for the benefit of any other VF pump users, I did have a single instance of a nearly instantaneous over current alarm on the pump display panel on one transition from auto to service mode. Based on the discussion here: #756 and never having seen an over current in almost 10 years on either pump, I suspect this is somehow related to the timing or content of the RS485 comms. The only clue I have is that sometimes, but not repeatably, when entering service mode the pump control panel transitions from the automation lockout screen to the 'manual' mode rather than the 'feature 1' mode. I've also observed it switch to 'feature 1' with the pump re-starting right away and 600 mins remaining showing, whereas most of the time with Nixie, and every observed time with the IntelliTouch, it transitions to 'feature 1' with 0 mins remaining and the pump stopped. It seems plausible this might be related to the Set[feature] issue above but unfortunately I was unable to reproduce this over current error, so am not suggesting pursuing it any further, just wanted to document what I did find here in case it comes up again for anyone else.
Beta Was this translation helpful? Give feedback.
All reactions