Missing data in block array writen to PLC


We are experiencing intermittent data missing in a block item array of 180 real values that is retrieved from a database and written in a control logix 5000 PLC. For example the query will return 177 items and PLC data element array position 68 will have data not written at all. It can be at different areas of the array, but it looks like Factory SQL did not write a value in that position at all. How we tested this was we pre-populated the array in the PLC with values of -44, which will never be in the database. Then trigger the query and FactorySQL will populate the array with the “POSITVIE” real values that was retrieved. We notice that occasionally some of the indexs in the REAL array in the PLC will still show -44 indicating that the value never got written to from FactorySQL.

We are hoping that you have seen this before and can advise us of how to resolve this problem.


James Williams


I noticed that in your email to support, you mentioned that you were using RSLinx. I would check there first, under OPC/DDE>Communication Events, to see if anything was reported.

Also check the log in FactorySQL (Help>Log Viewer). Are there any messages at all from when you tested?

Some sort of error must have occurred along the way. However, since I suspect your trigger is either reset or set to “only execute once”, when the writes failed for the values, they were not attempted again. If that’s true, you may try to not use those modes, but instead reset the trigger through the success handshake (if you give me more details on how your trigger is set up I can guide you better).

FactorySQL has always been rather reliable in these types of situations, but there are some tricky situations that can come up, as I just described. Also, RSLinx is unpredictable at best, though I won’t start down that road until we have to.


The trigger is setup to reset in FactorySQL.
We also have a handshake signal for pass and fail. We are always getting a pass.

I did not see anything reported in FactorySQL, as for the log, I get an error when I try to open Help->Log Viewer.

The problem is that that in a continuous array of 180 float 4. Some data points are missing or not written at all.

I will check RSLinx OPC/DDE tomorrow. But I hope that a solution exists to this known problem.



The inability to open the error log could indicate corruption in the internal database. The good news is that in the instances we’ve seen the database get corrupted, the corruption has been isolated to the error log portion, and it’s usually fairly easy to recover.

In the FactorySQL install directory, look for “system_database.fdb”. How big is that file? If it’s over 1-5MB, it’s likely that the error log has been corrupted.

Corruption in the error log could possibly affect the rest of the system, depending on a few different things. If errors are occurring, they wouldn’t get written. The rest of the system might slow down quite a bit.

If you’re getting the success handshake, however, it indicates that the system is receiving successful responses from RSLinx. The question is, are the responses erroneous, or is FactorySQL not attempting to write all of the data.

I would recommend the following course of action:

  1. We need to resolve the error log issue. I can advise you over the forum, or if it’s possible for you to call into support, we can help you over GoToMeeting.
  2. We should have you install the OPC Analyzer tool and set up a test case for this group that goes through it. In this way, we can see exactly what FactorySQL is trying to write, and what RSLinx is responding with.
  3. We should also try the test with synchronous writes, instead of asynchronous. This is a setting under Service Settings in FactorySQL.

The analyzer can be downloaded directly from this link. It’s really very simple to use: start it, and point it to RSLinx. In FactorySQL, you’ll see it show up as another OPC server. Copy your group, and use Search & Replace (from the group’s right-click menu) to change the server name. Then, everything that happens through the group will be traced in the analyzer, and you can export it for us. Of course, we can help with all of this, if you’re able to call in.


Hello Clegg,

We have isolated the problem to specific floating point values and we are able to easily reproduce the problem at specific points. For example, if the database has the value 96.69999125, then it does not write to the PLC, however if we change the value to 97.1, then it writes into that array column all the time. Now the two numbers that I just gave you are not the exact onces causing the problem, but the problem is reproducable. I went ahead and installed Ignition and setup the groups and we have not had a single problem with the writing of data into these arrays. So I am not sure if the problem was in FactorySQL, or RSLinx, all I know is that Ignition uses its own OPC driver which eliminates RSLinx.

Please advise, because our company is requesting that we get a refund on FactorySQL to apply to the purchase of Ignition. We do not have time to do all of this analysis at this time, because we have a very upset customer already.

Thank you,


Ignition can also communicate with RSLinx via the OPC-COM module. I would be interested in seeing if using Ignition + RSLinx caused the problem to start happening again. By switching to Ignition and moving away from RSLinx at the same time you’ve eliminated any control variables.


Your observation about the number is interesting. What database are you using, and what is the data type of that column in the database? It would probably be easiest to export a back of just that table and send it to us. It’s possible that there is some sort of data conversion error occurring in FactorySQL (which unfortunately we can’t see on your system, because you can’t open the error log). If that’s true, we can fix it in FSQL- or we can work with you guys to transition to Ignition.


The database in use is MySQL.

Here is a small subset of the data creating the problems, entry 17 will produce the problem every time.
If I change the value to 96.9, then it writes to the PLC array element.
But some numbers are simple decimals and they will produce the same problem.
In this subset that I provided, you will notice 3 or 4 others that create the same problem.
The database use double as the floating point data type. (Standard SQL92). Of course the PLC uses FLOAT32. So, I did suspect that there are conversion going on, but really that is a simple casting in your programming environment, which is part of the compiler that you use to build your application, so I ruled that out. Unless you are doing something non-standard. Other compiles with do this automatically, without your interaction.

1 5.69999980926514
2 11.3999996185303
3 17.1000003814697
4 22.7999992370605
5 28.5
6 34.2000007629395
7 39.9000015258789
8 45.5999984741211
9 51.2999992370605
10 57
11 62.7000007629395
12 68.4000015258789
13 74.0999984741211
14 79.8000030517578
15 85.5
16 91.1999969482422
17 96.9000015258789