| ID: | 2495 |
| From: | Alain Vigne <al...@gmail.com> |
| Date: | Sat, 1 Dec 2018 16:07:30 +0100 |
| Subject: | Re: [pcb-rnd] drc: new DRC dialogs, drc is safe to use now |
| in-reply-to: | 2492 from ge...@igor2.repo.hu |
| replies: | 2496 from ge...@igor2.repo.hu |
--00000000000008a4f7057bf74781 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 1, 2018 at 10:05 AM <gedau@igor2.repo.hu> wrote: > Hi Alain, > > On Sat, 1 Dec 2018, Alain Vigne wrote: > > >Thank you for the first step in the right direction. > > > >I might question 4 things ? > > > >1. It makes sense to me the DRC preview related to an error, is a *frozen* > >drawing: I mean, the DRC was performed on a state of the layout where this > >error is occurring. If later, I change the layout and want to refer back > to > >this DRC error, I need to compare previous situation (error) versus > current > >(fixed). > >It seems to me this is lost in translation because I will see same layout > in > >the 2 views ? > > Live preview instead of screenshot: yup. This is intentional, and the > reason is explained in the pool node. (Btw, we had this change many > months ago, even with the old gtk drc dialog.) > > The preview's extra is that it does a color highlight so it makes it > easier to identify the problem. > I 100% support the highlight colors. My point is : previously, you had a fix image, now a "dynamic" one. "the preview is automatically updated as the board changes, so it is never outdated." says the pool node. I do see cases where the "PCB choice" is better than the "never outdated" one... Now, as the view is "updated", the "fixed" information user might provide is even more relevant: you fix some violations, browse the list, see a DRC violation, but don't know where it is as the layout changed, and error might have been corrected. You can reply me then : Delete this error with the Del. button. OK that is the new use case now, fine. And I guess I will re-run DRC checks (refresh ?) as it is fast ? I don't know how fast or slow it is on "complicated" PCB. From Integrated Circuit dev. perspective, I just know we want to run as LESS as possible the DRC runs. > > > >2. The Del button is removing the violation from the list... Would it make > >sense to mark this violation as "fixed" and have a check box to display > >"fixed" yes/no instead ? > >I mean, if latter on I have to tackle a related DRC issue, I still can see > >it, even if I considered it "fixed" and I deleted it ? > > I was considering the checkbox, but I found it unnecessary. If you click > on refresh, the whole thing is remapped and things you fixed are removed > anyway. > > So I decided to provide a way to remove an item so you can keep a shorter > list of things you still need to address. > > >3. Is there any kind of graphical indication about the error ? I mean if a > >spacing is violated, preview can draw (as an offending polygon/rectangle > ?) > >where the spacing is laying between the 2 objects ? > > Nope, because we don't have that data. The DRC algorithm can determine if > there's a violated gap, but it can't tell where it happened. It's not > something that's going to change soon and it's outside the scope. > Will it be in the future ? > > (However, with the 2-color highlight, it's probably very easy to spot the > problem, unless you have some special case, like two huge, very complex > shaped, non-clearing polygons.) > > >4. How do you avoid the "conjugate error" between 2 objects, I mean 1. > error > >is: a object is "blue", b "red", 2. a is "red", b "blue" ? > >This will give me 2 errors for the same DRC violation ? > > Yes, it may be listed twice, as I wrote in the other email yesterday, and > will mask other errors of the same nets. This has nothing to do with the > DRC GUI, but how the drc algorithm works. As I wrote, these problems will > not be addressed in this effort. > Oops, I did not read e-mails in correct order. Sorry. I agree with you there. > > Regards, > > Igor2 -- Alain V. --00000000000008a4f7057bf74781 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat= , Dec 1, 2018 at 10:05 AM <<a href=3D"mailto:gedau@igor2.repo.hu">gedau@= igor2.repo.hu</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ala= in,<br> <br> On Sat, 1 Dec 2018, Alain Vigne wrote:<br> <br> >Thank you for the first step in the right direction.<br> ><br> >I might question 4 things ?<br> ><br> >1. It makes sense to me the DRC preview related to an error, is a *froz= en*<br> >drawing: I mean, the DRC was performed on a state of the layout where t= his<br> >error is occurring. If later, I change the layout and want to refer bac= k to<br> >this DRC error, I need to compare previous situation (error) versus cur= rent<br> >(fixed).<br> >It seems to me this is lost in translation because I will see same layo= ut in<br> >the 2 views ?<br> <br> Live preview instead of screenshot: yup. This is intentional, and the <br> reason is explained in the pool node. (Btw, we had this change many <br> months ago, even with the old gtk drc dialog.)<br> <br> The preview's extra is that it does a color highlight so it makes it <b= r> easier to identify the problem.<br></blockquote><div>I 100% support the hig= hlight colors.</div><div> My point is : previously, you had a fix image, no= w a "dynamic" one. <br></div><div>"the preview is automatica= lly updated as the board changes, so it is never outdated." says the pool node.</d= iv><div></div><div>I do see cases where the "PCB choice" is bette= r than the "never outdated" one... <br></div><div><br></div><div>= Now, as the view is "updated", the "fixed" information = user might provide is even more relevant: you fix some violations, browse t= he list, see a DRC violation, but don't know where it is as the layout = changed, and error might have been corrected. <br></div><div>You can reply = me then : Delete this error with the Del. button.</div><div>OK that is the = new use case now, fine.<br></div><div>And I guess I will re-run DRC checks = (refresh ?) as it is fast ? I don't know how fast or slow it is on &quo= t;complicated" PCB. From Integrated Circuit dev. perspective, I just k= now we want to run as LESS as possible the DRC runs.<br></div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> =C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> ><br> >2. The Del button is removing the violation from the list... Would it m= ake<br> >sense to mark this violation as "fixed" and have a check box = to display<br> >"fixed" yes/no=C2=A0 instead ?<br> >I mean, if latter on I have to tackle a related DRC issue, I still can = see<br> >it, even if I considered it "fixed" and I deleted it ?<br> <br> I was considering the checkbox, but I found it unnecessary. If you click <b= r> on refresh, the whole thing is remapped and things you fixed are removed <b= r> anyway.<br> <br> So I decided to provide a way to remove an item so you can keep a shorter <= br> list of things you still need to address.<br> <br> >3. Is there any kind of graphical indication about the error ? I mean i= f a<br> >spacing is violated, preview can draw (as an offending polygon/rectangl= e ?)<br> >where the spacing is laying between the 2 objects ?<br> <br> Nope, because we don't have that data. The DRC algorithm can determine = if <br> there's a violated gap, but it can't tell where it happened. It'= ;s not <br> something that's going to change soon and it's outside the scope.<b= r></blockquote><div>Will it be in the future ? <br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <br> (However, with the 2-color highlight, it's probably very easy to spot t= he <br> problem, unless you have some special case, like two huge, very complex <br= > shaped, non-clearing polygons.)<br> <br> >4. How do you avoid the "conjugate error" between 2 objects, = I mean 1. error<br> >is: a object is "blue", b "red", 2. a is "red&= quot;, b "blue" ?<br> >This will give me 2 errors for the same DRC violation ?<br> <br> Yes, it may be listed twice, as I wrote in the other email yesterday, and <= br> will mask other errors of the same nets. This has nothing to do with the <b= r> DRC GUI, but how the drc algorithm works. As I wrote, these problems will <= br> not be addressed in this effort.<br></blockquote><div>Oops, I did not read = e-mails in correct order. Sorry. <br></div><div>I agree with you there.<br>= </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> <br> Regards,<br> <br> Igor2</blockquote></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" d= ata-smartmail=3D"gmail_signature">Alain V.</div></div> --00000000000008a4f7057bf74781--
Reply subtree:
2495 Re: [pcb-rnd] drc: new DRC dialogs, drc is safe to use now from Alain Vigne <al...@gmail.com>
2496 Re: [pcb-rnd] drc: new DRC dialogs, drc is safe to use now from ge...@igor2.repo.hu