Yes :) we should do this in a few other places too On Thu, Mar 28, 2019, 07:53 Mark Roszko <mark.ros...@gmail.com> wrote:
> Wouldn't it also be smarter to make it an enum? "2" and "1" are already > annoying values as you have to hunt them down. > > On Wed, Mar 27, 2019 at 10:59 PM Jon Evans <j...@craftyjon.com> wrote: > >> No, reverting that commit causes the problems to reappear, even after >> 175a2bc0b. >> >> In SCH_EDIT_FRAME::ConvertPart(), the logic appears to toggle the >> parameter >> between 1 and 2 (value 0 is not used). It appears that the convert value >> for a >> component is never supposed to be 0, even though the convert value for >> component >> members (shapes and pins) can be 0 to indicate that they are common to >> all body >> styles. >> >> In SCH_COMPONENT::GetNetListItem(), the following check is made: >> >> if( pin->GetConvert() && ( pin->GetConvert() != GetConvert() ) ) continue; >> >> This has the effect that a component with m_convert set to zero, >> containing pins >> with m_convert set to 1, will appear to have no pins when netlisting. I >> just >> checked some of the demo projects (that were not converted from Eagle, to >> rule >> that out), and it appears that we do default to setting m_convert to 1 >> when >> creating new parts. >> >> In DIALOG_EDIT_COMPONENT_IN_SCHEMATIC::TransferDataFromWindow(): >> >> if( m_cbAlternateSymbol->IsEnabled() ) m_cmp->SetConvert( >> m_cbAlternateSymbol->GetValue() ? 2 : 1 ); >> >> I am out of time to trace this any deeper, but from brief examination of >> the >> code, it looks like the m_convert parameter of SCH_COMPONENT should >> default to >> 1. It is initialized this way in all places except for the Eagle >> conversion, >> which is probably why this bug was triggered. >> >> >> -Jon >> >> On Wed, Mar 27, 2019 at 10:36 AM Wayne Stambaugh <stambau...@gmail.com> >> wrote: >> >>> Jon, >>> >>> Would you please see if reverting commit ab74445df4 and loading the the >>> schematic with the 64 bit time stamps has been fixed by commit 175a2bc0b >>> when you get a chance? If commit 175a2bc0b resolves the issue, then >>> your commit should be reverted. >>> >>> Thanks, >>> >>> Wayne >>> >>> On 3/27/2019 9:44 AM, Jon Evans wrote: >>> > In my investigation of the issue in that forum thread, I found that >>> > eeschema was choking on the convert value being zero. >>> > >>> > In that case, I have misunderstood the code and we should probably >>> > revert ab74445df4 >>> > That commit fixed the loading/netlisting issues in the forum thread but >>> > perhaps it fixed it the wrong way. >>> > >>> > -Jon >>> > >>> > On Wed, Mar 27, 2019 at 8:35 AM Wayne Stambaugh <stambau...@gmail.com >>> > <mailto:stambau...@gmail.com>> wrote: >>> > >>> > Oops. >>> > >>> > On 3/27/2019 8:30 AM, Wayne Stambaugh wrote: >>> > > Jon, >>> > > >>> > > I don't think setting m_Convert to 1 is the correct solution >>> > unless the >>> > > part actually has a convert. According to the Doxygen comment: >>> > >>> > /** >>> > * Shape identification for alternate body styles. Set 0 if the >>> item >>> > * is common to all body styles. This is commonly referred to as >>> > * DeMorgan style and this is typically how it is used in KiCad. >>> > */ >>> > >>> > Unless someone changed this behavior this should still be valid. >>> > >>> > > >>> > > >>> > > On 3/23/2019 9:08 PM, Jon Evans wrote: >>> > >> For context, I've been looking at the issues in this forum >>> > >> >>> > thread: >>> https://forum.kicad.info/t/before-giving-up-on-kicad-one-last-attempt-erc-misery/15933/63 >>> > >>> > This post is about the timestamps not the convert value. >>> > >>> > >> >>> > >> I have already pushed a band-aid fix to "repair" these >>> > situations, but >>> > >> it looks like they are being caused by the EAGLE importer (or at >>> > least >>> > >> that is one path to this situation coming up) >>> > >> >>> > >> Specifically, it looks like m_convert is set to 0 in >>> > >> SCH_COMPONENT::Init(), but this value is not valid (it should >>> be at >>> > >> least 1 for components). >>> > >> >>> > >> Are there any cases that I am missing, where it makes sense for >>> a >>> > >> component to have m_convert set to 0? If not, it's an easy fix >>> > in that >>> > >> Init() to set it to 1. If so, we can just update >>> > the SCH_EAGLE_PLUGIN >>> > >> to call SetConvert() wherever it creates new components. >>> > >> >>> > >> -Jon >>> > >> >>> > >> _______________________________________________ >>> > >> Mailing list: https://launchpad.net/~kicad-developers >>> > >> Post to : kicad-developers@lists.launchpad.net >>> > <mailto:kicad-developers@lists.launchpad.net> >>> > >> Unsubscribe : https://launchpad.net/~kicad-developers >>> > >> More help : https://help.launchpad.net/ListHelp >>> > >> >>> > >>> > _______________________________________________ >>> > Mailing list: https://launchpad.net/~kicad-developers >>> > Post to : kicad-developers@lists.launchpad.net >>> > <mailto:kicad-developers@lists.launchpad.net> >>> > Unsubscribe : https://launchpad.net/~kicad-developers >>> > More help : https://help.launchpad.net/ListHelp >>> > >>> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > -- > Mark >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
