Using DaqFactory to poll the TStat10. I figured out that for analog inputs I have to ReadHoldingS32RWords in DF… this gives the correct representation for temperature sensors. However I cannot let the 1sec poll run for very long before it times out… my timeout is set to 5 secs!
I caught this in Wireshark… apparently the TStat10 spat out a BacNet packet instead of a Modbus one? Lots of black retransmission frames as well. Whenever this happens the DF sequence running just dies unless I take care to detect the error and restart it… just doing Hello World right now.
As always, the first step is to make sure you have the latest firmware on the device, you can do that from T3000 → help → check for updates.
The next step is to reduce the polling rate, you can do that by polling in blocks rather than single registers.
And one second is pretty fast for wifi because of known limitations with the wifi module we’re using. There’s a new wifi version nearly ready for release, if you are just beginning your evaluation we should arrange a swap. You can send an email to any of the address’s on the website and it will get to me.
OK… I was polling at 5second intervals… one value, two fetches of two words each. I’d get about five periods before 5second timeout would bomb the sequence (DaqFactory 17). Doing ReadHoldingU16(1,7484,2) (device 1, chan 7484, 2 words).
I updated the firmware using T3000. I tried over the wifi… no go. I had to delete the device in T3000, reconnect using RS422, find the device, then update it via serial port. During all this I noticed that when the failure happened a window (that was not on top) showed that the device needed to be on the same subnet… and T3000 suggested another IP implying that I had set MASK to be FF:FF:FF:00. Perhaps I had. This tells me that firmware updates use UDP packets over wifi? Anyway I was able to move to serial and get it done.
Moved back to wifi. I tried the same 5sec poll… same result. I moved it to 10sec… similar. I moved it to 60(!) seconds… on the 12th poll it timed out again. Fresh firmware, 60 second polling loop… timeout.
If an updated version is available that we can poll faster than once a minute yes we’d like to exchange.
Interesting… I upped the block size from 2 to 10… now it’s gone 20 intervals without timing out. Why would increasing the fetch size prevent timing out? At a loss.
I’m going to try upping the polling rate from once a minute to every 30 seconds… we’ll see where this takes us.
Regarding the bacnet packet you captured, it looks like there is either some other software or another device sending the bacnet who-is command. Our Tstat10 supports both bacnet and modbus protocols and you can adjust it in the communications settings dialog.
If there is only one modbus connection, there is no problem with the interval of 1s, so please confirm whether there are multiple software communicating with it at the same time, each application will try to take over port 502 which can cause conflicts. Niagara for example uses a service which also needs to be shut down to free up the IP port.
T3000 was open, but not connected. Does it send packets out occasionally? That would explain.
So is a 10second timeout too short? Would my TStat10 have replied if I’d just waited longer? I’ll try another experiment… 1 min timeout, 1 min poll. 10 packets starting at IN0, 7484.
Not going to bother… I’ve just examined the Wireshark from last night’s run… the TStat10 replied to a Modbus request with a TCP ACK instead of a Modbus reply. This ended up not triggering a retransmission request so TCP was happy… but DaqFactory was not satisfied… so it timed out and bombed the script. I’ll attach a picture of the 'shark… the TStat10 never sends TCP ACK unless a retransmission has been asked for, as far as I can tell. Why would the TStat10 send an ACK instead of a Modbus reply?
T3000 does indeed send some packets in backgroud, if you are running other software that needs the Modbus 502 or Bacnet IP 47808 ports you should shut T3000 down.
If DAQ factory has a trial license we can set up a test here and see what is going on.
The wifi module used on the Tstat10, current production, is not that great. It can only deal with a light load. As mentioned before, if you can do a block read rather than a series of single registers that will reduce the load. If you dont get a reply to your poll in the first second or so you would need to do a retry. Waiting a few seconds or even minutes as you mention here is not going to make much difference. But waiting a few seconds between successive polls will help.
We have a new ESP32 based wifi module nearly in production. Since you are evaluating for a new project we should swap units with you, please contact us by email to arrange this.
I sent you an email to swap for the TStat10’s with the new wifi module. The RS422 works fine, it’s just the wifi that’s the issue. Please work with your stateside vendor to arrange a swap of these three units we purchased. Thanks in advance.
