nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

about Sanity Check Error

medini_1064862860

Dear medini support Team,

I just want to know about the "diagnosis" feature implemented from 2023R2.

I tried replacing the procedure that derives the system model from separated FMEA with a script sample.(sample3_createPartandType_r03_forANSYS.js)

However, if I set "after script executing" in the diagnostic settings to "MAX", the following error will be displayed, but if I set it to "MIN", no error will be displayed.(refer to fig.1 and fig.2)

The Line 75 of the script file (sample3_createPartandType_r03_forANSYS.js), "part.theType = finder.findByType(Metamodel.sysml.SysMLBlock).toArray()[i];" seems to be the cause of the error.

Could you please tell me what is the cause of the error in "MAX" setting?

Also, the 2024R1 User Guide "15.2. Diagnostic Tools" does not contain any details. Could you please explain the error, the cause of the error, and how to resolve it?

I attached replication sample project that was created 2023R2.1.

<fig.1>

<fig.2>

1."after
script executing" of diagnostic setting set to "MAX".

2.choose both FMEA
model of "sample" and System model of "sample2" in the
model browser.

3.execute the
script "sample3_createPartandType_r03_forANSYS.js".

4.the error dialog of fig.2 will be displayed.

Please let me know the reason why occurred the error.

note; The sample script shows a simple method.

Best Regards,

Find more posts tagged with

medini

medini legacy

Accepted answers

medini_1024169437

Thanks Ka-lip, I think I undertood it exactly that way. My guess is, that the "failure mode synchronization" which synchronizes FMs between type and instance, is always running as a post-commit step *after* the script transaction. The sanity check I think (needs confirmation) also runs as post commit step but probabaly too early, maybe before the type synchronizer?

This of course makes the MAX sanity check somewhat useless. Kojima-san, could you please proof my assumption by running the sanity check after the script was executed, manually?

That should not give you any sanity problem.

Happy Scripting

Jan

All comments

medini_1064887566

Let me simplify Kojima-san's question.

When a type has FM, scripts cannot set it as other elements' type with MAX sanity check. And he wants to know the reason.

If the type has no FM or the sanity check is MIN or NONE, it can be done successfully.

 selection[0].theType = selection[1];

medini_1024169437

This of course makes the MAX sanity check somewhat useless. Kojima-san, could you please proof my assumption by running the sanity check after the script was executed, manually?

That should not give you any sanity problem.

Happy Scripting

Jan

medini_1064862860

Hi all,

I did by running the sanity check after the script was executed, manually.

However, Sanity Check Error did not occur.

I do not understand the medini internal detail, your assumption may correct.

Could you please check medini internal.

Best Regards,

Tamotsu.

medini_1024169437

Thanks Tamotsu,

that confirmation helped. I can confirm that this is an issue in the tool.

I have filed a ticket and we will probabaly fix that with one of the next versions.

Regards

Jan

medini_1064862860

Hi Jan-san,

Thank you for your reply.

I understood that this problem will be fixed in the next version or later..

Thank you very much.

Tamotsu.

medini_1040289819

Hi,

the issue has been fixed in version 2025 R1 of medini analyze.

Regards

Olaf.

medini_1040753747

I upgraded to 2025R1, ran the dynamic constraints, tried to adjust the dynamic constraints and now I get the Sanity Check Result after every script - even in a new imported project (but not all my projects). How do I remove it?

medini_1024169437

Hello Johan,

is this error dialog coming before or after script execution? The diagnostic preferences allow you to switch bith on/off independently.

If before, it means your project has some in inconsistencies before the script is executed, and thats merely a warning that the script may do more harm when working on a project with problems already.

If after, it means you script actually is the originator of these inconsistencies. In your example it seems the problem are dangling traces, so is that script creating or changing traces?

Note that under "Main Menu -> Traces -> Dangling Traces" there is also a tool to visualize and manage them.

Regards

Jan