Two step trimming in Maestro Assembler. Difficulty encountered trying to calculate the trimming code in the second trimming step.

Dear IceTea,

IceTea said:

In the end it all worked out, and the two step trim procedure worked as expected, but I really don't understand why the initial attempt in the second trim step with "round(cross(VS("/ibt_2u_npn<0>") 1.0 1 "rising" nil nil nil))" didn't work.

Is there any chance your second cross() function is returning an integer value and not a floating point value? The round() function is expecting a floating point value. As an experiment, have you tried changing your expression from:

round(cross(VS("/ibt_2u_npn<0>") 1.0 1 "rising" nil nil nil))

to:

round(cross(VS("/ibt_2u_npn<0>") 1.0 1 "rising" nil nil nil)/1.0)

Shawn

Hi Shawn,

I haven't tried this, but if that would have been the case, the splitting would have provided the same error, right? If cross() returned an integer number, round() should have complained about this. Anyway, thanks for taking a stab at this,

IceTea

Dear IceTea,

IceTea said:

but if that would have been the case, the splitting would have provided the same error, right? If cross() returned an integer number, round() should have complained about this.

I don't think your statement is quite true from what little I know of your process....this is why...

I'm not familiar with how you did the assignment to the new variable trim_ib_val or if you initialized this variable. If you initialized the variable as an integer, it clearly will be an integer. If you initialized it as a floating point, it will be expecting a floating point value. There may be other steps in your code that may impact its assignment - but I can't tell as you did not provide any more information...

The motivation for the comment is that adding the "/1.0" will force the cross function output to be a floating point number and hence the argument of round() will definitely be a floating point number. This will eliminate the possibility the error is due to an inappropriate argument to round() - that was my thought.

Shawn

The issue is that the round() function doesn't support waveform objects - see How to apply round() or any other unary function to a waveform as a workaround. CCR 1360232 is asking for this to be handled natively, but it isn't yet.

So you can use the code in the the linked article, and then you should be able to use:

abApplyToWave('round cross(VS("/ibt_2u_npn<0>") 1.0 1 "rising" nil nil nil))

The problem is that in certain situations the cross results will be a waveform, and any function that is called on that also needs to handle waveforms.

Andrew

Thank you Andrew. 

Let me tell you how this unfolded since yesterday. I tried round(1) in the calculator and it didn't complain about 1 being an integer..., but I said let me do the divide by 1.0 just to make sure. While I was in the middle of making the changes, the system crashed such that I lost pretty much all the current state, so I was forced to start from the beginning, and yes the .snapshot didn't help recovering a previous version.

So I started again and this time I used the calculator each time I defined the round(cross(...)) expression in each of the trimming steps. I'm saying this because when loading the waveform in the calculator I get this on the calculator:

leafValue( v("/ibt_2u_npn<0>" ?result "dc") "Design_Point" 1 )  

which is slightly different than what I was used to (which was without leafValue and "Design Point")... I have to say that after applying the cross() and round() functions (and testing it to see it gives the right result, and it did!) I sent the buffer expression to ADE outputs using the calculator button. In the expression field in the maestro Output Setup tab leafValue and "Design Point" were stripped out and there even was a message popping up informing about the stripping process. In the interest of full disclosure, I have to say that in the lost example, in the second trimming step I wrote the expression by hand in the expression field of the Output Setup and I suspect this may have created an issue in the maestro "Output Setup".

So, I used the above method and I also used the function that Andrew sent (thank you Andrew, nice skill function, I also learned from the help text how to add the function to the calculator!!!). 

Both methods gave the correct trimming result this time. The somehow bewildering point is that from my vintage point I don't know exactly what went wrong the first time. The real good news is that now everything works using two methods which is not bad. I'll use Andrew's because I have the feeling it covers more cases. Thank you all,

IceTea