04-13-2012 03:36 AM - edited 04-13-2012 03:37 AM
Here is the console output (attached). This is with no network connected, prior to this startup the controller was online with DHCP and ran as it should.
04-13-2012 09:07 AM
Ouch, it appears you've got much more going on than "it's falling back to Safe Mode." Apparently Logos (our communication protocol workhorse) doesn't like not having a NIC, because it seems to be implicated as the module crashing on boot - this is why the system is falling back to Safe Mode, thus Safe Mode is definitely not "intended or expected behavior." On your target there is likely a file called, "rtlog.txt" in the /ni-rt/system directory - can you find this file and attach it? The log file you provided is "tainted" between printing the crash information and normal startup information, it's hard to partition the crash details from the startup info. The rtlog.txt would exclusively have the crash info and would be very helpful.
I'll begin the process of getting my hands on a cFP-2220 and have the owner of Logos take a look at this, maybe we can figure out what's wrong and possibly get you something that will work.
Could you also possibly include a MAX technical report for the controller showing the software installed?
04-13-2012 09:19 AM
04-16-2012 02:25 PM
Okay, we've reproduced the problem in-house, and we've got a developer looking into why the crash is happening. Hopefully we can get to the bottom of what's going on and maybe provide some kind of a workaround for you. I do not have an ETA, but I wanted to let you know it's being looked into.
04-26-2012 09:12 AM - edited 04-26-2012 09:19 AM
This issue is being tracked by Corrective Action Request ID 349598. The change is on track to be included in the next release of the FieldPoint driver, but that is subject to change. Is solution delivered this summer acceptable?
09-13-2012 01:55 AM
Has this been resolved now?
We've run into another issue where the controller refuses to start the software. This time it has DHCP contact and launches the application once, but when this application tries to reconfigure the IP and do another restart it ends up in a software error state. The hunt so far seems to link the problem with a temp file possibly created by the System Configuration API.
Under ni-rt/system/ethernet there is normally just a single file; netconf.ini. Hower, on the device that kept crashing there was a tmp file as well. It could be accidental, but we did lots of other trials that failed until we deleted that file. Since then it has worked fine.
I'm speculating (on a very thin basis...) that the system uses a temp file during reconfigurations, and that something (power failure?) caused this temp file to remain. Then there is a bug that prevents new reconfigurations to succeed because the temp fiel blocks creation of a new one...Could that be the case?
I've attached the crash log here. (This might fit better in a separate thread, or not...I'm trying to get the attention of you gurus so perhaps this thread is the most effective one ;-) ).
09-13-2012 06:07 AM
The mystical temp file was named ini$$0.TMP, and contained the same as the netconf.ini file, but with different values.
As mentioned the software would crash as long as this file was present.