Ignition server returns ServerStatus: null

Using prosys example opc client unmodified, the ServerStatus returns null causing an exception in the read thread. See out put below. Is there some configuration settings I have missed?

  • Running in EVALUATION mode
  • Connections will close after 120 minutes

08/01/2011 13:23:41.883 INFO [main] com.prosysopc.ua.ApplicationIdentity - Reading application certificate from C:\TEMP\development\eclipse\workspace\OPC_Client\PKI\CA\private\SampleConsoleClient.der
08/01/2011 13:23:41.888 INFO [main] com.prosysopc.ua.ApplicationIdentity - Reading private key from C:\TEMP\development\eclipse\workspace\OPC_Client\PKI\CA\private\SampleConsoleClient.key
Using SecurityMode [opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15,SignAndEncrypt]
08/01/2011 13:23:42.490 WARN [main] com.prosysopc.ua.client.UaClient - Using an alternate endpoint URL 'opc.tcp://xxx.xxx.xxx.xxx:4096/Ignition_OPC_UA_Server’

*** The Server Certificate :

Subject : CN=Ignition OPC-UA Server, OU=Inductive Automation, O=Inductive Automation, L=Sacramento, ST=California, C=US
Issued by : CN=Ignition OPC-UA Server, OU=Inductive Automation, O=Inductive Automation, L=Sacramento, ST=California, C=US
Valid from: Wed Jul 06 13:20:03 CDT 2011
to: Sat Jul 03 13:20:03 CDT 2021

08/01/2011 13:23:42.792 INFO [main] com.prosysopc.ua.PkiFileBasedCertificateValidator - Certificate ‘1706EC62AD5BC6BC11ADD1E290B18E648CE92992’ added to trusted certificates.
08/01/2011 13:23:42.793 INFO [main] com.prosysopc.ua.client.UaClient - publishTimer scheduled: period=1000
Exception in thread “TcpConnection/Read” java.lang.IllegalArgumentException: object argument must not be null
at org.opcfoundation.ua.builtintypes.ExtensionObject.(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getExtensionObject(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getScalarObject(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getVariant(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getDataValue(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getDataValueArray(Unknown Source)
at org.opcfoundation.ua.core.EncodeableSerializer$120.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.utils.AbstractSerializer.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.utils.SerializerComposition.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getMessage(Unknown Source)
at org.opcfoundation.ua.transport.tcp.io.TcpConnection$ReadThread.run(Unknown Source)
ServerStatus: null

Using the latest version of Ignition (7.2.7) and the OPC Foundation’s sample client I am able to read the ServerStatus node without any issues.

There may be an interop issue with the Prosys SDK; I remember contacting them about this or an issue very similar before and the conversation went back and forth until they stopped responding. I think right about the time I said “Look, the OPC Foundation client can read this and yours can’t.”

You might try contacting them? I’m willing to work with you/them to get this figured out so just let me know what you need.

Thanks for the input, I will start the process of coordinating with procsys. I will update this thread as I progress.

I am facing the same problem, it seems that the problem is that the information from the server cannot be received because i wrote some values with my client and then i read them from the ignition client and the values were successfully written.

if i get new information i will also update this thread.

Hi everyone,

a similar issue was investigated by Kevin and I in late February/early March this year, I thought that one was resolved after some fields were fixed in the ServerStatus. From what moralesm has told about this issue, on his system the ServerStatus is readable using UaExpert, so I think this issue is not exactly the same what it was last time.

Anyways, I am not currently able to reproduce the issue moralesm is facing (using Ignition 7.2.8 (b178)), since for some reason the ServerStatus node itself cannot be read, instead returning BadInternalError. Please see attached screenshot for how this looks using the OPC Foundation UA Sample Client.

Ignition logs the error as

[code]11:42:39 AM OPC-UA Server.ReadService Returning ServiceFault for request: com.inductiveautomation.xopc.common.types.messages.ReadRequest@799c056. StatusCode=StatusCode[Severity=Bad, Subcode=Bad_InternalError, 0x80020000]

java.lang.ClassCastException: java.lang.String cannot be cast to com.inductiveautomation.ignition.common.opcua.types.UtcTime
at com.inductiveautomation.xopc.server.core.XOPCModule$Provider.getValueForData(XOPCModule.java:485)
at com.inductiveautomation.xopc.server.core.XOPCModule$Provider.getValueForData(XOPCModule.java:342)
at com.inductiveautomation.xopc.server.infomodel.AbstractInformationModel.getData(AbstractInformationModel.java:37)
at com.inductiveautomation.xopc.server.nodes.infomodel.ua.UaInfoModelVariableNode.readAttribute(UaInfoModelVariableNode.java:54)
at com.inductiveautomation.xopc.server.addressspace.base.ops.ReadOperation.handleBefore(ReadOperation.java:86)
at com.inductiveautomation.xopc.server.addressspace.base.ops.ReadOperation.beforeExecution(ReadOperation.java:56)
at com.inductiveautomation.xopc.server.addressspace.base.ops.ReadOperation.beforeExecution(ReadOperation.java:34)
at com.inductiveautomation.xopc.server.addressspace.AbstractOperationHandler.handleOperation(AbstractOperationHandler.java:33)
at com.inductiveautomation.xopc.server.addressspace.base.BaseAddressSpace.read(BaseAddressSpace.java:195)
at com.inductiveautomation.xopc.server.addressspace.base.XOPCAddressSpace.read(XOPCAddressSpace.java:266)
at com.inductiveautomation.xopc.server.core.services.attribute.ReadService.executeInternal(ReadService.java:41)
at com.inductiveautomation.xopc.server.core.services.attribute.ReadService.executeInternal(ReadService.java:19)
at com.inductiveautomation.xopc.server.core.services.AbstractService.execute(AbstractService.java:52)
at com.inductiveautomation.xopc.server.stack.AbstractUAServer$RequestServer.run(AbstractUAServer.java:69)
at com.inductiveautomation.ignition.common.execution.impl.BasicExecutionEngine$ThrowableCatchingRunnable.run(BasicExecutionEngine.java:526)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)[/code]

Until I can get this error out of the way, I cannot get to the bottom of what goes wrong when our client tries to read Ignition’s ServerStatus. Can you Kevin give a hint as to what might be going wrong with Ignition here?

Best regards,
Otso Palonen

That stack trace shows a problem in Ignition reading ServerStatus.BuildInfo.BuildDate. It looks like for some reason the build date String isn’t being parsed into a Date object when you read it, Otso. Maybe there’s something funny going on with locales…

I need to at least make a change so that the BuildDate falls back to a valid UtcTime instead of a String, as that’s what’s causing the the ClassCastException in the stack trace.

Otso, I’ve posted a new version of the UA module that shouldn’t produce the internal error you were seeing. You can download it here.

Thanks for the fix Kevin, now that problem seems to be solved and I can read the ServerStatus using UaExpert.

The immediate cause of this problem seems to be that in the Java stack, when the ServerStatus ExtensionObject is being decoded, the length of the object body is read from the stream as -1.

I’ll continue analyzing the problem and report to this thread.


  • Otso

Okay, I tested the issue also with the .NET stack version 1.1.329.1 and indeed the length of the body is -1, which is not a valid length. According to OPC UA Part 6 section, “The length shall always be specified.” The .NET stack (and apparently the C stack as well) does not care about the length in this case as it uses a slightly different implementation strategy for decoding ExtensionObjects. I believe that if the length of the ExtensionObject body would be correct, there shouldn’t be any problems with it since everything else seems to be in order.

Hope this analysis helps in fixing the issue. If any further troubles arise, please let me know so I can help in fixing them.


  • Otso

I’ve got a comment in my binary serialization code that says “// Built-in UA type - we can omit the length.”

Time to investigate the validity of this comment… Glad we’ve got the problem narrowed down :slight_smile:

I’ve fixed the binary encoding logic so that it always encodes a length. You can download a beta version of the module that includes the fix here.

Please let me know if this fixes the problem for you guys.

This update apears to have fixed my problem. I will have more time later in the week to perfome additional testing but looks good for now. Thanks!