jesawyers

Members
  • Content Count

    40
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jesawyers

  • Rank
    Member
  • Birthday 12/01/1963

Contact Methods

  • ICQ
    0
  • Skype
    jesawyers63

Profile Information

  • Gender
    Male
  • Location
    Fort Collins, CO
  • Interests
    Guns, Guns, Guns...And I kind of like this automation stuff.
  1. jesawyers

    2019 Update??

    Wanted to check in to see how things are going and can we expect a release this year? Also, following are some items that I requested in 2017 to make DAQ Factory better for me to sell to customers. You wanted me to ping you. 1. Display the ALM, ACK, and RST times in the format set in Windows Region and Language settings. 2. When you resize a column in the alarm display, for example the description, they do not retain their new column width settings. Would be nice if they did so you don't have to resize every time you open the alarm dialog. 3. Check-box on alarm display to hide inactive alarms to "clean up" the alarm summary. John
  2. jesawyers

    2018 Update?

    Hi Guys, Was wondering if there was a planned update of DF for 2018 and what new features might we expect> John
  3. 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
  4. Hey Rodney...If you don't mind, can you tell us what WiFi devices your using?
  5. 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
  6. 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
  7. jesawyers

    Alarm Summary Hide Inactive Alarms

    Since 17.1 was recently released would like to bring up the following requested items for possible inclusion in future relates... 1. Display the ALM, ACK, and RST times in the format set in Windows Region and Language settings. 2. When you resize a column in the alarm display, for example the description, they do not retain their new column width settings. Would be nice if they did so you don't have to resize every time you open the alarm dialog. 3. Check-box on alarm display to hide inactive alarms to "clean up" the alarm summary. Thanks...John
  8. Thanks Guru...I did not know that but makes sense. John
  9. Hey Guru...duplicated TestDevice.dds and created a internal.dds with the changes you directed. Works great!!! One additional question...Under the I/O Type, I see standard data types like string, but not some of the other data types such as int, float, and Boolean. What I/O type should I use for these types? John
  10. Hi Guru...referencing the Test device above led me to a question. Is it possible to rename the device to something like "Internal". The reason I'm asking is that "Test" to me is more like a temp channel for testing purposes and is not a permanent channel.. To me it would be better to name is something like "Internal" or something that indicates that it's a permanent channel. Can it be renamed? Thanks...John
  11. Hey Guru! Thanks for the update and no worries about specifying a date or even a month. Was just curious . John
  12. Hi Guru, Well since you mentioned it, what can we expect in release 17.1? Any target date for the release? Thanks...John
  13. jesawyers

    Modbus RTU Address Limit

    Hi Guru...Yep completely agree about the DoS attacks and the use of a firewall. I'm sure I'm stating the obvious, but network security should be approached with multi-layered solutions in mind. On our turbine control systems we are delivering to the US Navy, we are implementing firewalls with deep packet inspection as our current security solution since they still want to still use MODBUS. One item as part of the multi-layered security solution is also physical security which most folks ignore. The last statistic I saw, about 60% of all security breaches come from inside the network/firewall. That number used to be as high as 75%. The control systems we supply are on ships with no access to the Internet. So physical locking or disabling Ethernet ports is part of our security plan. Something you and others might be interested in is an organization called the Defense Information Systems Agency (DISA.mil). DISA provides Security Technical Implementation Guides (STIGs) which identify security holes in software and hardware and solutions. The big one we use for software are the STIGs for the various Windows releases which we use for HMI applications. I also recommend folks visit http://energy.gov/oe/services/cybersecurity Right before starting my current job, we received a RFQ for a turbine control system that included a bunch of Department of Energy Cyber Security requirements. I believe this will now be standard policy for control system and implementation of Cyber Security requirements will increase control system costs. Well nice chatting with you and hopefully our exchange will help increase control system security awareness within the Azeotech users. Later...John
  14. jesawyers

    Modbus RTU Address Limit

    Hi All, I just wanted to put my two cents in on this subject because I have fought this subject my entire career in the power industry. As we all know, there are latterly thousands of devices that support MODBUS. But you have to ask the question...Is it MODBUS compliant with the actual MODBUS protocol as defined by specification at www.modbus.org? Many products only implement part of the full MODBUS protocol and others, like in the case above, implement extensions specific to their products. This is fine but can lead to confusion because the actual MODBUS specification is not being implemented. As our awesome Azeo Tech Guru has pointed out, the biggest issue is if the MODBUS device uses zero based addressing or 1 based addressing. We all have seen both and I have seen devices use 1 based addressing but the actual packet uses zero based addressing. If you look in the actual MODBUS specification, it specifically states register addresses are from 0x0000 to 0xFFFF. Notice that they don't start at 40000. MODBUS is a very simple protocol if implemented per the specification but it's beginning to run in to age issues. MODBUS is still a popular protocol because it's been around for a long time. However, one item we are running into is the lack of security features within the protocol. MODBUS can be spoofed quite easily when using MODBUS/TCP. Cyber Security is the new hot topic in the automation industry and the MODBUS protocol needs to be updated to improve Data Integrity, Authentication, Non-Repuditation, and Replay Protection. These security holes have been identified by many companies and are pushing the MODBUS organization to update the protocol. In particular, we are being pushed by the US Navy to find methods to better secure MODBUS communication links. For our Azeo Tech Guru, I have attached an PDF showing a possible solution that the authors proposed for doing this that I found on the Internet. We are looking at rolling our own MODBUS protocol based on this proposed solution but it would be better if the MODBUS.org folks jump on this to keep the MODBUS protocol relevant in today's cyber security threats. Later...John A_Secure_MODBUS_Protocol.pdf Modbus_Application_Protocol_V1_1b3.pdf
  15. I was just wondering when the next revision of DF might be released? Not rushing you guys for a release just was wondering. What kind of goodies and features might we see? John