I am trying to run a model in Simulink, available for download here (direct).
I have been able to run it on a Linux machine, but on Windows it seems to get stuck at the compiling step. At the bottom of the screen I see two green bars, and the message "compiling: evaluating block parameters." It never goes beyond this.
I have tried choosing a compiler using the mex -setup process, but to be honest, I suspect this is not even close to what I need to do.
Any advice would be appreciated.
Related
I'm using DrRacket to develop R6RS programs but I often see a bug where DrRacket hangs when either clicking on Check Syntax or Run. For example when checking syntax the message 'Check Syntax: expanding expression' is displayed at the bottom of the DrRacket window but no progress is made. Clicking on Stop shows the error message
C:\Program Files\Racket\collects\compiler\cm.rkt:213:2: user break
As far as I've been able to tell the problem always happens when running a program that imports a user library. I'm able to run the user library directly but for some reason there a problem when importing that same library into a program. I'm also able to use raco make on the same program without any issues, so I don't think there is any problem with the code.
A few more details. When I see this problem the Windows Task Manager shows that DrRacket is consuming no CPU (although a lot of memory). The memory use indication at the bottom right of the DrRacket window is ticking over, showing that DrRacket has not completely frozen. This feels like a thread deadlock situation to me. I have the latest version of DrRacket (8.7).
Any solution or workaround would be appreciated.
I'm tasked with upgrading a lot of legacy models and scripts made in an older version of Matlab/Simulink and have it running smoothly in R2018b. Among other requirements I'm not allowed to have any warnings issued upon execution of .m scripts or Simulink models. This is generally tedious but straightforward to comply.
However, there is a specific warning that Matlab does not give me hints on possible sources:
Warning: MATLAB has disabled some advanced graphics rendering features by switching to software OpenGL. For more information click here.
The link opens the Matlab Help page titled Resolving Low-Level Graphics Issues, which describes issues I'm not finding (or at least not noticing)
I do note that many scripts I run create and close figures, but this is done procedurally. I haven't been able to associate this warning with some specific function or feature. I'm working on a Windows Server machine.
Does anyone have an idea of how to narrow down which kind of function os Simulink block could cause this warning?
As datenwolf and Ander point out, the first thing to try is to update your drivers. If this doesn't work, and your only problem is that you're getting the warning but your graphics still render fine, then you have two other options to try.
First, you can simply modify your OpenGL rendering preferences using opengl. The following will set your preference to 'software' and save that setting for future sessions:
opengl('save', 'software');
Alternatively, you can just try to suppress that particular warning message. After you get the warning, issue this call to the warning function:
w = warning('query', 'last');
The w.identifier field will give you the ID for the warning message, which I believe will be 'MATLAB:hg:AutoSoftwareOpenGL' in this case. You can then add the following line to your startup.m file so that this warning is suppressed every time MATLAB is opened:
warning('off', 'MATLAB:hg:AutoSoftwareOpenGL');
Install the original vendor drivers for your GPU. The drivers that are installed by Windows by default lack full OpenGL support. Download the driver package directly from the website of Intel, AMD or NVidia, depending on what GPU you have.
If you don't have GPU, for example when running in a Virtual Machine, then you can not avoid that warning, because then Matlab has no other choice than falling back on the software OpenGL implementation that it ships with.
There's nothing you can do about that, other than making sure, that the system you're running Matlab on, does have proper OpenGL support!
It took me a long time to get it, so I'll put you here in case it helps how I managed to activate openGL in Linux:
If you haven't already (it's common for other problems), rename libstdc++ library from MATLAB:
mv _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6 _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6.bak
Create this link: sudo ln -s /usr/lib/x86_64-linux-gnu/dri/ /usr/lib/
Run export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER;matlab -desktop -nosoftwareopeng
Your DRI Driver will be a file from /usr/lib/dri, removing "_dri" (in my case was the "radeons" driver for an AMD Vega graphic card.
Run MATLAB from a terminal using: export MESA_LOADER_DRIVER_OVERRIDE=_YOUR_DRIVER_HERE_;matlab -desktop -nosoftwareopengl. YOUR_DRIVER_HERE should be your driver, radeonsi in my case.
Check openGL with info = rendererinfo
If something went wrong, you will be able to see in the terminal which library was responsible. Executing 4) and 5) I was discovering what I had to correct, you can do the same if you have another problem that has not appeared to me.
So that it always runs correctly I put export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER at the beginning of the script that runs matlab (_YOUR_MATLAB_FOLDER/bin/matlab), although I suppose it can also be set as an environment variable.
I hope this has been useful to you.
Over past days the option "Run Functional Simulation" (in waveform part) in Altera Quartus 13 here (i use in Ubuntu 11.10) was working fine, but since yesterday It, all of sudden, is not working. When I click in the option, it's opened a tiny grey retangle, and so it disappears. In other words, simulation doesn't work. Does anyone knows how to solve this problem?
Best Regards,
Inácio.
I recommend to start quartus in a console do exactly what you have done before and paste at least everything what is outputs in the console. Otherwise nobody can really help you.
My crystal ball tells me that you could delete or update a library which the simulator needs, or the PATH variable does not include the path of the executable of the simulator.
I have a Simulink model that uses an s_function, which is a mexw32 file. The s_function block uses a .lib module as well. Now, when I'm trying to run the model Matlab crash before the simulation end and without any errors in the command window. What are my options for debugging if Matlab crash?
This is typical behaviour of a badly written S-function that is causing a seg-fault. Debug it using the steps outlined at: http://www.mathworks.com/support/solutions/en/data/1-3KK6RK/
I dont know about Simulink or S-functions (never used them), but usually when a MEX-file segfaults, MATLAB will recover from it most of the times, showing a stack trace and placing you in the "you need to restart MATLAB" command prompt mode. You'll find a crash dump and error log files in the system %TMP% folder.
As other have said, if you have access to the source code of the MEX-function, recompile it with debugging symbols, attach a debugger to MATLAB, place breakpoints in the debugger, and initiate the MEX-function by calling it from MATLAB. Once inside the C code, debug it code step by step until you find the problem.
Here is the relevant doc page describing this process in more details.
You mentioned that your MEX-executable is linked against an external library. So you might also want to check that for the source of the problem.
I'm currently developing a mex-file with CUDA functionality to be used in MATLAB. When I'm doing something wrong (e.g. wrong pointers or something like that), MATLAB always crashes (windows prompts me to end, send the report for mathworks or attempt to continue). Is there a way to prevent this from happening? It's really annoying to develop like that but as you probably know yourself: Hardly anybody can write perfect code without 'trial and error'...
Thanks so far!
As far as I know, there is no way to prevent Matlab from crashing on a mex bug. But you may be able to attach a debugger to the Matlab process and step through the code.
I know for a fact that this works if your code is in an external dll that you load into Matlab. I am not sure if this works with mex files.
From the Matlab MEX file page,
mex -g yourmexfile.c
if you're not doing this already.
You can debug Matlab mexfiles including CUDA codes using Visual Studio and NVIDIA Nsight for Visual Studio by the following procedure.
Define the system environmental variable NSIGHT_CUDA_DEBUGGER and set it to 1.
Launch Matlab.
Launch NVIDIA Nsight. Right click on the Nsight Monitor icon on the taskbar and select Options. Select the CUDA tab. For the option Use this Monitor for CUDA attach, click the drop-down menu and select True.
Open your project in Visual Studio, set the breakpoints and compile it.
Go to Tools -> Attach to Process.
Click the drop-down menu next to the Transport field, and choose Nsight GPU Debugger.
Ensure that your host machine name is listed in the Qualifier field.
Note that this field is blank by default; you will have to manually select your machine name the first time this dialog is opened.
When you enter your computer's hostname in the Qualifier field, a list of available processes will appear in the dialog box. Processes that may be attached with CUDA usage will appear with CUDA listed in the Type column. If a process is grayed out and CUDA is listed in the Type column, it is already being debugged, so it is not attachable. Processes that are grayed out without CUDA in the Type column indicates that it has no CUDA usage in the process to be debugged. Processes that may be attached will appear normally, and the Attach button will be enabled.
Ensure that Matlab has CUDA in the Type column and select it.
From the Matlab command line, invoke the function defined in the CUDA mexfile. The execution will then stop at the first breakpoint and debugging could start.