<DIV>I am using External JLink Application to manipulate the models
and<BR>generate the drawing automatically. As the size of the model
varies<BR>from 16 to 60 inches, the views sometime go out the drawing sheet.
Is<BR>there any way to fix this, such that the view will always fit into
the<BR>sheet, whatever may be the size.</DIV>
<DIV><FONT face=Garamond>See what the option default_draw_scale is set to. If
you had this set to 1 (which equals 100 percent), views that were set to No
Scale in Properties whould always show at real model size and wouldn't
automatically scale on the drawing. To disable an absolute scale and allow
proportional scaling, set this option to NO. This doesn't have anything
particularly to do with jlink but checking this option setting would still be my
first troubleshooting step.</FONT><BR>-- <BR>David Janes</DIV></BODY></HTML>
I think I have not commnicated properly. Sorry for that!
The drawings views are made to scale. I have completely automated the
model generation using JLink. I have kept a particular scale for each
view. This scale is OK for mid range. If the size goes too low or too
high, then they look odd in the sheet.
Eventhough I am opening the drawing manually and setting the right
scale, I would like the appriate scale to be calculated and used for
Thanks for the help!!
You can use DRAWING_SCALE_FACTOR as a paretmer in the model that the
drawing will automatically pick up on. That is a TON easier then
trying to do it via J-Link. Assuming you are completely generating a
model from scratch with J-Link (which I doubt) if you could append the
relations via J-Link to include your calculated value, or relations
based on other model dimensions/parameters or what ever.
That parameter sets the global drawing scale for the model. View
dependent scales (e.g. if you want to show a cross section for a very
long part with a small cross section) are more complex - usually best
if already set in the drawing before you automate anything.
<DIV>You can use DRAWING_SCALE_FACTOR as a paretmer in the model that
the<BR>drawing will automatically pick up on. That is a TON easier
then<BR>trying to do it via J-Link. Assuming you are completely
generating a<BR>model from scratch with J-Link (which I doubt) if you could
append the<BR>relations via J-Link to include your calculated value, or
relations<BR>based on other model dimensions/parameters or what ever.</DIV>
<DIV><FONT face=Garamond>I'm not sure what you're thinking of here, Dave, with
drawing_scale_factor. It's not a config option, not even a hidden one, at least
not according to Olaf Corten and proesite.com. Maybe a plain old parameter?
Holding some value that you'd use how? Or maybe you're thinking of the one I
mentioned in my earlier post, default_draw_scale which, when set to NO, does the
proportional scaling we see in most detail drawings.</FONT></DIV>
<DIV><FONT face=Garamond></FONT> </DIV><DIV><FONT face=Garamond>But, you're right, there're probably easier ways to do
this with the internal parameters, maybe some relations, etc. Still, most
automated ways are at least a takeoff on manual ways, repeating their mechanics
quickly or developing an algorythm that captures the essence of what's going on.
Since this whole thing of scaling really boils down to numbers, it could be an
iteresting mathematical puzzle: dimensions of hte part in a top and front view
vs the space available on a drawing format. You'd have to make some allowances
for borders around views, space for dimensions and other annotations, say 20%,
but that still comes out to be some ratio or "scaling factor". It might even
provide the information needed to decide the optimum format/paper size to
<DIV><FONT face=Garamond></FONT> </DIV><DIV><FONT face=Garamond>Anyway, the chief thing missing (can you get this with
jlink, Prabhu?) is the model size. <BR>There's some teaser functionality in
Pro/e called 'Info>Model Size' which gets you some virtually useless
'diagonal' because, for any length diagonal, there are a nearly infinte number
of boxes that can have that diagonal. But, what you need, to determine the
needed space, at a certain scale and a certain view, is HxWxL numbers. If you
can write a jlink app to capture this information, you'll have x, y, z numbers
to evaluate for the drawing space available for any given format and drawing
<DIV>-- <BR>David Janes</DIV></BODY></HTML>
There is a method GetOutline() in View2D interface of pfcView2D class.
This will give Lower left and Upper right co-ords. With this, I am
thinking of adding some calculations to finalise the view scale. Will
try and let you know.
In the meanwhile, if you have some better methods please let me know.
This suggestion came from the "David Bigelow" web site, not Olaf's :)
:) (just kidding Olaf)
DRAWING_SCALE_FACTOR is parameter that is automatically picked up by
the drawing IF you set it in the model. (assuming you are not manually
overriding or setting it via config.pro or something else wierd). This
is standard functionality within Pro/E, has been for some time
(probably back before rev 18).
Just put it in the model's relations with either the value you want to
use for a scale; or even better, compute the scale to fit a target view
box on the drawing using model dimensions/parameters as the
proportional references - and you are good to go!
Again - this is a TON easier than trying to use J-LINK to try and get
anything close to it for this level of detail / automation.
Again, the ONLY draw back is scales for detail views / cross sections,
etc.. You can still compute those in the pro/e model relations, but
you have to set those manually in the drawing for the view when you
click on it's scale to modify it (e.g. the parameter name instead of a
value in those specific cases).
Hope that makes sense.
Well, all kidding aside, I put DRAWING_SCALE_FACTOR as a parameter into a part (and one which already had a drawing made of it at a scale of 1:1). I assigned a value of .5 to this parameter. When I went to the drawing again, it had scaled all the views to one-half and showed .5 on format scale label, also on &scale drawign note. So, it definitely works.
Naturally, for this to work, it means that you've got to keep drawing scale in mind while modelling and do the math ahead of time based on how your named views will display, kind of get it all planned out ahead of time so you can figure the all important drawing_scale_factor, instead of letting the program do it for you with some kind of autoproportional scaling. Naturally, when using the parameter for drawing scaling, all bets are off when one changes drawing size. The factor will automatically be too big or small. Then what, redo the parameter or adjust the scale onscreen? This business of 'automating' drawing creation is perilous, no matter what way is tried. Given the complexity of producing good drawings, it's likely too complicated to lend itself to the regularity/predictability of automation.
suggestion came from the "David Bigelow" web site, not Olaf's :)<BR>:)
(just kidding Olaf)<BR><BR>DRAWING_SCALE_FACTOR is parameter that is
automatically picked up by<BR>the drawing IF you set it in the model.
(assuming you are not manually<BR>overriding or setting it via config.pro or
something else wierd). This<BR>is standard functionality within Pro/E,
has been for some time<BR>(probably back before rev 18).<BR><BR>Just put it in
the model's relations with either the value you want to<BR>use for a scale; or
even better, compute the scale to fit a target view<BR>box on the drawing
using model dimensions/parameters as the<BR>proportional references - and you
are good to go!<BR><BR>Again - this is a TON easier than trying to use J-LINK
to try and get<BR>anything close to it for this level of detail /
automation.<BR><BR>Again, the ONLY draw back is scales for detail views /
cross sections,<BR>etc.. You can still compute those in the pro/e model
relations, but<BR>you have to set those manually in the drawing for the view
when you<BR>click on it's scale to modify it (e.g. the parameter name instead
of a<BR>value in those specific cases).<BR><BR>Hope that makes
Thanks for the suggestions.
I also agree that drawing production is much more complex than
automating the model generation. But in this case, the sheet size is
not going to vary for a particular component. If the component is made
in A2, it will always be made in A2, irrespective of its size. That's
why we need scaling. Also we are calculating a lot of parameters for
model generation. So one more parameter would not be an issue, I hope
We are still working on the drawing automation part. Will keep you all
posted once it is through.
Thanks once again...
I think you are thinking through this way too much. This is *easy* to
do if you look at it from the perspective of the amount of space you
want a view to occupy on the drawing - the relation is always going to
be the same in that case. Viewport Size in relation to model width,
height or what ever you choose. Even if you change drawing formats,
your ratios are simply driven by the view space you want to occupy - so
this is still not a big deal to modify/adapt to in these circumstances.
The only thing that will make your head spin is the size of the view
over the smallest and largest conditions of the design. So you may
have a couple of relations for the drawing size in the model to address
this; not a big deal, and easy to modify/update before the automation
is made available for others to use.
I disagree with this statement. I think it comes down to this: Are
you willing to present information in a format that is easy to automate
within the capabilities of the software, or are you going to turn your
head inside out trying to make you automated drawing look like the
drawings your company has generated for the past 30+ years?
If you can agree to reduce the amount of information to the essentials,
present it in a form that is easy to automate, then you are very (very)
likely to suceed with design and drawing automation.
However, if you persist in applying your artistic impressions into
creating drawings (because your name is on it) - or are afraid to
present infomation differently (more optimum) to your suppliers, this
process will be extremely painful and will become the justification for
*not* doing automation at any level within the company.
But that subject starts an entirely new thread... :)
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.