RodSwan Posted October 20, 2015 Share Posted October 20, 2015 I have a number of independent systems, each talking over a dedicated Ethernet link to an Adam 6050 (multi digital I/O device). I get no errors reported in DF (I have output set encapsulated in try/catch) yet output does not always get set to correct state. once every second code (OP0 is i/o channel and X is desired output state):- if (OP0 != X) try OP0 = X catch() logmsg("Error Caught setting OP0" + strLastError) endcatch if (OP0 != X) CommsErrorCount++ LogMsg("Error Setting OP0") endif endif After each set I check output one second later to verify it has changed. If it hasn't I set it again and log error. Sometimes it takes up to 10 minutes of retries once every second to get output to change. Problem is very intermittent. I have thought it was problem with Adam 6050 but sometimes when problem is repeatedly occurring on a system simply restarting DF clears the problem. Communication to Adam I/O unit is over a very short (about 6 inches) dedicated Ethernet link - only devices on the link are the PC and the Adam unit. Any idea where I should start looking to find source of problem? Is there any convenient way to log the comms (discreetly on the customers live system) so I can confirm what data is sent to and from I/O unit? (as per sods law, I have been unable to recreate problem on test bench ). I think I've had this problems for years, but haven't noticed it before as I only use a single output that changes maybe once per hour or so and when it fails my retry code usually corrects it with in a few seconds. I am currently running DF 5.90 build 2197 on Windows 7 professional SP1. In the channel list Timing and Offset are both set to 0.0. Rod. Link to comment Share on other sites More sharing options...
AzeoTech Posted October 20, 2015 Share Posted October 20, 2015 Do reads on the device keep working? I wonder if its losing its socket? Try doing it more often and watching the comm monitor. See if you see Tx without Rx, or you see an error code returned by the device or something similar. Link to comment Share on other sites More sharing options...
RodSwan Posted October 20, 2015 Author Share Posted October 20, 2015 Hi,Yes, reads continue without problem. I have modified code in "AppEverySecond" sequence (executed 1 every second) to test it more often: global OP2Test=0 function AppEverySecond() .... while(1) ..... if (OP2 == OP2Test) OP2Test=!OP2Test //flip flag Op2Count = 0 endif if (OP2 != OP2Test) Op2Count++ try // setting it. OP2 = OP2Test catch() logmsg("Caught setting OP2" + strLastError) endcatch if (OP2 != OP2Test) logmsg("setting OP2 to " + OP2Test + ", failed... count " + Op2Count) endif endif .... wait(1) EndWhile Difficult to follow in the comms log as I'm only able to grab (i.e. copy to clipboard) about 10 seconds worth from the Comms monitor - Is there anyway to send this directly to a file... or even just be able to grab a couple of minutes worth?... to follow a complete set OP2 to completion needs at least 95 seconds on the one I've just tried to log. So, I've checked the Comms log and it seems that DF waits an (as yet) indeterminate time before sending the command to the Modbus device. I have two files attached (the DF Comm log and my own logfile) that show this. I have not yet been able to identify why it doesn't send the command immediately or what finally triggers DF to send it. I have one example (my log file... too long to get DF Comm log) where it took 209 attempts (i.e. 3 minutes and 29 seconds) to send it and the problem that finally brought it to my attention was an event a week or two ago where it took more than 10 minutes. The comms log trace that eventually gets communicated is: OP2 is Channel 19 (address 018) Tx (16:32:01.299): \000\000\000\000\000\006\001\005\000\018\000\000 Setting OP2 0.... finally succeeds after 95 failed attempts Rx (16:32:01.299): \000\000\000\000\000\006\001\005\000\018\000\000 Tx (16:32:02.038): \000\000\000\000\000\006\001\004\000\014\000\002 The comms all look good - except that the send of the command is delayed. The CPU usage during all of this was around the 10% mark (uVNC remote connection). The priority of the "AppEverySecond" sequence is 5 - Aquisition, though there is no doubt that is executing to completion (well, round the While()...EndWhile loop) as you see from the other logs. HELP! (please!!) Rod. My Log - Showing Setting of OP2.txt Log of DF - Mod1 comms - Showing Setting of OP2.txt Link to comment Share on other sites More sharing options...
AzeoTech Posted October 21, 2015 Share Posted October 21, 2015 What is the timeout value on the port? Its likely I'd need to see the ctl doc. Link to comment Share on other sites More sharing options...
SteveMyres Posted October 21, 2015 Share Posted October 21, 2015 Also, is there other traffic on the Ethernet port on the PC? Maybe DF is having to wait to get the port. Link to comment Share on other sites More sharing options...
AzeoTech Posted October 21, 2015 Share Posted October 21, 2015 Ethernet doesn't work that way. As the client, the PC can open as many sockets as needed on a particular port, and each of those connections are separate. If they weren't you'd get collisions all the time. The limiting factor is the server (device). PC servers can typically handle lots of clients, but often devices only support one or a few clients on a particular port due to simple cpu limitations. But if DAQFactory is already reading on the socket, then there really is no difference between the reads and the writes. In fact, Ethernet has no idea what the data means that it is carrying, neither does TCP/IP. The most likely cause here is that the timeout value is too short and the outputs are unable to access the port because DAQFactory is busy performing the inputs. Its basically what Steve is suggesting, but within DAQFactory itself, on a single connection line. DAQFactory provides its own blocking mechanism to keep other threads within DAQFactory from writing to the port while its waiting for a response. Link to comment Share on other sites More sharing options...
SteveMyres Posted October 21, 2015 Share Posted October 21, 2015 Thanks for the background -- I didn't know that! Link to comment Share on other sites More sharing options...
AzeoTech Posted October 21, 2015 Share Posted October 21, 2015 There's actually a critical lesson here too: a Denial of Service attack is when a multiple clients connect to a server and use of all the available connections. As mentioned, normal web servers can handle thousands, if not millions of connections so a DoS attack takes a bit of effort to be effective. But a PLC, can only handle a few, maybe only one connection at a time. In an internal network environment this is usually not a problem, but if you go and put the PLC on a publicly facing IP, one that can be reached from the Internet, then it is very easy for someone to do a DoS attack on the device. For well made PLC's the DoS attack probably won't cause the PLC to not function, but while the DoS attack is occurring, you won't be able to connect and query the device. Note also, that security, like passwords, on the PLC itself won't help protect against a DoS attack because the connection is made before the password is entered. To protect against a DoS attack, you should either setup a VPN or similar connection where a device designed for remote network access lies between the PLC and the Internet, or better (and easier) use a product like DAQConnect (www.daqconnect.com) and a DAQBridge to get remote access to a PLC without having to do any network changes. Link to comment Share on other sites More sharing options...
RodSwan Posted October 22, 2015 Author Share Posted October 22, 2015 Reply and CTL file sent in private email... Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.