Hi

I get the same problem when trying to open the FFT subsection of the
library. I have gone back to the first version of the 10.1 library and
it still does it. I may have to redo the port from scratch from the
7.1 version.

The changes to save_state basically save all parameters and their
values into a structure and then save them in UserData.
backpopulate_mask then checks the length of the string to be written
into a text box. If the length is too long, a call to the saved
variable is written into the text box instead of the value to ensure
the text string is not too long.

same_state has been modified to include a call to backpopulate_mask to
ensure any variable names passed as a parameter are converted into the
corresponding value. This prevents a bug where, if a variable name is
passed and the under-lying value is the same as the previous value,
the init script will be called but no changes are made (as expected as
state has not changed). However, if the underlying value is then
changed in the workspace, the init script will not be called as
Simulink does not invoke the script unless a mask value has changed.
The change ensures that mask values are updated even if no under-lying
values have changed so that if under-lying values do then change, the
script will be invoked. Bit of a hack but if Simulink was a bit more
intelligent about invoking init scripts it would not be necessary.
What this does do is introduce a possible bug where backpopulate_mask
attempts to update the mask even if the wrong init script has been
called. Placing a call to check_mask_type before a call to same_state
will prevent this.

Oh, and implemented the check before converting to strings. Is in
tostring.m which has been checked in. flatstrcell.m has been updated
to use this and it seems to work.

Cheers
Andrew

2008/6/12 Terry Filiba <[email protected]>:
> Hi Andrew,
> So far this has been fairly reproducible. When I load the casper_library
> model file it opens the main casper library window and the Downconverter
> sub-library. I double click on FFTs and that is when it begins to seg fault
> (but this doesn't kill matlab, just shows up on the command line). Have you
> tried this/are you having the same issue?
> I'm not clear what your changes to save state and same state are for. Right
> now I am trying to allow for very large ffts which creates very large arrays
> that don't fit in the text box which I think is a different issue.
> Thanks,
> Terry
>
> On Jun 10, 2008, at 12:39 AM, Andrew Martens wrote:
>
>> Hi
>>
>> I have not had matlab seg faulting (touch wood) in my porting efforts so
>> far.
>>
>> I will check in the changes to support large parameters (changes to
>> save_state.m, same_state.m).
>>
>> I will implement the string checker function and check it in today.
>>
>> Cheers
>> Andrew
>>
>> 2008/6/10 Terry Filiba <[email protected]>:
>>>
>>> Yeah, this is a 10.1 problem. I'll continue looking into the problem with
>>> the fft tomorrow. I can also take care of the change to support large
>>> ffts
>>> and pfbs since that is needed for the seti spectrometer.
>>> Let me know when you update that function so I can grab it.
>>> Thanks,
>>> Terry
>>>
>>> On Jun 10, 2008, at 12:17 AM, Andrew Martens wrote:
>>>
>>>> Hi
>>>>
>>>> Is the FFT issue with 10.1? I have not got around to porting the FFT
>>>> blocks to 10.1 yet.
>>>>
>>>> I can make a function that checks something is a string before
>>>> conversion and make it part of the standard to use the function.
>>>>
>>>> Cheers
>>>> Andrew
>>>>
>>>> 2008/6/9 Terry Filiba <[email protected]>:
>>>>>
>>>>> Hi guys,
>>>>> I have been working with the fft for setispec but I'm having issues
>>>>> with
>>>>> matlab seg faulting. Has anyone encountered this/is working on fixing
>>>>> this?
>>>>> If not I'll continue working on that and get it resolved.
>>>>> Also, I was talking to Henry about the mat2str issue when you run it on
>>>>> a
>>>>> string (the string gets another set of quotes). Although checking if
>>>>> the
>>>>> data is a string every time may make things slow I think it is a
>>>>> necessary
>>>>> change. Does anyone have an alternative solution for this issue?
>>>>> Thanks,
>>>>> Terry
>>>>>
>>>
>>>
>
>

Reply via email to