I have a big problem with SIMULINK. I wrote an interpolation routine using the Embedded Matlab Function block, much like a function-m file. The block works perfectly fine on its own. When I try to run the block in the program with the states being fed into it from the 6DOF block, it stops due to an error and says the abscissae should be distinct and strictly monotonic.
This means for some reason the interpolation routine thinks the index is not increasing. But this is NOT true. I know this works because I've run it by itself with no problems.
After doing some digging I even put some Signal Specification blocks to the signal coming into the Embedded function, but it's still not working. I really need help please! I'm pulling my hair out here!
-Cyrus
My first suspicion is that your routine stores some data related to the abscissae each time the EML is called, but you haven't allowed for the fact that variable step solvers can "go backwards in time" while they "search" for the correct time step to actually take.
i.e. you aren't taking account of Simulink's minor time steps.
Calling the code yourself from outside of Simulink wouldn't account for the above, and hence the code may work when you manually call it from MATLAB.
But without seeing any code that is pure (and possibly incorrect) speculation.
Phil.
I don't understand your comment about the "index". If you call
interp1(x,y,xi), then x must be a vector and diff(x) must be all positive or
all negative numbers. If the input x values are not sorted, you can sort
them before calling the interpolation routine, e.g.
[x,idx] = sort(x);
y = y(idx);
yi = interp1(x,y,xi);
MATLAB's INTERP1 does this for you automatically, but Embedded MATLAB's
INTERP1 does not.
--
Mike
When I connect these blocks to the main global code it crashes and says:
"Function 'mrdivide' is not defined for values of class 'unit8'."
If I run this *Exact* same code by itself, no errors, no problems. What the heck is going on?....
Apparently, one of the blocks in the "main global code" (which I'll refer to
as MAIN) that passes input to the piece of code that runs fine separately
(which I'll call SUBFUN) is passing data of class uint8 into SUBFUN, and
SUBFUN includes a call to MRDIVIDE or its operator form (/). Since MRDIVIDE
is not defined for data of class uint8, you receive this error.
You will need to track down where in MAIN the uint8 data is coming from and
make sure that's what you want it to do, or perhaps cast all the data coming
into SUBFUN to the double class, for which MRDIVIDE is defined.
--
Steve Lord
sl...@mathworks.com