Yeah I’d go with 5 hours to be safe.
I’d start more simply first. Clear the DTC and see if it comes back. This is a communication error, not a configuration error. It might have been a one-time glitch.Yeah I’d go with 5 hours to be safe.
Drove the truck and came to scan it again.
Got an IPMA DTC so should I PMI it or run the update on IPMA like it’s asking?
Mine is showing the same after completing the updates.So I finished… it all went successfully as far as I could tell. Ran network test on mongoose and the IPMA still says update along with the PSCM.
Instead I’m going to leave the truck off for 30 minutes, drive it. And see again later.
Appreciate the tip. I ran the Self Test after the PMI. Running boards went in and out, seat and steering wheel moved and the results say it passed. Unfortunately the functions have not returned. Thx again!
I hear what you’re saying. But what if a network scan had just been performed subsequent to the module flash, followed almost immediately by the use of the FDRS [module] configuration command. Wouldn’t that pull down the very version of the as-built that the Nano just corrupted?
Yes it would. Each module SW update thread runs "module configuration" which basically restores the "latest known" configuration to the module. Either is the one retrieved by Network Scan or the one retrieved from the cloud. The thing is, both of the sources might already have his corrupted (or misconfigured) data hence the best bet is to restore the ForScan backup taken prior changing the configuration (with ForScan). PMI in fact is not even needed here, especially if his module SW version is up to date. Just ForScan backup restore. That's it
If the errors are gone, I’d leave it alone and check again tomorrow.
Ok. That’s what I thought. I was focusing on how it happened for future avoidance. Less on the remedy, which entails finding an uncorrupted source for the as-built data. I think how it happened—running the FDRS configuration command right after the module update confirms that using FDRS’s configuration tool is very risky if using the Nano and should be avoided. Stick to the PMI as the initial course of action if you need it to complete the configuration post-update.
Again, I am yet to see an evidence that VCX Nano corrupts the actual configuration data in As-Built data set. If he has some corruption, it is likely a result of "human error" when applying ForScan changes. So, assuming he has VCX Nano device and he ran Network Scan, his configuration data for given module would be intact, or contain the same corruption that ForScan changes produced. Not by VCX Nano itself
Saw that in a post too but not on my truck still after the updates. Currently just waiting it out.
Well, that’s why I asked the question a couple of posts ago. Take this hypothetical. User has never, ever, run FORScan. User updates module X with the Nano, but for some reason, the update has a problem—something akin to a U2100 configuration error. Instead of running a PMI to complete the configuration, user executes the FDRS configuration command which attempts to grab the as-built data. This all happens so close in time that the truck has not had the opportunity to self-report. Wouldn’t the config command grab the as-built data that the Nano just corrupted? That is the question I asked previously.
Yes, this helps. Sounds like the dataset has split purposes—part of it is for module restoration, part of it is for reporting/administrative purposes. The same part of the dataset is not used for both purposes and the Nano corrupts only the administrative portion. I understand now. Thanks.
