OS-147 Assert MAIN %d %d %s

    This has been a recurring issue for several months now, and i would like to see if anyone else has had this issue.

    When it began, it occurred on one robot. It would be operating normally, and then typically at the start or end of a weld, we would receive a SYST-302 (Please Power Off) and a OS-147 (Assert MAIN %d %d %s) Alarm, requiring us to cycle power. Then the robot would be fine for a while. At first, it would go 4 to 6 weeks between occurrences, then it slowly increased in frequency until it was occurring daily.

    All of the help i have been able to find regarding this fault say to contact Fanuc, which we did, but the variable place holders have never been filled in with the two numbers and the string that they should display in place of %d %d %s. Fanuc suggested it may be a memory card issue. We took an image backup, reloaded it, and it went away. For a while. After a couple of months, it started occurring again. This time, Fanuc suggested that since we were on version 8.30p/11, we should do an AutoUpdate to 8.30p/36 (latest at that time).

    I took an image, and an AOA backup, reloaded the image to verify it had worked, then attempted the AutoUpdate. The AutoUpdate went through the first sections fine, taking its own backups of the different drives, but after the first power cycle, it update the BOOT monitor version, and stopped. The AutoUpdate screen displayed a failure message, but otherwise no indicator was given that anything had gone wrong.

    We have sent the AOA and Image backups, as well as the backups taken by the AutoUpdate to Fanuc, but we have not heard back yet.

    1. Has anyone else had an issue with Assert MAIN, specifically with it not filling in the placeholder variables for debugging?
    2. Has anyone performed an AutoUpdate across such a large version gap, and was there any indicator after the first power cycle that the update was still ongoing?

    Robot in question is an R-30iB A Cabinet, with an ArcMate 120iC 12L robot, and it is from Fanuc Europe.

    Edited once, last by Robo_Eng_13 (March 5, 2018 at 3:18 PM).

    Update, in the hopes that someone will have some information.

    Fanuc was able to replicate the Auto Update failure from our image backup. Their solution was to perform an Init Start, load the AOA backup, then re-attempt the Auto Update. They succeeded with that method. I attempted it on a similar physical system, but it failed the same as before. Fanuc has provided the updated image, however i have some concerns.

    1. We have no identified what has caused the failure. Since the failure is happening on brand new cells that are not presenting the original fault, i do not feel confident that we can write it off as some mystery corrupted file. It seems more like something is actively preventing the update.

    2. Whatever is stopping the update is most likely not re-loaded if the auto update is then able to work, which might mean the cell will fail to operate at afterwards.

    3. Since i replicated their actions on a real robot and got a different result than their virtual robot, i feel that some of the peripheral equipment could be causing the issue. During the Init Start, i watched as the external axes we are using were setup automatically. I doubt this occurred on the virtual robot.

    If i am able to get the updated image onto a flash drive before the weekend, i will try to load it during our scheduled downtime on sunday, but i do not have a lot of confidence that it will solve the problem, or function at all.

    If anyone has had any issues like this, i would appreciate your insight.

    I would first check all the the cables for proper screening, isolation, placement and fixing, maybe the welding equipment causes a noise or interference which in turn causes some kind of disturbance in controller's electronics?

    Quote

    During the Init Start, i watched as the external axes we are using were setup automatically. I doubt this occurred on the virtual robot.

    this happens automatically, during the procedure the controller is just reading-in data that is stored in .dt files (ext.dt, exta1.de and so on) in the backup.

    Final Resolution:

    We are still unable to successfully perform an Auto Update in house, however Fanuc was able to successfully update an image that we took and sent to them, and we were able to successfully reload that image onto our robot. Currently, the root issue appears to be resolved, and it did not fix a side issue we hoped it might, so we are no longer actively pursuing rolling out version updates to all other robots. In addition to the update, we also upgraded from 32MB DRAM to 128 MB DRAM, (driven by the fact that the controller no longer had room for additional programs after update) so we do not know for sure which operation actually resolved the issue, or what the true root cause was.

Advertising from our partners