I am eager for winter to release its icy grip on New England. Fortunately, change is in the air and spring is around the corner. At work, the big change is the new release of MATLAB. After installation I immediately notice the slight differences in the UI.
The new release of MATLAB and Simulink products went live for download at the beginning of this month. You can read about some of the changes to R2008a in the release notes. Here are some of my favorites:
- Simulink has a new library browser available on all supported platforms! The graphics are smoother, and the search capabilities have been enhanced. Take a look:
- The bus editor has been re-designed. The tree displayed in the left pane now shows the full bus hierarchy under each bus, instead of just the immediate child elements. I have been frustrated in the past when I forgot to save the changes to my bus objects back into a MAT-file for future sessions. The new editor now has load and save capabilities built in.
- In R2008a model reference rebuilds have become more efficient. Parent models will only rebuild if they need to because of an interface change in their child models.
- The limit on the number of Accelerator mode reference models in a model hierarchy has been lifted on Windows.
- Bidirectional traceability has been added to Stateflow Charts and Embedded MATLAB functions. This used to only be available for Simulink blocks.
- More simulation data can be logged on 64-Bit platforms. The limit is now up to 2^48-1 bytes (one byte shy of 256 TB!) in each field of the logging Structure, Timeseries or each Array variable! The limit on earlier releases is about 2 GB per variable.
- New autosave options are available for Simulink models to help guard against loss of work.
- Level-2 M-file S-functions are now easier to write with the new basic template: msfuntmpl_basic.m.
- There is a new zero crossing algorithm for use with the variable step solvers. The adaptive zero crossing mode better handles systems which exhibit chatter.
- The Desktop Team should get some credit for enhancing the MATLAB editor to provide TLC syntax highlighting.
- The Real-Time Workshop Embedded Coder has new AUTOSAR compliant code generation capability, and there are even some demos to go along with it.
- R2008a has improved MISRA-C compliance for matrix math utilities and lookup block utilities.
Over the next few months, as the spring flowers bloom (for those of us in the northern latitudes), I will highlight many of these new features.
These are some of my favorite enhancements to Simulink products. Have you activated your new copy of R2008a? What do you see in the release notes that you want to try out?
6 CommentsOldest to Newest
Looking forward to your upcoming posts. Are you going to highlight the new zero crossing algorithm? I think a discussion about Simulink solvers and/or zero crossing would be GREAT for all users, new and old.
@Joe – I will most definitely be talking about zero crossing detection in general and look at the capabilities of the new adaptive settings. If you have 8a and don’t want to wait, open the Simulink demos:
>> demo simulink
Then, open the second demo called “Double Bouncing Ball: Use of Adaptive Zero Crossing Location”.
Thanks for starting a Blog on Simulink. Much needed! I have a question on signal buffering and processing in Simulink without a DSP toolbox or Blockset.
Lets say you have a sinusoid for example, of varying amplitudes in every period. Lets look at the first 4 periods of this signal. The positive side max amplitudes are 5, 4, 6, and 3 respectively and the negative sides are
-4,-5,-3 and -5 respectively.
What I want to learn is to buffer the 4 periods as they arrive in based off hit crossings. These crossing thresholds are 10% of the amplitudes in the period of interest. For example the first cycle has 5(max) and (-4)min. So we want to generate the rising edge of a square wave when we cross 0.5(towards the +ve direction or upward)and generate the falling edge when we cross -0.4(towards the +ve direction or upward).
This square wave is then buffered, post processed and the buffer reset for the second period. The process continues until all 4 cycles are processed.
Thanks for your time.
Two comments before I point you in the rigt direction:
1. Your logic seems to be anti-causal. i.e. How would you know at the stating of a period what the amplitude of the sinusoid is going to be? This will decide your threshold for that time period. If you are collecting this information offline in some other fashion then you’re all set.
2. Just a caution from a signal processing perspective. You said you have a sinusoid with varying amplitudes in each period. This can happen if the gain of your amplifier is drifting. But just as a word of caution, if this indeed happens, you no longer have *one* sinusoid. You can confirm this by taking the fourier transform of you signal. But since you are procesing only one period at a time, you are approximating a sinusoid and therefore okay in short time spans. Just be careful about doing any spectral processing of this signal (you will notice some high frequency components that you do not expect).
Now to you question about buferring. Given that you “know” what the threshold for this period is , you can use for example the “Compare to constant” block in the “Logic and Bit operations” library (under Simulink) to enable/trigger either an “Enabled Subsytem” or a “Trigerred Subsystem” to do you buffering. These blocks may be found under the “Ports and Subsystems” library (under Simulink). You may either use a “Memory” block (Simulink) or the “Buffer” block (Signal Processing blockset)to do the actual bufferring. Check the documentation for more information on “Enabled Subsystems” and “Trigerred Subsystems”. Pay special attention to the options that allow you to keep/reset the outputs and states when these subsytems are not active.These options can greatly affect how your subsystems will behave.
@Vijay – thank you for answering Yaw. It’s good to see other MathWorkers on MATLAB Central.
@Yaw – I think Vijay gave some good suggestions. The Buffer block can be tricky to use when combined with a conditional subsystem. I don’t think the memory block is going to meet your needs because it will only capture one sample and hold it for a single step.
In my application i need to send output to CANOE from simulink model on need basis only.
i send the output to the external application when i have data. Otherwise i should not send anything.
I have implemented the logic using stateflow inside a simulink subsystem and using CANOE MATLAB interface simulink library blocks.
The issue is that when i dont want to send data the output transmitted out is “Zero”. Which seems correct by all sense.
But as per my specific requirement, i should not transmit anything , not even “Zero”.
If i transmitt “Zero” the CAN bus will wake up to transmitt “Zero”. This is undesiable as we cannot simulate “Sleep mode” since it is always awake.
I would like to know we can do something in the MATLAB end to stop sending “Zero” i.e transmitt nothing when no data is present.
This seems to happen without the interface blocks. ie by default MATLAB sends “zero” when no data is transmitted. This i could see in the scope.
But i dont want “Zero” also to be transmitted out. Is there a way to disable output from the simulink output ports forcibly and then re enabling them back when needed using a .m script?
Please let me know if any clarification is required regarding the issue.
Kindly let me know at the earliest.