Solved

ZPL Solve behaves differently than Fixed for the same cell value

  • 7 February 2024
  • 5 replies
  • 78 views
David.Nguyen
Rank
Userlevel 7
Badge +2

Hi everyone,

 

I was trying to solve the following problem, and stumbled across an odd behaviour of a ZPL Solve.

Imagine a collimated beam incident upon a Fold Mirror. The Reflect Angle is arbitrary. I want the next surface to retain its orientation irrespective of the Fold Mirror orientation. For example, if the Reflect Angle is -80 deg, and I want the next surface to have an overall tilt about X of -90 deg, I would add a Coordinate Break after the Fold Mirror and put a value of -10 deg in the Tilt About X column. This works. Now to deal with arbitrary angles, my idea was to have a ZPL Solve that would take the Tilt About X of the second Coordinate Break of the Fold Mirror, double it, add 90 deg, and change its sign. This works in the sense that the value returned for the -80 deg Fold Mirror is indeed -10 deg, but the 3D Layout looks very different and I can’t wrap my head around it.

This is the ZPL Solve:

fold_return = SOSO(0) - 1
fold_tilt = -2 * parm(3, fold_return) - 90
SOLVERETURN fold_tilt

These are screenshots of the situation and I’ll attach my file at the bottom of this post:

I’ve highlited the IMAGE Surface in orange and shown two configurations of the Tilt About X of Surface 5 (with a Y Offset for visualization). In the Multi-Configuration Editor, the value is exactly the same, but in the 3D Layout, Configuration 1 (Blue rays) has the large horizontal surface at the bottom, which is what I expect and Configuration 2 (Green rays) has the small angled surface on the right-hand side.

Thanks for your help and take care,

 

David

icon

Best answer by MichaelH 8 February 2024, 03:26

View original
1 Attachment

5 replies

MichaelH
Rank
Userlevel 6
Badge +2

Hey David,

Using the SOSO command with MIRROR surfaces will not work (or any other command that uses a relative reference in the LDE).  Although it’s hidden in the LDE, the underlying code for drawing the mirror’s substrate is to actually insert a true “dummy” surface and let the layout engine draw the substrate.  This is a known issue and I doubt it will be “fixed”.

I believe if you change the Mirror Substrate to None, this might allow the SOSO command to work with a mirror, but I can’t remember for sure.  

~Michael
David.Nguyen
Rank
Userlevel 7
Badge +2

Hey @MichaelH,

 

Thanks for the information. Just to be sure I understand this correctly, SOSO seems to return the correct surface number, but you are saying that there is then an issue after the solve when the layout engine is used, is that right? I will try with a mirror coating as you suggest and keep this post updated.

Thanks again for your help and take care,

 

David 

MichaelH
Rank
Userlevel 6
Badge +2

Hey David,

SOSO itself returns the correct surface number for the calling row, but when you use SOSO(0) - 1, the minus 1 is what is causing the error.  I don’t know where the logic is for the back of the MIRROR substrate, but combining SOSO with a relative offset will typically give errors with a reflective system. 

The 2 options I would try:

  1. Change the mirror’s Substrate Thickness to None
  2. Use SRCN combined with a comment to identify the CB.  I would make both the CB & the surface with the solve have the same unique comment.  Then you can use SOSO(0) + SPRO/$BUFFER() to get the comment of the solve surface and then SRCN with a value of 1 to find the CB surface.  This way, you are directly identifying the surface and not relying on relative offsets of -1.
~Michael
David.Nguyen
Rank
Userlevel 7
Badge +2

@MichaelH 

 

Thanks for the clarification. I’ve tried your two options and this is the outcome:

  1. Changing the Mirror Substrate to None fixes the issue (anything else is a problem)
  2. Working like a charm, for anyone interested, I’ve put my macro solve below
solve_surface = SOSO(0)

dummy = SPRO(solve_surface, 1)
identifier$ = $BUFFER()

fold_surface = SRCN(identifier$, 1)

fold_tilt_x = PARM(3, fold_surface)

fold_offset = SIGN(fold_tilt_x) * ( 90 - 2 * ABSO(fold_tilt_x) )

SOLVERETURN fold_offset

The only thing left is perhaps if we could have SOSO for the actual column where the solve has been called so I could replace my hard-coded 3 for Tilt About X.

This is brillant, thank you so much Michael, you are gold!

Take care,

 

David

MichaelH
Rank
Userlevel 6
Badge +2

Hey David,

I’ve been pushing for a SOCO-like function to return the column in the LDE, NCE, & MCE for years now, but it’s not implemented yet.  For editors with a dynamic number of columns, having a function which returns the column number would be amazing for ZPL solves.

Zemax has added a lot of cool features with their last 2 releases so maybe this will make it in a future release in the near future.

~Michael

Reply


Community Posting GuidelinesCookie settings


Zemax Community

Need more help?

To Chinese users:

Do not provide any information or data that is restricted by applicable law, including by the People’s Republic of China’s Cybersecurity and Data Security Laws ( e.g., Important Data, National Core Data, etc.).


不要提供任何受适用法律，包括中华人民共和国的网络安全和数据安全法限制的信息或数据（如重要数据、国家核心数据等）。



Privacy policy   License Agreements    Terms of use    Cookie Policy   Zemax Account Licensing Policies