I have two textboxes and a button in matlab. Designed the form using GUIDE. I used the following code to copy value from one textbox to another. The code works sometimes and not always. I am not able to find the scenario in which it works and what was wrong with this code.
function pushbutton1_ButtonDownFcn(hObject, eventdata, handles)
myTextBox1 = findobj('Tag','edit1');
myTextBox2 = findobj('Tag','edit2');
str = get(myTextBox1,'String');
set(myTextBox2,'String',str);
Given the comments it is safe to say that nothing is wrong with this piece of code.
This is not yet a solution, but it seems clear that you are searching in the wrong place.
Two things that you want to check:
The state your program is in at the time the function is called, maybe there is something strange going on with the relevant variables.
Whether there is a problem with the availability of files that you use as input, if you use a file right after it is updated this may be a cause of problems.
It worked when i gave the code in pushbutton1_Callback(...) function. Thanks.
Related
I have MATLAB Simulink model running successfully. In this model, a function runs code to do the operation. The function code generates a value during the operation. I want to save this value and use at successive operations.
In above screen shot, Icur_in and Icur_ou are input and output of the function. In fact both refer to same value. I am using memory function to hold the value for next operation. Up to this point is fine. But the value keeps on changing.
My present code is:
Function [Icur_ou] = fun(Icur_in)
Icur_ou = Icur_in;
if somecondition
Icur_ou = I_s;
end
end
I am not 100% sure about what your problem is, since you state: "Up to this point is fine." And also your model looks fine to me, but nevertheless I found this link, which seems to be about the same problem. Besides the suggested solutions, I also liked the first two comments about persistent variables, which I think could maybe also help you depending on the sample time of your model (see comments in the link).
In this case, you would not need the memory block, but instead you'd have to make your Icur_ variable persistent, so that it stays in memory between function calls. Similar to this:
Function [Icur_ou] = fun(Icur_in)
persistent Icur_ou = Icur_in;
if somecondition
Icur_ou = I_s;
end
end
I'm working on a project based on the stm32f4discovery board using IAR Embedded Workbench (though I'm very close to the 32kb limit on the free version so I'll have to find something else soon). This is a learning project for me and so far I've been able to solve most of my issues with a few google searches and a lot of trial and error. But this is the first time I've encountered a run-time error that doesn't appear to be caused by a problem with my logic and I'm pretty stuck. Any general debugging strategy advice is welcome.
So here's what happens. I have an interrupt on a button; each time the button is pressed, the callback function runs my void cal_acc(uint16_t* data) function defined in stm32f4xx_it.c. This function gathers some data, and on the 6th press, it calls my void gn(float32_t* data, float32_t* beta) function. Eventually, two functions are called, gn_resids and gn_jacobian. The functions are very similar in structure. Both take in 3 pointers to 3 arrays of floats and then modify the values of the first array based on the second two. Unfortunately, when the second function gn_jacobian exits, I get the HardFault.
Please look at the link (code structure) for a picture showing how the program runs up to the fault.
Thank you very much! I appreciate any advice or guidance you can give me,
-Ben
Extra info that might be helpful below:
Running in debug mode, I can step into the function and run through all the lines click by click and it's OK. But as soon as I run the last line and it should exit and move on to the next line in the function where it was called, it crashes. I have also tried rearranging the order of the calls around this function and it is always this one that crashes.
I had been getting a similar crash on the first function gn_resids when one of the input pointers pointed to an array that was not defined as "static". But now all the arrays are static and I'm quite confused - especially since I can't tell what is different between the gn_resids function that works and the gn_jacobian function that does not work.
acc1beta is declared as a float array at the beginning of main.c and then also as extern float32_t acc1beta[6] at the top of stm32f4xx_it.c. I want it as a global variable; there is probably a better way to do this, but it's been working so far with many other variables defined in the same way.
Here's a screenshot of what I see when it crashes during debug (after I pause the session) IAR view at crash
EDIT: I changed the code of gn_step to look like this for a test so that it just runs gn_resids twice and it crashes as soon as it gets to the second call - I can't even step into it. gn_jacobian is not the problem.
void gn_step(float32_t* data, float32_t* beta) {
static float32_t resids[120];
gn_resids(resids, data, beta);
arm_matrix_instance_f32 R;
arm_mat_init_f32(&R, 120, 1, resids);
// static float32_t J_f32[720];
// gn_jacobian(J_f32, data, beta);
static float32_t J_f32[120];
gn_resids(J_f32, data, beta);
arm_matrix_instance_f32 J;
arm_mat_init_f32(&J, 120, 1, J_f32);
Hardfaults on Cortex M devices can be generated by various error conditions, for example:
Access of data outside valid memory
Invalid instructions
Division by zero
It is possible to gather information about the source of the hardfault by looking into some processor registers. IAR provides a debugger macro that helps to automate that process. It can be found in the IAR installation directory arm\config\debugger\ARM\vector_catch.mac. Please refer to this IAR Technical Note on Debugging Hardfaults for details on using this macro.
Depending on the type of the hardfault that occurs in your program you should try to narrow down the root cause within the debugger.
I have a problem that I'm having a hard time even framing for this question's title.
I have a library that calculates the properties of refrigerants. For example, you give pressure and enthalpy, and it tells you the temperature. That library is coded in Fortran with a mex file to interface with Matlab. Now, I am 100% sure that library is thoroughly debugged (it was coded by people much smarter than me, and has been used for almost a decade). The problem is definitely in how I call it.
And that problem is this. I call the library from a StartFcn callback (a .m script file) in a subsystem of a simulink model. The first time I run this model, it runs perfectly. The values I'm sedning to the function are therefore correct. The second time I run it, however, it crashes. The inputs both times are exactly the same.
Also, if I do a clear all between the two runs, then there is no crash. But if I do only clearvars or clear, I still get a crash. When I debug and look at the variables being passed in the function call, they are valid and the same both times.
Does someone have any experience with this, or can advise me on what I might be doing wrong? Is there something persisting within the function call that only clear all can remove and not clear? Save My Soul!
Yes, persistent variables can be declared by the persistent keyword.
If you want to clear only those, try
clear StartFcn
to clear all variables of the function StartFcn. A quote from the documentation:
If name is a function name, then clear name reinitializes any persistent variables in the function.
A quick thing to try would be clear mex inbetween simulations - this should clear all the mex code from matlab.
Other questions to think about..
Can you call the fortran interface directly from the matlab command line two times in a row?
I believe that using a m-file sfunction to call fortran in simulink is quite inefficient. Possibly consider writing your own fortran or C sfunction to interface to the code and compile in directly?
in case you're using LoadLibrary to load fortran code compiled into a dll, are you calling FreeLibrary in the mdlTerminate function?
Hope some of this helps.
I would try to put a clear all inside the function that you are calling in the StartFcn Callback.
So let's say your function is:
function [out] = nameoffunction(a,b,c)
%do calculation with a,b,c
d = a + b + c;
%output out
out = d;
assignin('base','out',d)
clear all
And you can call the function:
nameoffunction(a,b,c)
Let me know if it changes something. If this works, you could try other clear command but inside the function.
How can I extract the plotedit state of a Matlab figure inside a function? If I want to know the zoom state of the current figure, I can write:
zoomState = get(zoom(gcf), 'Enable');
A similar syntax for plotedit does not work, since plotedit(gcf) toggles the plotedit state without returning anything. Without having a way to get plotedit's current state, I have no clue how to temporarily put it to 'off' and restore its value once my function has finished. Any ideas?
I just received an answer from the MathWorks on this issue:
here is an undocumented feature that you might want to use :
ison = plotedit(gcf,'isactive')
This will tell you if PLOTEDIT is active or not. However, since this
is undocumented it might change or not work in future releases.
I think that this answers my question.
If you type open plotedit at the command line, you will see that it is actually an m-file. When the state is toggled, it calls the undocumented function activateuimode to do the dirty work. Taking a wild guess, I typed help getuimode at the command line and got back the message
This function is undocumented and will change in a future release
So the function exists. Presumably, calling it with the same input arguments as activateuimode in plotedit will do what you want. That is,
getuimode(myFigHandle, 'Standard.EditPlot')
On my system, it returns [] if not in edit mode, and an instance of uitools.uimode if it is.
Note, however, that this approach may be a bit dodgy - as the help says, it will probably change in a future release. If you open getuimode, you will see it has been the same since 2007, but as I understand it there has been a major overhaul of the UI system in R2013, so it may have changed in the most recent release (I'm running R2012a).
All GUI components Callback functions have function might not be used warning.
I know it sound silly for most of programmers to care about such silly warnings when code is running okay, but I wonder why matlab emit such a warning although the function is called when the button is clicked, or whatever component Callback event happens.
Can anyone here explain how to fix this warning? or why this even happens?
Hint: I am using Matlab R2011a , if it differ for one version to another.
The solution is to add this string %#ok<DEFNU> at the end of function definition line to to disable might not be used warning in this line or %#ok<*DEFNU> to disable this warning type in current file.
And it indicates that no warning and this issue is okay in the run time.