simple, but very wrong, PLC structured text bombed the core.

[MrAdam1983]

at this point, this is an observation and report. I do not intend on trying to diagnose the issue.

I am not a code developer, however I was feeling confident after my recent 5 week AI lead Javascript crash course and decided I would slam out of some structured text to test my newly minted WebIQ widget. After about 20 minutes of back and forth and figuring out the syntax and methods I had about 10 lines of code that appeared to accomplish a button toggle. no errors, no messages so I tried to download.  First it complained about an unidentified exception, finally figured out it was a issue with the watchdog on the main task.  Me, an un-educated intellectual, tried to disable the watchdog.  Ctrlworks was not happy with that choice so I re-enabled the watchdog and set the time out from 20ms to 200ms.  Again I tried to download and it went, still showing an exception, but the PLC loaded.... and then crashed. ctrlworks completely disconnected and when i tried to re-connect to the PLC app the core became un-responsive. eventually i powered cycled it and noticed that none of my apps loaded on the home page, in the PLC tab the core reported that there was no PLC app, and trying to connect through ctrlWorks again locked up the core.  I now have a blinking yellow light on the core, none of the apps load but I am able to see the apps and licenses in settings.

Since there is a new 1.20 subversion available I am just going to reload the core, I attempted to backup the core configuration and the creation of that backup file failed.

I done did'er good, but I am concerned that I was so easily able to completely bomb the core and everything on it.  Seems like a potential issue to me. 

[CodeShepherd]

In general messing with an realtime system can be quite easy. So programmers in such system need to care about that.

In your case I guess you created code that on one side needed more time to be executed then the triggering interval was set to. (cycle time 10ms, watchdog 200ms, needed time for execution >10ms). In that case your code will at some point overload the calculation capacity of the CPU and realtime will be violated.

Also loading code to the realtime framework that will bring an exception to the system can do the same. For the ctrlX PLC we have e.g. own checker functions that can be implemented to prevent pointer or array access exceptions. See our online documentation.

[MrAdam1983]

and that all makes sense; however there is still a concern.  While I understand that the PLC application and development software cannot account for all Human error it bothers me that the entire core was brought down by this.  Seems like maybe there needs to be some sort of runaway app protection, maybe it's possible to uninstall the PLC app and then reload it; I did not try that before reloading the core. But at the same time i don't think it's in the best interest of the industry for the entire core to be mostly inoperable when just one app is in a undesirable condition, especially for a device designed around the concept of remote access as a core feature. 

I knowingly wrote something that I had very little expectation to function, but I did not anticipate it doing this.  i understand why it was was wrong now, but imagine some know it all doing this in production and bringing the entire system down.  This is the start of the argument I will have face internally about why and all-in-one device is not ideal.  I am already facing issues with my argument for palletizing our product lines and an error like this is not the argument "for" multiple cores that I need. 

[EngJay]

I had a similar experience one time where I crashed a core by reading a bit in the PLC app with the IDE app through the datalayer without proper delay.  Now in my case it did not actually crash the whole core, just the apps managed by the automation core.  And I was able to recover after a power cycle by uploading functional code into the IDE app, which still ran even with the automation core  in service mode.  Now if a customer is using a third party solution and is connecting different systems through another data broker, they would be just as capable of crashing part of the system.  So I prefer to look at it as a matter of risk versus reward of having connected systems.  If you are going to have connected systems, then an all-in-one-device is quite advantageous in providing a uniform architecture. 

[MrAdam1983]

but that is what we are being sold here.  This one device that can run multiple apps and do multiple processes.  That is the description and explanation of the system we have been given. 

[CodeShepherd · Accepted solution]

@MrAdam1983 And this is totally correct. But when working with several tasks/threads/processes you need to know what you are doing especially for interacting with the real time capable part. The ctrlX CORE as several cores that can be used so even stuck processes do not kill the system. But if processes using the same CPU or even sharing the same process room they will and do interfere.