Ignition 7.3.3 stops to work with error

Hi!
I have a project wich gateway data between two OPC. System start to work and work a few hours. After this the tags stops to updates and writes to another tags and the errors occures in console. What is the reason? Log attached
logs[1].bin.gz (205 KB)

Hi,

It appears that the system may be running out of memory. We occasionally see issues like this with the OPC-COM module, but it’s not always clear what the cause is. Could you tell me:

  1. How many tags are in the system? You can view this by going to Status>SQLTags in the gateway.
  2. Which OPC servers are you using?
  3. Are any of your scan classes or transaction groups set to “Read” mode for “OPC Data Mode”?

It may be that there are too many tags. However, there may be a problem with the library we use for COM access. I might be able to get you a test version with the latest library later today.

Regards,

I have 3820 tags and 52 scan classes

I have two OPC. Lectus Modbus OPC server and EIBA OPC server (for KNX systems)

All of my scan classes seted to “Subscribe” mode

Now on the second machine i have the same error…It works about 3 hours and crashed…

Hi,

Could you tell me the following:

  1. What version of Windows are you using?
  2. Is the system 64-bit? I know you’re using 32-bit Ignition, but is the overall system 32-bit as well?
  3. What version of Java is Ignition running on? You can usually get this by going to the command prompt and running “java -version”.
  4. What do the virtual memory settings look like for both systems? From what I can find online, a lack of sufficient virtual memory in windows can sometimes cause errors like this. Go to System Properties>Advanced>Performance>Advanced>Virtual Memory.
  5. How much RAM is on the machine? Is there a good amount of disk space free?

I need to try to figure out why you have 2 systems that are failing, while most people run without a problem. Problems like this come up occasionally, but I’ve never been able to replicate them here. There must be some specific thing that is different on your machines.

Regards,

Hi!
1,2) I use the WinXP SP3 and it is 32 bit;
3) Java version is 1.6.0_29;
4) The virtual Memory is setted from min amount 1524 MB to max amount 3048 MB;
5) We have 1GB of RAM Memory and Intel Atom 1.6Gz CPU N270 processor. This is the Arbor PC
FPC-3100_20111213.pdf (711 KB)

I see… does this box have a hard drive? I’m fairly sure the system must be paging memory, and it seems possible that it could be running out of virtual memory. If you have a hard drive in there with enough room, try increasing the max virtual memory and see if the system will run for a longer period of time.

And since you only have 1 gb of ram, you might want to set the max mem of Ignition to a lower number, which defaults to 1gb. You can do this by editing “ignition.conf” in install directory (under “home”, I think). You can try setting this to 512, which may help reduce paging.

Regards,

One more question…
How are you think what is the best way to gateway data between two OPCs? I try to use the DB tags with Write Value back to OPC option. I tested it and find that sometime i have the error writing to OPC in console (“Error Writing to OPC addrees [tag address] Result code [OPERATION_FAILED] Device didnt responde”)and data was not updated. I use the leased scan class for variables wich i try to write. Slow rate is set to 0 and fast rate to 5 sec. In OPC sever this variables doesnt subscribed, until i make this tag active. When i look on this tags i see that values overwrites from DB tags, but not in all cases. Can be the reason in Slow rate=0?
Also i try to use the transaction groups. I set execute group only if any of tags changes it value. Update rate is set to 1 sec. Group started successfuly. But when the tags comes to bad quality ignition try continiously write data to tags. It overload the OPC server (it continiosly send write requests to PLC) and it cannot update other data…

Yes we have 250Gb HD. I will make this changes and let you know about result…

is the line wrapper.java.maxmemory=1024 ned to be changed?

Yes, that’s the line.

As for how to write OPC-to-OPC… there are a few ways, though unfortunately nothing as simple as an “opc-to-opc” transaction group, which we really should make!

Here are a few different ways:

  1. Use a transaction group, put all items (directly from opc, not sqltags) into the group. Set their targets to “read only”. Set the group to update the first row of a “dummy” table (it won’t be used). Turn off “auto create table”. For each tag pair, create an expression item whose expression simply references the first item, and set its write target to be the second item.

  2. Use gateway tag change scripts. Add all of your tags from OPC A to the list. In your script, make a lookup map between opc a and opc b. When change events occur, you can take the value (“newValue” in the scope of the event) and write it to the other server, after looking up the new path with “event.tagPath”.

  3. Make two transaction groups. In one group, put all items from OPC A. Have them update the first row of a “transfer” table. In the other group, put all items from OPC B. Set it to also look at the first row of the transfer table. Map the item targets to the existing columns, created by the first group. Set its mode to DB-to-OPC (or set both groups to be bi-directional).

Hope this helps,

Also, I should say: if you’re going to use SQLTags for this, I really don’t think you want to use leased scan classes. Those are useful for tags that are only used for display, not for processing. A least rate of 0 basically means “do not use”.

Regards,

What we may do when the PLC goes to offline? Ignition continiosly try to write OPC items with bad quality and overloads the OPC server ((

Well, if you were using transaction groups, you could set up a trigger which was based on the item quality. For example, you could make an expression item that was a boolean, and was an expression like:

toInt({Path/to/Tag.Quality})=192

And then set your group to only run when that was true.

Beyond that, I’ll have to see what else we can do. Writing to the server shouldn’t overload it, it should just return a “write failed” error, but of course it would be better to avoid writing at all if possible.

Regards,

Hi Colby!
Thank you for help! I configure the transaction groups to read values direct from OPC (not SQL) and all works perfect!!! It doesnt call the write requests on OPC server when the controller is offline (tags BAD) what i have when used the SQLTags in group. I am happy))

In addition want to say that i increase the amount of virtual memory and decrease the max Ignition mem and errors stops occure…Thanks. Also i think it occures becouse of my mistakes in project (

Hi,

That’s great. I thought it wouldn’t write with bad quality, but I guess that’s only with OPC tags.

Keep me posted on the other error. It might very well not be a problem any more with fewer writes, and no writes when the device is down. I spoke with the company that makes the COM library, and they said that that error could happen when one side is overwhelmed or blocked, and the side continues to try to post commands- which might be the case if your opc server was getting overloaded as you thought.

Regards,

Sooru for offtop (just our workday finished, we have 20.00 at clock). Can you help me in this topic
viewtopic.php?f=72&t=7596

Hi,

I’ve been looking into the error “not enough quota to process the command”, and it appears to be related more to the system (either Ignition or on the OPC server side) getting “overloaded” with operations to process. This could happen with a lot of changing data, or many read/write operations. In this case, before you made the changes in this thread, you were executing many more writes than you intended.

I’m still investigating exactly what can cause this, what level of activity is “too much”, or if this can be related to other things going on in the system. I’ll post back when I find out more.

Regards,

Hi Colby!

I have get the deadlock and attached the needed files (include the print screen) to confirm that it is error you talk in PM before.
thread-dump.txt (54 KB)