Rodney Posted January 16, 2018 Share Posted January 16, 2018 Hi My project testing on my bench has worked well with no timeout errors / no data acquisition errors I have just completed my first field test at my friends cattle station where data acquisition is over wifi links (3km and 10km with a ping of 12ms) I am getting both CRC and ID mismatch errors on a regular basis and after reading a number of posts re these believe I have timing issues please see attached below I am using an ethernet /RS 485 converter with a the timeout set to 1000ms (same unit/ settings used for bench testing) I need some guidance as to which parameters etc I need to change / maybe try catch error scripts in sequences? Rodney Link to comment Share on other sites More sharing options...
AzeoTech Posted January 17, 2018 Share Posted January 17, 2018 Hard to say without seeing the comm monitor at the time of the errors. You got some errors, then it worked for 27 minutes, then you got some more, so its not constant. Link to comment Share on other sites More sharing options...
Rodney Posted January 17, 2018 Author Share Posted January 17, 2018 ok is there anyway I can dump the live comms monitor data to a file? Link to comment Share on other sites More sharing options...
AzeoTech Posted January 19, 2018 Share Posted January 19, 2018 No, I'm afraid not. Link to comment Share on other sites More sharing options...
Rodney Posted January 19, 2018 Author Share Posted January 19, 2018 Hi I've been playing around with various settings and changed to another type of equipment at a different site to the above post and reduced the channels I am reading to just 1 I have set the time out to 750ms on both the tcp/ethernet converter and the comms device I am still getting timeout errors please see attached 4 screenshots your guidance greatly appreciated what I need to change to remove the timeouts Rodney ps disregard theuploaded images 2& 3 use 5&6 instead - I couldn't work out how to delete them.... Link to comment Share on other sites More sharing options...
AzeoTech Posted January 25, 2018 Share Posted January 25, 2018 Unfortunately you didn't quite catch the timeout error at 19:36:31. But I do see that occasionally your device takes 200ms or more to reply to a query from DAQFactory. That seems long, especially since other times it's closer to 60-80ms (which is also pretty long for ethernet). Are you going over a radio? Link to comment Share on other sites More sharing options...
Rodney Posted January 25, 2018 Author Share Posted January 25, 2018 yes using wifi - 3km hop then 10km I have sort of fixed the issue over the last few days by inserting a try/ catch and just ignoring the timeout errors is there a "better" way to try and fix? Link to comment Share on other sites More sharing options...
jesawyers Posted January 25, 2018 Share Posted January 25, 2018 Rodney...First thing I would try is to increase your timeout on both the DF driver and ethernet/serial device. Your timeout is simply that your not receiving a response in the 750ms time frame. Set your timeout to 2 seconds (2000 ms) on both DF and your ethernet/serial converter and see what changes. This is for troubleshooting right now to see if there is a latency issue somewhere. Also, how often are you polling the single value from DF? The default is 1 second. Good move to poll a single tag right now until your figure this out. What is the baud rate of your RS485 connection? Are you seeing any errors on the WiFi side of things? John Link to comment Share on other sites More sharing options...
Rodney Posted January 26, 2018 Author Share Posted January 26, 2018 John I have set the timeout to 2000 ms as suggested and after 30 minutes no errors..... I will let it run for 24-48 hours and see what happens I am actually polling 3 different sites concurrently - 1 has one tag the 2nd 4 tags and the 3rd 10 tags the baud rates are all 9600 as I have a number of different types of equipment so I set them all to 9600 to make it easier to write the sequences Initially I had wifi issues but I think I have solved them - ping tests now are fairly consistent just the occasional packet loss in 24 hours one of the sites is 13 km away and I getting average 12ms pings from the wifi /RS485 converter there Thanks for your suggestions Rodney Link to comment Share on other sites More sharing options...
Rodney Posted January 28, 2018 Author Share Posted January 28, 2018 Hi John Testing over the last couple of days has shown spasmodic timeouts - runs for 7 hours then a timeout another an hour later then 4 hours before the next etc It appears to me these are wifi related not timeout issues - Thanks for the 2000ms timeout fix I can live with these spasmodic outages - it will be interesting when we eventually go to the planned 30km wifi hops... Regards Rodney Link to comment Share on other sites More sharing options...
jesawyers Posted January 29, 2018 Share Posted January 29, 2018 Hi Rodney, Glad the timeout worked. Another thing you might want to try is to setup your WiFi with fixed values... no auto negotiation. Also, try slowing down the WiFi link speed if your devices support this. Some WiFi devices will change speeds and channels based on conditions and this can induce delalys. Make everything a fixed value so that the WiFi link is always the same and does not have to be negotiated. Start at a very slow speed and work your way up. If the links were good how many tags are you going to poll? John Link to comment Share on other sites More sharing options...
jesawyers Posted January 29, 2018 Share Posted January 29, 2018 Hey Rodney...If you don't mind, can you tell us what WiFi devices your using? Link to comment Share on other sites More sharing options...
Rodney Posted January 30, 2018 Author Share Posted January 30, 2018 Hi John I'm using TP-Link CPE520 for the 3km and 10 km links for the planned 30km links again using TP-Link it will be WBS510 with ANT5830MD dish Antennas for us it was the best bang for our buck..... Re the Auto negotiate - in initial testing that was what I used but ping times were 1700-2500ms plus so I used the "survey" mode and locked the channel to the best one available - like I said above return pings are now averaging 12ms Re the tags to poll - this is going to be interesting.... Each site might have up to 5-7 pieces of equipment - Solar controllers, tank sensors, flow meters, pressure sensors, Amp meters weather stations etc so each site might have 100 tags x the planned 16 sites 1600+ As we add sites we may have to reduce the amount of data we are gathering - we just don't know yet Rodney PS I'm an accountant and knew a liitle about wifi and networking but have taught myself DAQ factory in the last 12 months from scratch - it a big learning curve this and a great adventure for me!! Link to comment Share on other sites More sharing options...
jesawyers Posted January 31, 2018 Share Posted January 31, 2018 The CPE520 looks like a nice piece of hardware and should be more than adequate for the 3km and 10km links. I like learning new things, so I'm going to dig into CPE520 a little because it looks interesting. If I see anything that might help I'll let you know. I bet turning off the auto negotiate disabled the long distance features of the CPE520. Accountant or not, your doing a fine job figuring this stuff out. Take a look at the OSI model to see how networking protocol stack is structured. Ping (ICMP) is a great tool but only tests up to layer 3 of the TCP/IP protocol stack. This is why you were seeing ping times of 12ms but still getting timeout errors. I believe your ethernet/serial device is using MODBUS/TCP which is part of the application layer 7. So when DF is communicating to your devices there is additional overhead (i.e. latency). Your getting 12ms pings, but the actual transmission time might be taking 1000ms, or longer, because you have to... 1. Transmite the MODBUS/TCP request to the ethernet/serial converter 2 The ethernet/serial converts to MODBUS/RTU, transmit the request over RS485 3. Wait for a response from the slave device 4. Convert the MODBUS/RTU response to to MODBUS/TCP,. 5. Transmit the MODBUS/TCP response back to the master. How often are you polling data from DF? You might be pushing it at 1.0 second when you shift to your 30km links. Running 9600 baud with multiple nodes on RS485 is OK for 1 or two devices but as you increase the number of RS485 nodes I would recommend a higher baud rate to decrease your latency. If you don't mind do you happen to have a network drawing I could look at? If not or don't want to I completely understand. If you want to contact me direct my email is jesawyers63 <at> gmail <dot> com. John Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.