Post by thread:[EE] Don''t want diagonal routing from Eagle!!!

nicholasdatt@yahoo.co.uk wrote: > I specify 99 for DiagStep as instructed in the user manual, and yet > i do receive some diagonal lines. Why?? Because the cost of all other solutions was higher. 99 only makes it unlikely, not impossible. > Also, is there a way to prevent tracks from top and bottom overlapping - > this is when the red and the blue on the screen merge and form pink?? Not that I can think of. You can specify keepout areas for the autorouter, but not automatically make a trace on one layer a keepout on another. Why do you want this? This sounds like you are getting stuck in an implementation rathole, and need to step back and think about how to solve the true problem. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

>From all the stripboard autorouting requests on the list, I'm guessing someone could make a little bit of money by developing a stripboard EDA package. Given the restraints of stripboard, it wouldn't be overly difficult either... Then they can hope to be bought out by veroboard and live in luxury for a few months. -Adam On 4/13/06, spam_OUTnicholasdattTakeThisOuTyahoo.co.uk <.....nicholasdattKILLspam@spam@yahoo.co.uk> wrote: {Quote hidden}> > > Also, is there a way to prevent tracks from top and bottom overlapping - > > > this is when the red and the blue on the screen merge and form pink?? > > > > Not that I can think of. You can specify keepout areas for the > autorouter, > > but not automatically make a trace on one layer a keepout on another. Why > > do you want this? This sounds like you are getting stuck in an > > implementation rathole, and need to step back and think about how to solve > > the true problem. > > No, it's because I am working with a stripboard. In a stripboard the blue > layer > must be implemented on both sides (because the strips are one way.) This > leaves us with a situation that if the red layer overlaps the blue layer and > if the > blue layer needs to be implemented on top(the other direction to the strips) > we get an impossibility. > -

On 4/13/06, EraseMEnicholasdattspam_OUTTakeThisOuTyahoo.co.uk <nicholasdattspam_OUTyahoo.co.uk> wrote: > > > Also, is there a way to prevent tracks from top and bottom overlapping - > > > this is when the red and the blue on the screen merge and form pink?? > > > > Not that I can think of. You can specify keepout areas for the > autorouter, > > but not automatically make a trace on one layer a keepout on another. Why > > do you want this? This sounds like you are getting stuck in an > > implementation rathole, and need to step back and think about how to solve > > the true problem. > > No, it's because I am working with a stripboard. In a stripboard the blue > layer > must be implemented on both sides (because the strips are one way.) This > leaves us with a situation that if the red layer overlaps the blue layer and > if the > blue layer needs to be implemented on top(the other direction to the strips) > we get an impossibility. Hmm, I don't understand this. Blue = one layer. Red = other layer Usually red = top and blue = bottom for two layers Eagle style. So, why you can't design a dual layer stripboard ? Light me please. greetings, Vasile BTW, if you want a real CAD, incomparable with Eagle, then try Pads.

> > > > Also, is there a way to prevent tracks from top and bottom overlapping - > > > > this is when the red and the blue on the screen merge and form pink?? > > > > > > Not that I can think of. You can specify keepout areas for the > > autorouter, > > > but not automatically make a trace on one layer a keepout on another. Why > > > do you want this? This sounds like you are getting stuck in an > > > implementation rathole, and need to step back and think about how to solve > > > the true problem. > > > > No, it's because I am working with a stripboard. In a stripboard the blue > > layer > > must be implemented on both sides (because the strips are one way.) This > > leaves us with a situation that if the red layer overlaps the blue layer and > > if the > > blue layer needs to be implemented on top(the other direction to the strips) > > we get an impossibility. > > Hmm, I don't understand this. Blue = one layer. Red = other layer > Usually red = top and blue = bottom for two layers Eagle style. > So, why you can't design a dual layer stripboard ? > Light me please. Stripboards are not double sided > > greetings, > Vasile > > BTW, if you want a real CAD, incomparable with Eagle, then try Pads. Is Eagle not "real" ? why ? If you want me to checkout Pads - send me a link. tia.

On 4/16/06, @spam@nicholasdattKILLspamyahoo.co.uk <KILLspamnicholasdattKILLspamyahoo.co.uk> wrote: {Quote hidden}> > > > > Also, is there a way to prevent tracks from top and bottom > overlapping - > > > > > this is when the red and the blue on the screen merge and form > pink?? > > > > > > > > Not that I can think of. You can specify keepout areas for the > > > autorouter, > > > > but not automatically make a trace on one layer a keepout on another. > Why > > > > do you want this? This sounds like you are getting stuck in an > > > > implementation rathole, and need to step back and think about how to > solve > > > > the true problem. > > > > > > No, it's because I am working with a stripboard. In a stripboard the > blue > > > layer > > > must be implemented on both sides (because the strips are one way.) This > > > leaves us with a situation that if the red layer overlaps the blue layer > and > > > if the > > > blue layer needs to be implemented on top(the other direction to the > strips) > > > we get an impossibility. > > > > Hmm, I don't understand this. Blue = one layer. Red = other layer > > Usually red = top and blue = bottom for two layers Eagle style. > > So, why you can't design a dual layer stripboard ? > > Light me please. > > Stripboards are not double sided And does not require autoruter either... just copy and paste. So which is the problem then? > > > > > greetings, > > Vasile > > > > BTW, if you want a real CAD, incomparable with Eagle, then try Pads. > > Is Eagle not "real" ? why ? too many to say... > If you want me to checkout Pads - send me a link. http://www.mentor.com/products/pcb/pads/demos/request.cfm download, run and see till the end the "Pads layout with Pads Router tour". It's a video. If you know well Eagle, you'll understand pronto the major differences between those two. greetings, Vasile > tia. > -

0000000000000 Hi Vasile PADs is a commercial offering with no apparent "freebie" version. Eagle has "freebie" versions that run on Linux, WINDOZE and OS X. It appears to me that comparing these is " apples to oranges " Gus 0000000000000 On 2006-Apr 16, at 11:16 AM, Vasile Surducan wrote: On 4/16/06, RemoveMEnicholasdattTakeThisOuTyahoo.co.uk <spamBeGonenicholasdattspamBeGoneyahoo.co.uk> wrote: {Quote hidden}>>>>> Also, is there a way to prevent tracks from top and bottom > overlapping - >>>>> this is when the red and the blue on the screen merge and form > pink?? >>>> >>>> Not that I can think of. You can specify keepout areas for the >>> autorouter, >>>> but not automatically make a trace on one layer a keepout on >>>> another. > Why >>>> do you want this? This sounds like you are getting stuck in an >>>> implementation rathole, and need to step back and think about >>>> how to > solve >>>> the true problem. >>> >>> No, it's because I am working with a stripboard. In a stripboard the > blue >>> layer >>> must be implemented on both sides (because the strips are one >>> way.) This >>> leaves us with a situation that if the red layer overlaps the >>> blue layer > and >>> if the >>> blue layer needs to be implemented on top(the other direction to the > strips) >>> we get an impossibility. >> >> Hmm, I don't understand this. Blue = one layer. Red = other layer >> Usually red = top and blue = bottom for two layers Eagle style. >> So, why you can't design a dual layer stripboard ? >> Light me please. > > Stripboards are not double sided And does not require autoruter either... just copy and paste. So which is the problem then? > >> >> greetings, >> Vasile >> >> BTW, if you want a real CAD, incomparable with Eagle, then try Pads. > > Is Eagle not "real" ? why ? too many to say... > If you want me to checkout Pads - send me a link. http://www.mentor.com/products/pcb/pads/demos/request.cfm download, run and see till the end the "Pads layout with Pads Router tour". It's a video. If you know well Eagle, you'll understand pronto the major differences between those two. greetings, Vasile > tia. > -

On Apr 16, 2006, at 10:33 AM, blackcat wrote: > PADs is a commercial offering... "Starting at under $3500" :-) > Eagle has "freebie" versions that run on Linux, WINDOZE and OS X. Cadsoft is a veritable mecca of software distribution enlightenment. In addition to their freeware (which has some restrictions on "professional" use), they have a cheap "lite" version, a "non-profit" version (less size restrictions, but back to non-professional use), and a set of scaled and less restricted versions topping out at $1200 for one user... > It appears to me that comparing these is " apples to oranges " Perhaps. I've read enough professionals on the Cadsoft newsgroups describing how they like Eagle better than the much-more-expensive package they used to use that I no longer dismiss Eagle as a baby implementation usable only by those who want a free package... There are things it doesn't do that perhaps are important in some arenas (thermal analysis, circuit simulation, automatic placement; there are LOTS of "advanced features" that Eagle doesn't have, but apparently their presence comes with a price. (If you think the learning curve for Eagle is steep, apparently you haven't seen ANYTHING!) I've been very impressed with the level of support that Cadsoft provides; far above what many of the other free cad packages provide. Questions get answered. Bugs I find have already been fixed, or are fixed promptly and released quickly. And with the amount of improvement between successive release has been impressive; today's Eagle is a lot better than the first version I tried... Eagle doesn't do everything everyone wants, but it's clear that the engineers there ARE paying attention. That's really good. For freeware, that's phenomenal! BillW

William Chops Westfield wrote: > Cadsoft is a veritable mecca of software distribution enlightenment. > In addition to their freeware (which has some restrictions on > "professional" use), they have a cheap "lite" version, a "non-profit" > version (less size restrictions, but back to non-professional use), > and a set of scaled and less restricted versions topping out at > $1200 for one user... And the next few additional users are only $300 each. I think that's quite a bargain. We've got 3 licenses at Embed. I got one of my customers to get me an Eagle license for use there. It wasn't too hard a sell since my $1200 first user Eagle license cost a lot less than an additional license to what some people were sortof using. Once they saw that I could produce professional results with it, they readily got two more licenses for additional engineers. Nobody is using the big expensive package anymore. My biggest gripe with Eagle is that they still seem to be aiming too much at the university and not enough at the professional market. Real support for BOM production is missing, which is a shame since it would be so easy to get to the 90% level from 10% where they are now. All they would have to do is implement at least one additional >VALUE string, like >VAL2 maybe. This could be shown, or not, on the schematic or elsewhere as you wanted to. I would not show it and use it for part number information. I would then write a ULP that would parse this VAL2 string to build most of the BOM automatically. The next step would be to add more strings, some specifically for common things like part number and manufacturer, but a few uncommitted strings the user could use with a ULP any way they wanted. This would still be easy for them to do. The next step up would be much more difficult and probably there is no way to please everyone. Eagle would would have a part number database, which would totally automate BOM production. However, they are unlikely to get that right, so I'd rather they just gave me a string or a few and let me take care of the rest my way. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

On 4/17/06, Olin Lathrop <TakeThisOuTolin_piclistEraseMEspam_OUTembedinc.com> wrote: > William Chops Westfield wrote: > > Cadsoft is a veritable mecca of software distribution enlightenment. > > In addition to their freeware (which has some restrictions on > > "professional" use), they have a cheap "lite" version, a "non-profit" > > version (less size restrictions, but back to non-professional use), > > and a set of scaled and less restricted versions topping out at > > $1200 for one user... > > And the next few additional users are only $300 each. I think that's quite > a bargain. We've got 3 licenses at Embed. I got one of my customers to get > me an Eagle license for use there. It wasn't too hard a sell since my $1200 > first user Eagle license cost a lot less than an additional license to what > some people were sortof using. Once they saw that I could produce > professional results with it, they readily got two more licenses for > additional engineers. Nobody is using the big expensive package anymore. > > My biggest gripe with Eagle is that they still seem to be aiming too much at > the university and not enough at the professional market. Real support for > BOM production is missing, Hi Olin, this is just one small problem and it's not a problem for hobbists. I've cried on it on my last project having about 400 passive components writting the shit BOM manually. All proffesional CAD packages has solved this for a long time: Orcad, Protel, P-Cad are just three of them where the component have indeed 7 fields, so you can cover the name, value, vendor code, vendor description, seller code, the AVL field and other comments about mounting, in *.xls compatible files. If you've tried RF projects where quadrature routes must be egual lenght and parallel routed, or high frequency clock distributions where again the routes lenght must be perfect equal, you know that eagle can't be usefull only with a lot of struggle. It can't measure distances only ortogonally or the RF lines are not allways ortogonally. Placing a component other than on ox or oy (with a variable angle) is the hell thing. Rerouting manually a route does not move automatically the adjacent routes, you have to delete and reroute them. Dying till finish. Multiple ground planes (on double eurocard size, four layers) with resonable widths (16 or 24 mil) take up to 15 seconds for redrawing on a top 3.3GHz HP pentium with 512Mb of video memory. In fact the video size does not matter for Eagle... Eagle is an ugly joke for a proffesional PCB designer (my opinion, you all could have any other). However it works ok for hobby and small projects where BOM ulp is perfect. About the price I'm not telling nothing (a deep search on the web will reveal a lot of things, nice or not...), there is a *complete free* french CAD package (yes, the same which built the Liberty statue...) with the same functionality as proffesional Eagle, and open source on Yahoo groups. best regards, Vasile which is a shame since it would be so easy to get {Quote hidden}> to the 90% level from 10% where they are now. All they would have to do is > implement at least one additional >VALUE string, like >VAL2 maybe. This > could be shown, or not, on the schematic or elsewhere as you wanted to. I > would not show it and use it for part number information. I would then > write a ULP that would parse this VAL2 string to build most of the BOM > automatically. > > The next step would be to add more strings, some specifically for common > things like part number and manufacturer, but a few uncommitted strings the > user could use with a ULP any way they wanted. This would still be easy for > them to do. > > The next step up would be much more difficult and probably there is no way > to please everyone. Eagle would would have a part number database, which > would totally automate BOM production. However, they are unlikely to get > that right, so I'd rather they just gave me a string or a few and let me > take care of the rest my way. > > > ****************************************************************** > Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC > consultant in 2004 program year. http://www.embedinc.com/products > -