Page 1 of 1

square vs pow

PostPosted: Mon Mar 23, 2009 10:00 am
by jyoung
Not sure if thsi is a bug or a error on my part.

I have a model that has two inputs that go through a serios of calculatios and than then feed into a if/else block. As part of the calculatiosn I utilize the Math Function block and set it to "square".

After the translation in complete I get a Artimetic Operator Error when I select build within T-VEC. If I change this block to "pow" (power) and add a constant input of 2 I do not get the error and the model builds without any errors.

Is there a limitation with the use of "square", it seems odd to me that one works and the other does not.

Thanks for the help

Jimmy

Re: square vs pow

PostPosted: Mon Mar 23, 2009 10:17 am
by busser
Hi Jimmy

I was actually expecting this question from you because I noticed this in your model.

The difference between pow and sqrt is that there is no restriction on the input domain of pow, but sqrt is only defined for inputs with positive domains (including 0). That is, we don't support complex numbers, so sqrt(-1) will cause an arithmetic exception error for the low-bound vector case. This error is shown in the Error diagnostics information for the subsystem in question.

vector_gen_error.jpg
vector_gen_error.jpg (181.29 KiB) Viewed 10535 times


The reason this occurs is you have not defined a proper signal range for the input signal in this case. This can be done using the signal range editor that can be accessed via the sl2tvec GUI's tools menu. But it can be used to create user-defined types that specify actual signal domains for your primary signals. The translator then uses these signals and user-defined types to propagate these definitions throughout your model during translation. This way, when you have a signal such as "temperature" you can make sure that the vector generator does not default this signal to having a domain that inlcudes 1.0e-012 ;-) I don't think there are any temperature scales that include that value ;-) Setting proper signal domains is critical to using these tools effectively. You should consult the Users Guide about this tool before trying to apply it.

<soapbox>
One of the advantages of an actually training class is that it provides a much deeper understanding of the overall theory and process. Trying to learn by trial and error is a bit difficult.
</soapbox>

Re: square vs pow

PostPosted: Mon Mar 23, 2009 10:29 am
by jyoung
Bob,

I corrected that issue already (I'm now placing ranges on all inputs for just that reason, because you are right only a real range of values provide any real results) but in this case I'm not using "sqrt" but rather "square". Square is x^2. There shoud not be any limitation on the input because everything is defined. Well maybe there is an upper bound limit to remain with in the type domain, but I set my input range to be 0 to 1.


On your other point. This training class. How long is it, is there a cost, and can it be done remotely? I'm starting to think I might become a better user with a some training.

Re: square vs pow

PostPosted: Mon Mar 23, 2009 10:48 am
by busser
Ooops, sorry. My mistake. The version of your model was experiencing the error I described, so I mistakenly assumed you were referring to sqrt() rather than square.

If you are referring to the "square" block in the subsystem you have named "else_2" I am not experiencing the error you are referring to. Can I suggest that you set up your model and t-vec project files and artifacts to exhibit the error you are asking about and zip it all up and send it to us. This way we can see the information in the exact for you are asking about. This will help us to either explain what you are seeing or will help us identify an bug that may be occurring.

With respect to training class, it is normally done at the customers site for 3-5 days (depending on if the course is going to covera Simulink Tester AND TTM - with VGS or just one of the 2 modeling front-ends with VGS. There is a lot of ground to cover). Yes, there would be a cost involved. For details, I suggest you contact Maureen. (murtha@t-vec.com)

Bob

Re: square vs pow

PostPosted: Mon Mar 23, 2009 10:56 am
by busser
One thing I would like to add about training class costs. Some or all of the cost may be applied directly to the cost of a license(s). We are not trying to make money from beginner training class fees, we simply want customers to be successful and we feel one of the best ways to help this happen is to get them started with a baseline of formal training. There are many new concepts and techniques that take explanation and practice and an understanding of the foundations of the overall approach and technology. It is hard to acquire such information via emails and Users Forum questions/answers ;-)

Re: square vs pow

PostPosted: Mon Mar 23, 2009 4:40 pm
by jyoung
Bob,

I updated my version after I found out that I was using 3.3. That seems to have corrected the issue. Maybe there was an issue using VGS 3.3 with Sim 7.2.

Thanks for the help

Re: square vs pow

PostPosted: Mon Mar 23, 2009 4:45 pm
by busser
That is definitely possible since we were not supporting 2008b Simulink back when VGS 3.3 was release. What version of Simulink Tester are you using ?

Re: square vs pow

PostPosted: Mon Mar 23, 2009 4:50 pm
by jyoung
I'm now using 4.4 (Build 1797)

I was using 4.2 (Build 1451)