Stats

  • Replies 6
  • Subscribers 158
  • Views 15215
  • Members are here 0
More Content

Zooming problems; getting inconsistent zoom results using axlZoomToDbid

EvanShultz

Hi all,

I am working on my first SKILL program, so please don't bloody me too much if I am doing something silly :) I haven't written much code as I am a hardware engineer, but I'm the only person at a small company who's looked at SKILL so here I am. I have looked at several of the SKILL programs on SourceLink and I was quickly able to get a basic feel for the programs and understand what several of them are doing.

 

I want to zoom in on an object, so I reached for the apparently perfect axlZoomToDbid command using:

axlZoomToDbid(<object> t)

It wants to work as I am zooming in on the objects, but the amount of zooming varies greatly. The description of the command says the object will fill about 20% of the screen. For me, some components fill up the screen entirely and others are very small. But the component is definitely being centered on the screen, so I'm confident the command is working at some level.

 Can anyone else confirm this behavior? Has anyone used zxlZoomToDbid before? Perhaps it is related to another setting, like User Prefs > Ui folder > Zoom folder > buttonfactor which were added to PCB Editor after axlZoomToDbid was introduced? I tried changing the settings I thought might help but I didn't find the right one.

 

In lieu of using that seemingly simple command, I calculated coordinates a bit around the object's extents and saved the 4 points as variables x1, y1, x2, and y2. I thought I could use those coordinates and axlShell to zoom by points. But I wasn't able to pass along the variables using either:

;axlShell("zoom points; pick x1 y1; pick x2 y2") OR ;axlShell("zoom points; pick %f %f; pick %f %f" x1 y1 x2 y2)

It seems like one of the above ought to work, but it doesn't. I know I've got the right coordinate data in the variables because when I run the second line above I see the correct coordinates in the Command Window, but those coordinates aren't getting into the zoom points command.

 

I'd prefer to use axlZoomToDbid if possible, since it's a shiny new (well, since 15.0) command and it takes 4 less lines of code, but if anyone else can get my second option working or has a completely different solution please let me know. Thank you!

  • I've seen the same issue.  I wound up using the axlWindowBoxSet function.

  • The reason axlZoomToDbid seems to not zoom in enough (for components) is that it uses the bounding box of the entire component. This includes dimensioning and text (if they exist) on non-visible layers.

    I suggest you get the dbid of the place bound shape and zoom to that dbid, but highlight the entire component. There is nothing that says the object needs to be visible to zoom to it.

    Hope this helps...

    Nate

  •  Hi Randy,

     Well, I'm glad I'm not the only one seeing it. Of course, that's bad as well.

     

    Hi Nate,

     I could understand if that was true, but I don't think it is. I'm looking at the PSM files and there's nothing in there that is 'sticking out' which would cause my small small passive SMT parts (0805, 1206) to not fill up 20% of the screen.

    And with large through hole parts (box caps, TO220 transistors) the PLACE_BOUND_<subclass> shape fills up the entire screen while component pads and the ref des aren't on the screen. The same thing happens with large SMT parts (2512, SMT electrolytic caps).

    I'm not so sure. The description of axlZoomToDbid says "object(s) extents fill about 20% of the display" but it doesn't say what the function uses as the object's extents.

     

    The same thing happens when no_zoom_to_object is turned off and you use 'show element' to find a part in the Find tab. I get the exact same zooming behavior where the same parts have the same amount of zoom as using the axlZoomToDbid function. Hmm, it appears either our company's library parts (and Randy's) aren't happy with whatever this 'auto zoom' is using to determine the element's extents.

    And yet, I don't think it's the library parts either. I opened the cds_routed example board file at C:\Cadence\SPB_16.2\share\pcb\examples\board_design. J1 (THT box header) and C8 (THT box cap) fill up the screen, but C9 (SMT cap) doesn't fill up the screen. In fact, C9 looks like it's about 20% of the screen - it looks correct. And all the ICs (also SMT) are filling up the screen.

     I think there's something wrong with the axlZoomToDbid function or else we're improperly using it.

    A SR has been filed.I'll update everyone with the results. Please reply if you know how to get all parts to fill 20% of the screen using axlZoomToDbid or have another solution. Thanks!

  • I've been working with some of the Cadence AEs on this function. What they're not understanding is that because the function doesn't work 'right', nobody is going to use it. I'm trying to explain even if the documentation explains all the caveats, the function is silly so it doesn't matter. We'll see how that goes.

    I discovered that if you call this function from a different starting point on screen, the zoom level will change. They were able to accept that as a sign that this function needed some work. But I don't feel like I've got my overarching goal of explaining how useless this function currently is.

    Also, I am seeing some components filling the screen right to the edges of the part, and ignoring the ref des (and other text). While other parts are tiny, which might make you think more than just the symbol was being considered when axlZoomToDbid encounters a component. But since sometimes the ref des is being ignored, that can't be true in all cases. Sheesh! This function has no real rhyme or reason that I can find.

    The documentation will also be updated since the behavoir of the function is intentionally different with different types of elements, and the current documentation doesn't reflect this.

    So, I've got 2 CCRs currently in place: one will update the documentation to axlZoomToDbid and the other will change the functionality.

     

    Does anyone else have any other information to present, other than "axlZoomToDbid sucks", which I've heard from several SKILLers?

     

     Randy, I ended up using axlWindowBoxSet as well. Too bad axlZoomToDbid doesn't work the same way to replace several lines of code.

  • Hi EvanShultz,

    Not to beat this thread to death but "axlZoomToDbid" is working as it is documented.

    Please check out the brief description in %CDSROOT%/share/pcb/examples/skill/DOC/FUNCS/axlZoomToDbid.txt

    It states that the "Zoom is done so object(s) extents fill about 20% of the display" and I believe that is what you are seeing.  I think Cadence would treat your request as an enhancement to the functionality and not a bug so it may be an uphill battle.

    Good luck,
    Mike Catrambone

Cadence Guidelines

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.