2
« on: October 31, 2019, 01:16:06 PM »
I am currently using v3.97d, EthernetIPforCLXCom driver. My application acts as a data server between a CompactLogix PLC and a SQL Express database. The application has about 25 data subscribers, each of which listens for a boolean PLC tag. The DataChanged event handler has the following typical format:
* Read one or more PLC tags
* Execute a SQL stored procedure
* Write the returned results to PLC tags
The PLC tags are fields of a UDT, mostly INT and BOOL data types, although there are one or two STRING typed tags.
This application has been working well for around four years now, but there is one nagging issue that has recently hit the customer's radar: when the PC is rebooted, and the data server application starts, the first DataChanged event of each subscription fails with an exception. Second and subsequent events work just fine.
Unfortunately I do not have the exact exception data, but if memory serves it is a conversion error, and there is nothing that points to where in the code it happens.
I am verifying that I have an established connection with the PLC before processing subscription data--by this I mean that when I handle the ConnectionEstablished event, I am starting a heartbeat timer with the PLC. The PLC will not initiate any "triggers" until the app reports it is connected and the heartbeat timer is active.
Also, when an error happens, I write an error code to the PLC, and it successfully receives this tag write.
I have updated the application to v3.99x, and simplified it quite a bit. I now use one DataSubscriber2, add all the tags I need to listen for, and in the event handler I branch with a select statement based on the PLC address. However, I am currently off site and cannot test.
My questions are:
1) Are there any known issues in v3.97d that could cause the described behavior?
2) My poll rate is set to 500ms. I don't really want to make it too long, as the app needs to have a fairly quick response time. Could poll rate be a contributing factor?
3) Is there a better way to listen for my trigger tags, or to read/write the additional tags when a trigger is being handled?
Thanks,
Scott