This is my first B&R project and first PLC project. I’m using AS 4.12.6 with an X20CP1684.
After I do a transfer, the PLC enters Service mode with the error code -1070584042 “OPC UA Connection failed.” The system hosts an OPC UA server, which I only use to bind variable values to values on mappView HMI inputs/outputs. I don’t have any operations that connect to an external OPC UA server or client.
If I leave the Endpoint URL in the OpcUa_any configuration as “opc.tcp://” (default, which it was last week) it says “connect to opc.tcp:// failed E:0x80ab0000”. If I put in the IP address “opc.tcp://127.0.0.1:4840” (which is what I want for the internal server, right?) it says “connect to opc.tcp://127.0.01.:4840 failed Server_ServerStatus_State not 0 (Running)”
Last week it worked fine, then I flubbed something in my git repo and lost a couple days of work. I’ve pretty well recreated that lost work plus a little, including my first attempt at using event binding to change a widget Style using an opcUa.Event. Best I can figure - maybe some configuration file/parameter got buggered somewhere in this process?
Everything I know to look at looks how I think it should - the OPC UA system is activated, port numbers and IP addresses are set, and theoretically nothing related to OPC UA config is different from how it was last week, when it was working
B&R help info is pretty slim on how to troubleshoot this error, and all assumes you’re trying to connect to an external server.
OPC UA Connection failed should not send the PLC to Service mode unless you have set the Module supervision to ON on the OpcUa_any configuration. If you have I would recommend setting this to off and monitoring the status of the connection via the ModuleOk input on the IO Mapping of the OpcUa_any client.
Are you sure that error message is the cause of the service mode? If you are willing to share a system dump the community could try to see what is the actual cause for the service mode.
Module supervised is off. You know, I assumed it was the cause because it was the only error message I saw but it turns out I didn’t scroll down far enough. It didn’t register that it said “57 errors” at the top, so that’s embarrassing haha.
There’s also a page fault error/exception (ID 25314; all OS Task Data values are 0’s) and a “Stack underflow in task” error (ID 6803) and a memory access violation (ID 6804). Those do sound more likely.
I can attach a dump file if that’s still helpful in light of the new info
Systemdump is not really helpful with the page faults.
You should be able to pinpoint the source of the page fault with the backtraces. If this occurs during/after a transfer you are most likely not assigning pointers cyclically and during a transfer memory can shift around.
There is a great article here in the community for troubleshootin page faults.
Ahhh I did not know that, good to know! Yeah I assign a few pointers in an INIT portion of one package. Is it best practice to set them every cycle? Or is it okay to set them in a Reset or Init state in the cyclic program, that only gets run occasionally?
After moving all pointer assignment into cyclic programs I no longer see page fault errors, but still stuck in service mode. The remaining errors are the OPC UA error and also error 9206 “Restart of the PLC triggered by hardware watchdog.” If it makes any difference, I’m working in structured text.
I do use a lot of pointers like brsmemset and brsstrcat and itoa/ftoa, but very few of them should execute in the baseline/idle state. I don’t see a cycle time violation (I assume that would appear in the Logger?).
This depends on whether you are targeting for being able to transfer changes without restarting / stopping the machine. But this topic is a lot bigger than just pointers.
To exit Service mode you need to perform a “Warm restart” of the controller, either by power cycling it or commanded from Automation Studio. The hardware watchdog will send the PLC to service mode too.
A quick tip for any messages in the logger is to select the message and press F1 on your keyboard, this should send you directly to the help page of the message
If there is any new reason to send the controller to service mode, such as a cycle time violation, these would again be visible in the logger. In service mode the PLC is not executing your “user programs”.
A quick tip for any messages in the logger is to select the message and press F1 on your keyboard, this should send you directly to the help page of the message
Slick! Thank you!
I have a run a couple warm restarts, both through AS and with power cycle. Though, now I’m back to having a page fault error (ID 25314). There’s no backtrace but it does give me some OS Task Data in the details (it says it’s TC#1 - does that mean it was in the cyclic #1 task?). There’s also a “Memory access violation” error on the most recent warm start (ID 6804), immediately after the page fault.
Is it safe to call e.g. brsmemset(ADR(variableName), 0, SIZEOF(variableName)) in the INIT program, or can ADR also cough in that instance, like setting a pointer in the INIT program?
Okay it looks like the page fault happens on power cycle but maybe not on AS-initiated warm restart? After another power cycle, it showed up again but with no backtrace and also no OS Task Data. This time followed by a “Stack underflow in task” error. Good stuff…
It is safe to use pointers in the INIT program, but you need to be mindful that when you do a transfer the memory locations might change, which might result in your pointers pointing to the wrong places.
Page Faults, Stack Under and Overflows are usually caused by programming errors, please follow the Troubleshooting Page Faults guide and feel free to contact your local B&R support if you need more assistance.
