We poll the ZSCAN16PROXR every 4 seconds to detect the closure of hardwired latching buttons. Recently we reviewed our logs after the system did not function properly and it was discovered for a 30-40 minute time period the device reported closure of the buttons over 1, 2, and 3 consecutive polls. Since these buttons are latching users do not actually open them up seconds later, and furthermore the buttons are located in an area covered by video camera and during that time no one was there as it was late at night. We also notice that during this time the 16PROXR reported closures on inputs that had no wiring connected (these are unused). So for months the device reports nothing, then for about 30-40mins one night last week it reports various inputs are closed, then after that goes back to operating normally (no false closure reports). We have had reports with this device at other locations sending false button closure readings, so we altered our software to require the button to be closed for several polls before taking it as a true reading.
Are we using the device correctly and is there any explanation why the unit would report input states incorrectly? This has become a huge issue for us and we are rethinking continuing to use this in the future. There are other environmental conditions we have ruled out such as local electical noise, power supply droop, etc.
Please let us know what we should do next to investigate this.
Can you provide the snippet of code that sends input reading commands to the board or just let us know what command bytes are being sent to the board to read the inputs? Also what is the connectivity from the software to the board? USB, Ethernet, etc?
Our Server sends command 254,175,0 every 4 seconds to poll. If you need more detail on this can I send you a snip from Wireshark capture of the poll? I think this is better then the code. I can have one of my guys grab it from the lab today/tomorrow. Let me know if that works for you.
We always configure the units to static IP so they don’t move on the network. This is very simple change and we do not modify any other settings. When we see this happen its always an isolated incident then everything returns to normal.
Wrapping the command in an API frame will significantly improve the reliability in communication with the board. This guide explains how the API frame wrapper works:
I would recommend implementing that in your software, then see if you still have any false readings.
How long has firmware Version 3.2 been available for the ProXR boards? I will check what we have in the lab.
Are you suggesting that its possible that for a short period of time the device can return erroneous input states if we don’t use the API? We designed this years ago, the code is being checked.
The API frame format ensures that data received by the board is always a complete packet. Also by evaluating the API frame on the software side it can be concluded that the complete packet was received back from the device. This should eliminate “jumbled” data completely.
I am not sure about the lifespan of firmware version 3.2. I can look into that if you have any issues after implementing API frame wrappers.