You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our industrial partners have frequently encountered the following problem:
They import a unifmu (python backend) into Similink, And then when they press the simulate button and simulink, because of some error or another in the backend, the whole simulation hangs and simulink needs to be killed.
80% of the times this is some unhandled exception on the python backend that causes the process to crash, but you and FMU continues waiting for the reply. Most of the times I can find a work around that involves logging on the Python back end onto a file and then inspecting that file to figure out what was wrong but I feel like there should be a better way to catch exceptions in the back end and send an error message back to the uni fmu so that it gets logged in the proper channels.
We could always blame the user for not logging things properly (and I do blame them!😋) for not testing the fmu before running it, but some of our users are not aware entirely about how unifmu works behind the scenes so this would increase the usability.
The text was updated successfully, but these errors were encountered:
Our industrial partners have frequently encountered the following problem:
They import a unifmu (python backend) into Similink, And then when they press the simulate button and simulink, because of some error or another in the backend, the whole simulation hangs and simulink needs to be killed.
80% of the times this is some unhandled exception on the python backend that causes the process to crash, but you and FMU continues waiting for the reply. Most of the times I can find a work around that involves logging on the Python back end onto a file and then inspecting that file to figure out what was wrong but I feel like there should be a better way to catch exceptions in the back end and send an error message back to the uni fmu so that it gets logged in the proper channels.
We could always blame the user for not logging things properly (and I do blame them!😋) for not testing the fmu before running it, but some of our users are not aware entirely about how unifmu works behind the scenes so this would increase the usability.
The text was updated successfully, but these errors were encountered: