My subnet is flooded with transactions that keep repeating because they do not receive the correct response from the field device. I can stop and start the subnet, clear and set Data Valid and they still repeat. I have all the queries set to Update Mode = Change of state on Trigger. I have re-tries set on 3 for all the transactions. I called Tech Support and he said to post here for further help.
Hi @george.titus,
Can you please share:
- The config file (Go to File > Export)
- The packet capture or log of the transactions that you are seeing
Thank you,
Kyle
Hi George,
I’ve look at the configuration, but the file labeled “Jan 17 Log” doesn’t contain a log from the Anybus. To create a log, you need to make sure you are connected to the device and click the Log icon. When you stop logging it will automatically bring up the data that was logged.
I’ll need to see the log to confirm what is going on with the network. It you aren’t writing to the triggers though, the Anybus shouldn’t be flooding the subnet with traffic. To further limit it, you can increase the Reconnect time and timeout.
Can you also send the manual and memory map for the fieldbus device(s) so I can look at why it’s not responding?
Thanks,
Kyle
Not sure if that was the right log file, this is probably it, the one I emailed before.log 20200116 0930.txt (35.7 KB)
Were you writing to any of the trigger bytes when this log was taken? If so, is any data logged when you don’t write to a trigger?
You appear to be getting a response, but it’s only one byte, 0x16, every time. Does the manual for the slave device indicate what that means?
Some of the Query update times are set to 1, some to 10, and others to 100. Can you set them all to 100? And set the timeout to 200?
Would it be possible to connect to your PC with Teamviewer and help troubleshoot this with you?
Hi Kyle:
My latest problem seems to be I am sending queries even though none of the trigger bytes are changing state. I am going to try and attach a text file of what I logged this afternoon. I am up for a Teamviewer session most of the day tomorrow. Would around 10 AM Pacific time work for you?log 20200203 1458.txt (31.6 KB)
Hi George,
The log you sent does not seem to match the configuration file I received from you. It is querying slave number 34 and 35 in the log which aren’t in the configuration. Can you send me the latest config file? Are you sure you are successfully downloading it to the Anybus?
I will be available for a Teamviewer this after, but it will probably be closer to 10:30 PST. Let me know if that works.
Kyle
Hi Kyle:
In this log I am querying slaves 22 & 23 Hex, as should be reflected in the configuration file.
The nodes in the configuration file are:
PC100 Slave address 37 (55 Decimal)
Z1MFC1 Slave address 22 (34 Decimal)
Z2MFC1 Slave Address 23 (35 Decimal)
Z6MFC1 Slave Address 24 (36 Decimal)
I have been successfully reading and writing from the field devices like 90% of the time for a month now. I figured out how to successfully download to the module and am sure I’m getting the right
data onto the module as I can manually trigger the queries with their Change of State trigger.
The problem shown in this log is that all the change of state trigger changes in the PLC were inhibited during the time the log was taken.
I ran into another issue yesterday where a query that had previously been working quit updating it’s Process Tags in value, even though I can see the response from the field device (PC100) is replying
with the correct value. This query/response has been working for weeks now but stopped for no apparent reason.
And we still have the problem that if the checksum does not match the command and the device responds with NAK (0x16) the query never stops executing.
In the real world we are not going to be able to disconnect the ethernet connection and cycle power on the gateway to correct problems like this on the machines we will be sending to our customers.
HMS Config File 20200204.cfg (16 KB)
log 20200204 0903.txt (31.9 KB)
And anytime you are available for the TeamViewer. I usually go to lunch about 4:30 Central, 1:30 PM my time and would no have email with me but any other time I should be able to respond within a couple minutes.
So, I got this link, the page said I had to sign in. I used my forum credentials, no joy. Created a new account figuring it might need a “Local Account”. That let me sign in. But when I use this link even though it recognizes me as a user, it still says I have to sign in. What am I doing wrong? How do I get to this information?
Yes I did. It finds no reference to the case or CRM number
I will copy and paste the message below:
Hi George,
I have been discussing this issue with associates and this is their response after asking about a workaround:
That is the expected behavior as there is an actual response, not a timeout. It will continue sending the command until it gets a successful response. I would say that the correct action is to fix the reason to the incorrect Checksum. The only workaround I can think of is to replace the checksum object in the response with a data object and forward that either to the Input area or the General area and thus bypass the checksum, which otherwise must match the calculated checksum in that exact position. But, should you?!?
What are your thoughts on this? Is it possible we have mismatch of some type between the ways each of the devices calculate checksums? Seems unlikely because it sounds like it’s happening fairly rarely, but I could be wrong. Are there certain transactions that get stuck like this or do they all do it?
Kyle
Hi Kyle: Sorry it took so ling to get back on this I got drug off on another project. Anyway I think we have a misunderstanding. When the field device does not properly get the ASCII string the EN2SE sent it, it returns NAK (16), not the expected response. It is a response but not the response the EN2SE is programmed to look for (which could be ACK (06) ACK (06) or ACK (06) followed by data. I am not looking specifically for the checksum in the return data. That does indeed go to a memory location for comparison in the PLC to the expected value based on the data returned by the Query.
In that case, couldn’t we try using ‘VariableDataObject’ instead of ‘Byte constant’ or ‘Data’?