MullinRJ
-
Posts
2,017 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by MullinRJ
-
-
This procedure will copy all objects from a specified layer to the active layer. It should be easy to adapt it to copy selected objects from the active layer to any target layer (ie - Procedure PutStuff(Lyr :String)
.HTH,Raymond
Procedure GetStuff(Lyr :String); { Copy all objects from layer = "Lyr" to the active layer. } VAR LName :String; Begin LName := GetLName(ActLayer); { Get active layer name } Layer(Lyr); { Make "Lyr" the active layer } SelectAll; DoMenuTextByName('Copy', 0); Layer(LName); { return to previous active layer "LName" } DoMenuTextByName('Paste In Place', 0); End; { GetStuff }
-
Matthew,Your response has definitely opened the door for some serious Wish List items. Is there any hope of wishing for Dynamic Memory Allocation in VS? User defined data structures (Pascal records) would be a BIG plus. If you answer this question, will you have to shoot me?
On your comment about 4096 pin IC's, no, I have not seen any that big, yet, but it's probably not too far off. I have already done designs for some 1657 & 2092 pin BGA's. The good news regarding those monsters is that most (more than half) of the pins were Power and Ground pins. Still, by the time I finish writing this, the pin count will have gone up again. But to be practical, this would not be the limiting factor to a PIO approach.
Since PIO's cannot affect changes in other PIO's, could I also wish for a new object, a master PIO type that had the ability to force changes to related objects as in a Parent/Sibling relationship? I know this is not the Wish List board, but you did start some wheels turning.
Though keeping a realtime connection list sounds like the ideal way to make a "smart" layout system, it might be a lot faster to parse the existing connections after the editing is done. The downside to having everything done dynamically is that every small change would be accompanied by a ripple down effect when all the regenerations are done. I still think that having "smart" objects would be a useful addition to a well thought out system.
For years now, I have been exporting data to files and then reading the results with other routines, both internal and external to VW, to process the data. If objects can be made to export key attributes from a controlling script, or a script can extract and export the data from the objects, then I see no reason why a system could not be designed with the program as it is. Post processing the objects should be a lot faster than dynamically updating a database as you edit. But who am I to say it can't be done. More power to the motivated.
My gas tank hath runneth empty. Good night.
Raymond
-
It would be really hard to give you a comprehensive dissertation of how I develop a PCB design in a single post, so let's see if I can give you a good 10 cent tour.
I have an advantage with my designs in that the boards are used for IC testing, there is a lot of symmetry inherent in each design. For most designs there is only a single chip in the center of a tester specific piece of hardware. But for some, there are dozens, maybe hundreds, of relays and passive components. I do all the drafting in VW and I control placement with VS. This way I can control registration through all the layers. I have done designs up to 32 layers.
The secret to finishing any job is having the ability to output the work in a usable format. Until this year I had been exporting the data as PostScript, having the data plotted and then shipped to the PCB shop. This year I am exporting Gerber and sending the files directly to the PCB shop. Both forms of output use translators that I wrote to format the data. I have no idea how much of a time investment I have spent developing my tools, as it is a never ending process. I do know that I spent at least 3 solid months working on the Gerber translator. Postscript is a lot easier, as Gerber only has lines and arcs for basic primitives, and Gerber only prints one color at a time.
I usually start by placing the known "obstructions" first. By "obstructions" I mean holes and SMT pads. There will always be objects you save until the end to place, but get the big ones and the required ones down first. Second, mark all your power connections. This will give you a visual aid of pins you don't need signals on. The remaining pins will usually need traces to somewhere. Running traces is a hit or miss process. Sometimes I have to start over two or three times to keep things balanced. Doing it wrong should give you ideas on how to do it better, so don't be afraid to restart.
There are many possible requirements for the traces: equal line length for some or all traces, controlled impedance, predefined wiring or best fit for connectors, to name the most popular requests. Wiring spacing for BGA's is different from that for QFP's and DIP's, and different packages can really affect the layer count.
Lastly, run your power. It doesn't need to be last, but it is the way I do it. After all the traces are run, most, if not all the holes are in their final position. Knowing where the holes are makes it easier to distribute the power grid.
Each design is a puzzle. Each design is different and each has a unique set of constraints that needs to be met. Having a good understanding of VS is a great plus in getting the jobs done easier, faster and accurately. After all these years, I think I have derived more pleasure in designing the tools I use than in finishing the jobs, but it is the latter that pays. I know this is a short answer, but I hope it helps. Have fun deciding which way you want to go.
Best of luck,Raymond
[ 07-18-2002: Message edited by: MullinRJ ]
-
I was hoping someone would respond to your post so I could have the luxury of reading and musing. I feel you deserve a written response, as a silent one is much less satisfying, though it does answer your questions directly. Since no one has yet posted, here are my comments.
<< While this all may be ambitious, does it sounds feasible? >>
Yes, and yes. It is very ambitious, yet also very feasible. I have been designing circuit boards for IC test equipment using VW for more than 12 years. It is an excellent tool for the task. Most of what you outlined I have been able to accomplish, but not all of it in VW.
Many processes I accomplish outside of VW because I have more control of data structures, the computer and the execution speed is much greater. Your item, "4. Netlist export", is just such a beast. I have found that VS does not process large arrays very quickly, though it has sped up dramatically over the years. When the trace count is in the thousands, sorting through all the endpoints can take a good bit of time. If you were to write your routines with the SDK you might regain the speed benefits, but add another layer of complexity to your onion. One important missing item from VS is the linked list. I would not have been able to do many things I have achieved without it. Working entirely with arrays can be daunting.
<<My biggest concern would be how the wire tool can figure out which pins it has touched.>>
Though it is not a trivial exercise to check for connectivity, it is more a brute force task - save all coordinates and start comparing. That may seem like a big concern now, but you will find many larger ones if you proceed.
You will need an extensive library of parts to draw upon for your component tools. Reading one Component Vendor's catalog to find the right part is a non-trivial task, multiply that by the number of vendors out there and reach for your Excedrin bottle. Then, try to organize it for all the redundancy in the industry and you have created a full time job for someone.
In the end, I think the biggest hurdle you will encounter is selling the package. Even if it does all you set out to do, and does it well, most prospective clients, and there are quite a few, are entrenched in AutoCad or other PCB design environments. Just getting their attention will be difficult. Getting them to switch will be much harder.
If you are interested in attempting some of the things you have outlined, you might want to start designing it solely to suit your needs. There is still a lot of merit in having tools that do exactly what you need, and a lot of satisfaction in having built them.
Best wishes,Raymond
-
Joe, I have no way of testing if this works in v9, but give this a try. "SelectAll" the objects that have been reverse stacked and "Send to Front", (Cmd-F) on the Mac. In v8.5.2, this has the unique feature of reversing the stacking order of all the selected objects in addition to moving them to the front, but it's tolerable since pressing it twice restacks them back again. The feature may or may not have made it to v9, but you can write back and let me know. "Send to Back" has the same "hidden feature". If you're lucky, they haven't fixed it yet.
Actually, I hope they leave it alone, it can be a desired side effect at times, and pressing Cmd-F twice doesn't bother me a bit. Though it may not be intuitive, it is useful when you understand how it works. It works in the drawing, in the symbol edit mode, and inside groups.
HTH,Raymond
-
Interesting, when I close VW and start again, the Circle/Oval tool reverts to the SECOND mode button (Circle By Center & Radius). The FIRST mode button is the OVAL mode, which is usually the one I want. Of course I am using VW 8.5.2, so you probably don't care about it any more. We really could use VS support for selecting the Tool mode.
Raymond
-
No, No!!! Don't take it out. Add a little more. It looks like some code came up missing, but enough was there to recreate it. Try this. When you really get motivated, this piece of code would make a nice PIO (Plug In Object).
procedure braces;VAR x, y, x1, y1, x2, y2 :REAL; ymid, xmid, temp :REAL;BEGIN Getrect(x1, y1, x2, y2); {get the box} GetMouse(x, y); {will use this to determine which way the box was drawn} ymid := (y1+y2)/2; xmid := (x1+x2)/2;
{ I played with the code here. XYMID was undefined, that is where the garbling occurred. }{ Change the "<" to ">" in the next 2 if's and the braces will draw the other way. }
if (y < ymid) then begin {box drawn top to bottom} temp := y1; y1 := y2; y2 := temp; end; if (x < xmid) then begin {box drawn right to left} temp := x1; x1 := x2; x2 := temp; end;
if (abs(y2-y1) > abs(x2-x1)) then begin {box drawn taller than wide} beginpoly; moveto(x1, y1); curveto(xmid, y1); curveto(xmid, ymid); lineto(x2, ymid); curveto(xmid, ymid); curveto(xmid, y2); lineto(x1, y2); endpoly; end else begin {box drawn wider than tall} beginpoly; moveto(x1, y1); curveto(x1, ymid); curveto(xmid, ymid); lineto(xmid, y2); curveto(xmid, ymid); curveto(x2, ymid); lineto(x2, y1); endpoly; end; redrawall;END;run(braces);
-
Does the problem you are describing only pertain to symbols you create, or also to VW supplied symbols as well? For symbols you create you will need a 2D AND a 3D part defined for it to show in both environments.
Easy to check. From the Resource Palette, highlight your door symbol (single click). Press the Edit... button (top button on right). If no buttons are showing, click the grow window button in the Title Bar (second button in, on the upper right), and this will expand/contract the Resource window. When you click the Edit... button, you will get a dialog box for three selectable options: 2D Component, 3D Component, and Insertion Options. Both 2D AND 3D areas of the symbol need to be defined, so you will need to draw each and save each part for it to work in both views.
Next, check the Insertion Options of your symbol and pick the Class it will be created under. Be careful, if you have this class's visibility turned off, you will place invisible symbols and get confused a lot. Choose, or create a class that you will normally leave visible when you draw. It is also possible to have the symbol instance in one class and the symbol parts in other classes. All parts will need to be visible to see the entire symbol. Are we having fun yet?
There may be other reasons affecting the display of your symbols. If you are still having problems, write back.
HTH,Raymond
-
Thank you NNA,That was very quick for wish number two. I just downloaded your VW Viewer and noticed the change. That will help a good bit, but granting the first wish will help a lot.
Thanks again,Raymond
-
Here are some for the interface guys. First, I constantly switch between Cartesian and Polar coordinates on the LINE display of the OIP. Given that just about every other object type takes up more room on the OIP, hence I already have a large palette, could you please display BOTH modes at the same time? There is plenty of room available. It's quite a time waster to toggle back and forth to see the other coordinate display.
Second, If you can't grant the first wish, please consider this. The OI palette FORGETS the last LINE mode it was in when closed. It always opens to Cartesian display. This is very irritating when I want to work with Polar coordinates a lot. And no, leaving it open all the time is not a practical solution. The wasted screen real-estate is considerable.
Thank you,Raymond
-
A selection switch will keep me quiet - and happy.
[ 07-03-2002: Message edited by: MullinRJ ]
-
This is a becoming a really interesting topic. It has been my experience that the MAC standard has always reflected the modality of the VW9 selection mode. I just opened up a vintage reference, Inside Macintosh Volume 1 pp. I-39&40 entitled "Extending a Selection," and reconfirmed this suspicion. Re-marqueeing a selected object with the shift key depressed will deselect the object. In essence, it acts as a toggle. Even the Finder follows this modality, as does MacDraw, Freehand, Fontographer, Illustrator and a slew of other software packages.
VW has a long-standing history of adding to, not toggling, the selection status of objects that encounter a Shift-Marquee event. I happen to like it the way it has been up through VW8. I am sure if the whole VW community were polled, you would find a fair number of people who support each selection mode.
The solution seems quite simple, this should be a user selectable drawing feature, like the choice given for Click-Drag vs. Click-Click drawing modes.
NNA, please do not change the way we (I) have worked over the last decade. By all means, add new drawing features to the program, but not at the expense of replacing well entrenched features some of us still desire.
Raymond
-
It's almost 4 AM and I need to edit a series of Rounded Rectangles. I find the command GetRRDiam(), but where is SetRRDiam()? WHERE?
How many GET commands still have missing SET commands? And vice versa? You have been 98% complete on your command set for over 10 years. When do we get 100%? The obvious stuff should be OBVIOUS!
Not your happiest customer at the moment,Raymond
-
Katie,You are right about printing, but how about screen display? What you get on the printer is NOT what you see on the screen. With all the critical spacing and placement of lines required to make accurate drawings, it would be a big PLUS to see what we are really drawing. Consistency is king. Without it we are lost.
Best wishes,Raymond
-
Does your plotter have an asymmetrical resolution? Such as 1200 X & 600 Y? That might be one reason you are seeing differences.
<<Perhaps diagonal lines will reveal more whackiness.>>
Yes, if and when you plot diagonal lines, more wackiness will ensue. Line weights will grow as the angle of the line approaches 45?, up to 41% thicker. It is because the boys at NNA use a SQUARE pen for their graphics, a throwback to QuickDraw on the Mac. For a CAD package that prides itself as an "advanced" drafting tool, they fail miserably on this issue. Freehand figured out how to draw with a ROUND pen nearly a decade ago, so I know it can be done, NNA just has to want to badly enough. Personally, I am surprised more people haven't griped about this all along. It is, in my opinion, VectorWorks weakest detail.
Sorry NNA, I usually don't like to cast stones, but we have Super Computers on our desks and you still want us to use SQUARE pens?
-
Has anyone ever tried to set the TextStyle of a text object with:
Procedure SetTextStyle (objectHd:HANDLE; Start:INTEGER; Count:INTEGER; Style :INTEGER); ?
I had tried to use it for months with varying results:
TxtStyle := GetTextStyle(TxtHnd, 0); { save text style }{ change things up here }SetTextStyle(TxtHnd, 0, strLength, TxtStyle); { reset text style }
Note: In the above example, the whole text block has the same formatting as the first character. If individual characters have separate formatting, then additional code will be needed.
The documentation appears straightforward, but the results were anything but. I finally figured out what was missing from the written word. Just as the menu commands in the TEXT / STYLE submenu work, so does the VS command. The menu commands TOGGLE the text attributes. If some characters in a text block are BOLD and some are not, then with the whole text block selected (not a range of characters), selecting the Text / Style / Bold submenu item changes the BOLD characters to PLAIN, and the PLAIN characters to BOLD. To get all BOLD characters, you must first clear all formatting by selecting PLAIN and then select the BOLD option.
Adding one more SetTextStyle statement makes the next SetTextStyle command work the way the documentation would lend you to believe it should have worked in the first place.
TxtStyle := GetTextStyle(TxtHnd, 0); { save text style }{ change things up here }SetTextStyle(TxtHnd, 0, strLength, 0); { clear style formatting }SetTextStyle(TxtHnd, 0, strLength, TxtStyle); { set new style formatting }
This even works with multiple format styles selected, like BOLD & ITALIC.
Raymond
-
Maybe we should be labeled Power Posters, instead. Or Voluminous Vociferators, or, ... I think I just justified my existence.
Raymond
-
Ts, When you mention p1 and p2, you are referring to parameters passed to the ARC command in VS. Yes, they would be the DIAMETER of the ARC especially if the ARC were swept through 360?. Compared to the OVAL or the RECT, it would be analogous to the bounding box of the drawn object. For short arc segments it may seem a bit odd to define such an EMPTY box, but, think of it any way you like, as awkward as it may seem, those are the numbers that the ARC command requires. I have seen much more obtuse ways of defining arcs: Gerber RS-274D & IPC D350 come immediately to mind.
As a word of note, always use the upper left and the lower right coordinates of the bounding box, in that order, as the other combinations of corners definitely DON'T work. Been there, done that!
HTH,Raymond
-
As you know, there are 2 kinds of circles; the constrained Oval, and the 360? Arc. Which form do you want?
It is easy to program a circular Oval in VS using the Center/Radius method, you just have to do a little math.
If you have the Center point and the Second point, calculate the distance betwen both points, that is your Radius. Then fill in the blanks.
Rad := Distance(Xcen, Ycen, Pt2X, Pt2Y);Oval(Xcen-Rad, Ycen+Rad, Xcen+Rad, Ycen-Rad);
If that is not what you are looking for, then I do not understand your question.
HTH,Raymond
-
quote:Originally posted by bertb:Can someone help set the current tool, in addition to the function of setting current attributes, to the whatever object is picked after running the script?
bertb,This is not hard either. Just add the following case statement after the PenBack command:
... PenBack(Red, Green, Blue); { Select Tool } case GetType(h) of 2: SetTool(-201); { Line } 3: SetTool(-203); { Rect } 4: SetTool(-205); { Oval } 5: SetTool(-207); { Poly } 6: SetTool(-202); { Arc } 8: SetTool(-220); { Freehand } 10: SetTool(-200); { Text } 12: SetTool(-227); { Quarter Arc } 13: SetTool(-217); { RRect } 15: SetTool(-209); { 2D Symbol } 17: SetTool(-221); { 2D Locus } 21: SetTool(-204); { PolyLine } { etc. } end;
This list is not exhaustive, by any means. You may want more tools supported than the ones I have here. Embellish away. The Tool #'s and the Object Types are in the appendix of the VectorScript Function Reference which you should already have. If not, you really should download a copy.
HTH,Raymond
[ 06-14-2002: Message edited by: MullinRJ ]
-
TS,There is no difference if you only have one line of text in your text block. With two or more lines in a text block, Top Baseline refers to the baseline of the top line of text, while Bottom Baseline refers to the baseline of the last line of text.
Try the following to set the TVA if you are still using VW v8.5.2, which has the TVA attribute, but no way of manipulating it. Does version 9.5.x allow you to change it with a menu? I would hope so.
If you want to set the TVA for all text objects in a file, including symbols and groups, go to VectorDepot for another script to do just that. It also works in 8.5.2, though it says it is for version 9.
Procedure SetTxtVAlign;{ Change the TextVerticalAlign parameter of all selected text objects. } VAR TxtHnd: Handle; TA: Integer; x1, y1, x2, y2, x3, y3 :Real;
BEGIN repeat TA := IntDialog('Text Vertical Align Option (1-5)', '2'); if not DidCancel and ((TA<1) or (TA>5)) then Message('Value out of range. Try again, or Cancel.'); until DidCancel or ((TA>0) and (TA<6)); ClrMessage; if not DidCancel then begin TxtHnd := FSActLayer; while (TxtHnd <> nil) do begin if (GetType(TxtHnd)=10) then { only process text objects } begin GetBBox(TxtHnd, x1, y1, x2, y2); { Save position in (X1, Y1) } SetTextVerticalAlign(TxtHnd, TA); { Text will move after this call } GetBBox(TxtHnd, x2, y2, x3, y3); { Get new position in (X2, Y2) } hMove(TxtHnd, x1-x2, y1-y2); { move text back to original position } end; { end if } TxtHnd := NextSObj(TxtHnd); end; { end while } SysBeep; end; { end if }END; { End SetTxtVAlign }Run(SetTxtVAlign);
-
bertb,The first word 'INTEGER' was making your code inoperable. I took a few liberties and streamlined your code, and I also changed the comments a little. I hope this makes it readable to you.
Most code is adapted from code that already works so your scripting talents will grow from practice.
Have fun,Raymond
Procedure COT;{ Make all the attributes of the selected object the active attributes }VAR X, Y :REAL; h :HANDLE; Red, Green, Blue :LONGINT;BEGIN GetPt(X, Y); h := PickObject(X, Y); IF (h <> NIL) THEN begin { Make H's layer & class active } Layer(GetLName(GetLayer(h))); NameClass(GetClass(h)); { Set Fill Pattern & Colors } FillPat(GetFPat(h)); GetFillFore(h, Red, Green, Blue); FillFore(Red, Green, Blue); GetFillBack(h, Red, Green, Blue); FillBack(Red, Green, Blue); { Set Pen's Size, Style & Colors } PenSize(GetLW(h)); PenPat(GetLS(h)); GetPenFore(h, Red, Green, Blue); PenFore(Red, Green, Blue); GetPenBack(h, Red, Green, Blue); PenBack(Red, Green, Blue); end;END;RUN(COT);
-
bertb,The first word 'INTEGER' was making your code inoperable. I took a few liberties and streamlined your code, and I also changed the comments a little. I hope this makes it readable to you.
Most code is adapted from code that already works so your scripting talents will grow from practice.
Have fun,Raymond
Procedure COT;{ Make all the attributes of the selected object the active attributes }VAR X, Y :REAL; h :HANDLE; Red, Green, Blue :LONGINT;BEGIN GetPt(X, Y); h := PickObject(X, Y); IF (h <> NIL) THEN begin { Make H's layer & class active } Layer(GetLName(GetLayer(h))); NameClass(GetClass(h)); { Set Fill Pattern & Colors } FillPat(GetFPat(h)); GetFillFore(h, Red, Green, Blue); FillFore(Red, Green, Blue); GetFillBack(h, Red, Green, Blue); FillBack(Red, Green, Blue); { Set Pen's Size, Style & Colors } PenSize(GetLW(h)); PenPat(GetLS(h)); GetPenFore(h, Red, Green, Blue); PenFore(Red, Green, Blue); GetPenBack(h, Red, Green, Blue); PenBack(Red, Green, Blue); end;END;RUN(COT);
-
This question is to VW tech support:
What is the TYPE definition of <CRITERIA>?
[ 06-11-2002: Message edited by: MullinRJ ]
to change objects from one layer to another
in Vectorscript
Posted
OK, I had a few minutes free time and it's not 4 AM, so I can think straight. Here is a PutStuff script. One note of caution, if an object is locked, Cut will do nothing.
HTH,Raymond
Procedure PutStuff(Lyr :String; MoveObjs :Boolean); { Copy or Move all selected objects from the active layer to layer = "Lyr". } { If MoveObjs is TRUE, Objects are moved by Cut and Paste. } { If MoveObjs is FALSE, Objects are duplicated by Copy and Paste. } VAR LName :String; Begin LName := GetLName(ActLayer); { Get active layer name } if MoveObjs then DoMenuTextByName('Cut', 0) else DoMenuTextByName('Copy', 0); Layer(Lyr); { Make "Lyr" the active layer } DoMenuTextByName('Paste In Place', 0); Layer(LName); { return to previous active layer "LName" } End; { PutStuff }