Might also be worth saying that you can also pass arguments to the underlying search function, for example, to update all software registers (which is particularly useful of late):
update_casper_blocks(bdroot, 'Tag', 'sw_reg') Awesome! On 3 February 2014 19:22, David MacMahon <dav...@astro.berkeley.edu> wrote: > > On Feb 3, 2014, at 12:14 AM, Jason Manley wrote: > >> If you've updated from SKA-SA, you'll need to delete any existing X-engines >> in your design and drag a new block in from the library and set your >> parameters again. > > This kind of deleting and re-drawing is why the "update_casper_blocks" > function was created. To update all the CASPER blocks in the current block > diagram, run this command at the matlab command prompt: > > update_casper_blocks(bdroot) > > If you want to update just a single CASPER block, you can select that block > and run this command at the matlab prompt: > > update_casper_block(gcb) > > Note that the first command is plural (ends with 's') and the second command > is singular (does not end with 's'). The "bdroot" and "gcb" arguments are > actually simulink commands that return the root of the current block diagram > (bdroot == block diagram root) and the current block (gcb == get current > block), respectively. > > These auto-update commands generally work, but I have seen some strange cases > where they fail. Sometimes this is due to incompatible defaults for new > parameters of the new blocks, but other times it is due to unexpected > simulink behavior that I don't understand. In any case, it's worth a try as > the first pass. > > One thing to be aware of is that sometimes (though rarely) a block's default > latency might have changed so one needs to be sure to re-test their designs > after updating. This is true regardless of whether one updates the blocks > manually or with one of the above functions. > > Hope this helps, > Dave > >
