Cute, توصیه شده, مقاله

باگ های جهنمی را چطور خطایابی کنیم!

خطایابی یکی از مهم ترین بخش‌های طراحی یک محصول است، احتمالاً برای شما هم پیش آمده، مداری را طراحی کردید و بعد از کلی کلنجار رفتن، دیده‌اید آن طور که باید کار نمی‌کند! اصلاً چرا مداری که همه چیزش حساب شده، نباید کار کند و باگ داشته باشد؟ اینجاست که تفاوت یک طراح خوب و معمولی و غیر طراح مشخص می‌شود. راه حل‌هایی که آدم‌ها برای حل مشکلات ارائه می‌کنند، نشان دهنده میزان تسلط افراد روی آن مسئله است!

بله، به همین سادگی، یک غیر طراح وقتی با اولین بن‌بست مواجه شد، دست از تلاش می‌کشد و با یک “نمی‌شود” خیلی ساده همه چیز را تمام می‌کند. شخص دیگری سعی می‌کند با عوض کردن قطعات مختلف، چک کردن اتصالات، یا بسته به درکی که از عملکرد قطعات مختلف دارد، مشکل را حل کند، تا اینجا طراح معمولی داریم! اما چطور می‌شود یک طراح خوب بود؟ یا بهتر بگویم یک طراح هوشمند بود؟ در این مقاله سعی می‌کنم به این سؤال جواب بدم و البته خوشحال می‌شوم که دوستان و همراهان عزیز سیسوگ، با دیدگاه‌هایشان این مقاله را کامل‌تر کنند.

 

از طراحی تا تعمیرکاری!

تعمیرکار

دوستان زیادی را دیدم که این دو مقوله را مقوله‌های کاملاً متفاوت می‌دانند. در حالی که واقعاً این‌طور نیست. احتمالاً همان‌طور که از مقدمه متوجه شده‌اید، برای این که طراحی خوبی باشید باید تعمیرکار خوبی نیز باشید و هیچ اجتنابی از این مسئله نیست. فرض کنید در حال طراحی محصول جدیدی هستید که با مشکلی در عملکرد دستگاه موجه می‌شود. اگر تعمیرکار خوبی نباشید و نتوانید آن مشکل (و حتی مشکلات احتمالی دیگر) را حل کنید، هیچ وقت محصول قابل اتکایی نخواهید داشت که به بازار عرضه کنید.

البته لازمه که منظورم را از تعمیرکار این‌طور تعریف کنم که، تعمیرکار شخصی است که ایراد یک دستگاه را ردیابی می‌کند و منشأ وجودی آن را پیدا می‌کند. البته تعویض آن قطعه یا مکانیزم مشکل دار ممکن است بر عهده او باشد یا نباشد.

این مقوله رو به شکل عام نگاه کنید. یعنی تعمیرکاری را در رفع ایرادات سخت‌افزاری نبینید. البته احتمالاً بخش بیشتر ایرادات در فاز طراحی محصول مربوط به نرم‌افزار است تا سخت‌افزار، ولی باید نگاه کلی داشت و همه چیز را در نظر گرفت!

خلاصه، اگر بخواهم این بحث را جمع بندی کنم، باید بگویم که: “ممکن است هر تعمیرکار خوب، یک طراح خوب نباشد، ولی حتماً هر طراح خوب یک تعمیرکار خوب هم هست.”

 

خطایابی نیاز به شناخت دارد!

اهمیت شناخت در خطایابی

اگر بخواهیم واقع بین باشم و بحث سعی و خطا را کنار بگذاریم، هیچ راهی برای پیدا کردن مشکل نیست، جز این که اشراف خوبی بر روی مکانیزم عملکرد دستگاه داشته باشید. یعنی قبل از این که بخواهید مشکل رو پیدا کنید، باید بفهمید که یک دستگاه چطور کار می‌کند! حالا که آن کار را انجام نمی‌دهد، متوجه می‌شوید مشکل از کجاست که آن کار را انجام نمی‌دهد!

ممکن است کمی خنده دار باشد اگر بخواهم به شما بگویم، شاید تعدادی از طراح‌ها نمی‌داند دستگاهی که طراحی کرده‌اند چطور کار می‌کند! ولی متأسفانه واقعیت این است که وقتی طراحی نمی‌تواند مشکل دستگاهی که طراحی کرده را پیدا کند، یعنی نمی‌داند آن دستگاه چطور دارد کار می‌کند! (این مورد بیشتر در مورد دوستانی دیده می‌شود که با استفاده از ابزار آردوینو سعی در طراحی یک محصول دارند).

البته گاهی شرایطی وجود دارد که ممکن است نتوانید نسبت به عملکرد آنها دید درستی داشته باشید، آنها از این قضیه جدا می‌شوند. مثل ماژول‌های مخابراتی.

بگذارید برای ملموس شدن موضوع، یک مثال بزنم. خیلی از دوستان برای این که سریع‌تر محصولی رو آماده کنند تمام بخش‌های مورد نیاز پروژه را خودشان طراحی نمی‌کنند و از کتابخانه‌های آماده استفاده می‌کنند. در مواردی حتی داکیومنت‌های آن را نیز مطالعه نمی‌کنند. وقتی برنامه آن طور که باید کار نمی‌کند، درست نمی‌دانند مشکل از کجا می‌تواند باشد. چرا که نمی‌داند آن کتابخانه از چه منابعی استفاده کرده و یا با چه روشی مسئله را حل کرده است. آیا با دیگر کتابخانه‌ها اختلال دارد یا نه؟! این تازه آن نقطه‌ای است که جهنم شروع می‌شود! در نتیجه برای پیدا کردن منشأ یک خطا، نیاز است که عملکرد جزء به جزء اجزای دستگاه را بدانید تا بتوانید در ساده‌ترین حالت ممکن ریشه خطا را پیدا کنید. البته که با سعی و خطا نیز می‌شود مشکل را پیدا کرد. ولی نکته اینجاست چقدر زمان صرف پیدا کردن مشکل می‌کنید.

 

با خودتان صادق باشید، همه چیز نویز نیست!

برای این که بتوانید مشکلی را حل کنید اولین قدم این است که صادق باشید، حداقل با خودتان! درست است که نویز پیش‌بینی‌ناپذیر است و می‌تواند تأثیرات غیرقابل پیش‌بینی روی عملکرد یک مدار داشته باشد، ولی همه چیز هم نویز نیست! بر خلاف چیزی که فکر می‌کنید رفتار نویز را می‌شود حتی پیش‌بینی کرد و حتی می‌شود گفت که یک طرح چقدر می‌تواند تحت تأثیر نویزهای محیطی قرار بگیرد و برای حل آنها راهکار هم داد.

اولین چیزی که باید باور کنید این است که مسئله‌ای وجود دارد و برای حل آن نیاز است فکر انجام شود. دوستان زیادی را دیدم که معتقد بوده‌اند دستگاهی که طراحی کرده‌اند هیچ مشکلی ندارد چرا که بر روی میز کار آنها به خوبی ساعت‌ها کار می‌کند، ولی در محیط بهره برداری به دلیل وجود نویزهای خیلی زیاد، عملکرد دستگاه دچار مشکل می‌شود.

برای دابل چک کردن این مسئله به این مورد استناد می‌کنند که ریست یا عملکرد نامتعارف دستگاه، پریودیک و قابل پیش‌بینی نیست. گاهی یک ساعت بعد، گاهی بعد از ۱ روز و گاهی هم ۱۰ دقیقه بعد از شروع به کار دستگاه اتفاق می‌افتد.

ممکن است حتی شما هم متقاعد شده باشید که نویز، منشأ مشکل باشد، ولی مواردی که من بررسی کردم مشکل به هیچ وجه نویز نبوده و برای مثال یک مشکل نرم‌افزاری ساده مثل آورفلو شدن بافر دریافت سریال است که این مشکل را پیش می‌آورد و یا مواردی از این دست.

در مواردی حتی تقصیر را گردن کامپایلر و باگ‌های احتمالی کامپایلر می‌اندازند.

توصیه مهم این است که اگر قرار است برای خطایابی، عملکرد یک دستگاه را مانیتور کنید، حتماً در محیط بهره برداری این کار رو انجام بدهید و یا تا جای ممکن تمام شرایط محیط را فراهم کنید تا به واقعیت نزدیک‌تر باشید. البته با استفاده از راهکارهای مناسب، قوی‌ترین دلایل اختلال مدار را رفع کنید.

و هرگز فراموش نکنید که نویز از رگ گردن به مدار شما نزدیک‌تر است.

 

 

چه باگی جهنمی است؟!

تا اینجا راهکارهای ساده و پایه‌ای را برای خطایابی باگ‌های ساده را بررسی کردیم. باگ‌هایی که خیلی ساده در حین طراحی دیده می‌شوند یا در محیط بهره برداری به وضوح قابل مشاهد است. البته که همیشه باگ‌ها اعصاب خردکن هستند! بعضی‌ها کم و بعضی‌ها زیاد!

باگ‌های خوب آن دسته باگ‌هایی هستند که در هنگام طراحی یا توسعه نرم افزار با آن مواجه می‌شود. از آنجایی که در این مرحله همه چیز در شرایط آزمایشگاهی در حال اتفاق افتادن است، پیدا کردن منشأ این دسته باگ‌ها خیلی ساده است. من به این باگ‌ها می‌گویم باگ‌های مهربان! چرا که شرایط ایجاد و مشاهده آنها کاملاً مشخص است و قبل از ارائه محصول نهایی به مشتری بروز کرده‌اند. در این شرایط خیلی ساده می‌شود خطایابی کرد و منشأ باگ را حدس زد و مهم‌تر از همه، بعد از پیدا کردن منشأ احتمالی و رفع ایراد مربوطه، به سادگی می‌شود با چک کردن مجدد مشاهده کرد که خطای مربوطه رفع شده است یا خیر!

اما باگ جهنمی چیست؟ دقیقاً آن دسته از خطاهایی که فقط در شرایط خاصی اتفاق می‌افتند و مشاهده آنها بسیار سخت است. مثلاً خطایی که فقط گاهی در تابستان، آن هم بین ماه‌های تیر و مرداد، برای تجهیزات نصب شده اتفاق می‌افتد!!

ممکن است فکر کنید که شوخی می‌کنم. ولی متأسفانه باید بگم نه شوخی نمی‌کنم، واقعاً چنین اتفاقی برای خود من افتاده است. در فصل زمستان دستگاهی را برای کنترل گاز ورودی به توربین طراحی کرده بودم که به خوبی کار می‌کرد، اما در تابستان دچار مشکل شد 😐

و یا دستگاهی که اخیراً به مدت سه یا چهار هفته، به معنی واقعی کلمه بیچاره‌ام کرد تا خطایابی کنم و مشکلش رو پیدا کنم! مشکل این بود که دستگاه در داخل کشور بدون هیچ مشکلی کار می‌کرد اما در خارج از کشور کار نمی‌کرد! (دستگاه به شدت وطن دوست تشریف داشتند!) بعد از گمانه زنی در خصوص دلیل مشکل، مشکل پیچیده‌تر هم شد و زوایای تاریکی را نشان داد :/، در یک سری کشورها کار می‌کرد و در برخی کشورها کار نمی‌کرد!!

من به این باگ‌ها می‌گویم باگ‌های جهنمی یا شاید هم خجالتی! چون به سادگی نمی‌شود شرایط ایجادش را مهیا کرد. به همین دلیل پیدا کردن منشأ آن کار بسیار دشواری است و باید تمام حالت‌های ممکن و نا‌ممکن را در خصوص زمینه ایجاد باگ در نظر گرفت.

بدتر از همه، بعد از خطایابی نمی‌شود مطمئن شد که باگ برای همیشه برطرف شده است یا خیر! چون همه چیز بر اساس احتمال استوار است! طراح حرفه‌ای و هوشمند شخصی است که قادر است چنین خطاهایی را ردیابی و برطرف کند.

اما واقعاً چطور می‌شود این دسته خطاها را ردیابی کرد؟ سعی می‌کنم چند پارامتری را که فکر می‌کنم در پیدا کردن این گونه خطاها مؤثر هستند را بررسی کنم.

 

سعی کنید باگ را ببینید!

هنگام خطایابی لازم است باگ را ببینید

اولین و بهترین قدم برای شروع خطایابی است، ایجاد شرایط به این امید که دستگاه در محیط آزمایشگاهی باگ را بروز دهد. اگر موفق شوید چنین کاری را انجام دهید یک باگ جهنمی را به باگ مهربان تبدیل کرده‌اید. و مهم‌ترین اصل در این روش این است که آزمایش تکرارپذیر باشد.

یعنی هروقت، دما در فلان درجه سانتیگراد باشد یا فلان ورودی وضعیت بهمان را داشته باشد، شاهد بروز باگ خواهیم بود. اگر چنین اتفاقی افتاد، باید بسیار خوشحال باشید چرا که به سادگی می‌توان یک باگ معمولی را حل کرد و تست کرد که دیگر تکرار نشود.

اما همیشه چنین راه‌حلی خوب پیش نمی‌رود. یا اصلاً امکان ایجاد شرایط در محیط آزمایشگاه فراهم نیست. مثلاً دستگاهی که من داشتم، در سرتاسر ایران به خوبی کار می‌کرد و امکان ایجاد شرایط خارج از کشور هم متصور نبود. و یا آن دستگاهی که در تابستان به خوبی کار نمی‌کرد، با قرار دادن دستگاه در فر و بالا بردن دمای آن متناسب با دمای محیط بهره برداری و اعمال ورودی‌های مناسب همچنان مشکل قابل مشاهده نبود. آنگاه چه؟!

چکار باید کرد؟

 

به خودتان هم شک داشته باشید.

در خطایابی مهم است به همه چیز شک داشته باشید.

برای این که بتوانید در پیدا کردن منشأ یک مشکل موفق باشید، باید به تمام ممکن‌ها و ناممکن‌ها شک داشته باشید و هیچ احتمالی را مگر به شرط بررسی آن از لیست خارج نکنید. سپس بر اساس احتمال‌های ممکن آنها رو اولویت بندی کنید. از بالاترین اولویت‌ها شروع به بررسی حالت‌های ممکن بپردازید. بارها برای خود من پیش آمده است که مشکل از بی ربط‌ترین احتمال ممکن بوده باشد. برای همین تاکید می‌کنم که هیچ احتمالی رو حذف نکنید تا شگفت زده نشوید.

برای هر احتمال روش تستی داشته باشید که مطمئن شوید عملکرد درستی دارد! مثلاً اگر قرار است عملکرد پورت سریال را بررسی کنید رشته ثابتی را ارسال کنید و با اتصالات مورد استفاده در پروژه همان رشته را باید در سیستم مانیتورینگ (مثلاً کامپیوتر) دریافت کنید.

سعی کنید اول احتمال‌های سخت افزاری رو بررسی کنید و بعد به سراغ نرم افزار بروید. یعنی مثلاً اگر ماژول SD کار نمی‌کند، اول تغذیه و ارتباط پین به پین رو چک کنید و حتماً از اتصال آنها مطمئن شوید، بعد به سراغ موارد نرم افزاری بروید. مثلاً سرعت کلاک SPI و یا صحت از صفر و یک شدن پایه‌ها و همه چیز را مو به مو بررسی کنید، هر چقدر هم که بدیهی به نظر برسد! تا مشکل را پیدا کنید.

بگذارید با یک مثال که اخیراً اتفاق افتاده، موضوع را مقداری روشن‌تر کنم. دستگاهی داشتم که از ماژول GSM (نکات مهم در طراحی برد بر اساس GSM) برای ارسال یک سری اطلاعات استفاده می‌کرد. دستگاه به محض این که سعی در کانکت شدن به سرور داشت ریست می‌شد :|، گاهی هم بدون مشکل کار می‌کرد حتی روزها ولی در برخی مواقع هم به محض اتصال به اینترنت ریست می‌شد.

اولین و قوی‌ترین احتمال قسمت تغذیه مدار بود. چرا که هنگام تبادل جریان کشی‌های لحظه‌ای وجود دارد و اگر نتوانیم کاهش ولتاژ را جبران کنیم دستگاه ریست خواهد شد. دلیل این که گاهی هم ریست نمی‌شود احتمالاً کیفیت سیگنال شبکه است. وقتی شبکه پوشش خوبی داشته باشد جریان کمتری مورد نیاز است. سه روز تمام به بررسی این احتمال گذشت و مشکل حل نشد.

اما مشکل در بی ربط‌ترین جای ممکن یافت شد. فلان رجیستر حافظه فلش یک نمی‌شود و موقع خواندن بافری آورفلو می‌کند و ریست می‌شود. واقعاً هم به کیفیت شبکه مرتبط است وقتی کیفیت شبکه خوب باشد تمام تلاش‌ها برای اتصال به سرور موفقیت‌آمیز هستند و وقتی شبکه ضعیف است ممکن است ارتباط قطع شود و نیاز است داده بر روی حافظه فلش ذخیره شود.

این مثال به خوبی نشان می‌دهد که در خطایابی نباید هیچ احتمالی را کنار گذاشت حتی بی ربط‌ترین احتمال‌ها را.

 

اگر باگ به آزمایشگاه نمی‌آید، آزمایشگاه را پیش باگ ببرید!

اگر با فراهم کردن شرایط محیطی در آزمایشگاه موفق به مشاهده باگ نشدید، بهتر است وسایل مورد نیاز را بردارد و در محل بهره برداری حاضر شوید به امید خطایابی و شکار باگ! اگر خوش شانس باشید زیاد معطل نخواهید شد و باگ خودش را نشان خواهد داد. در این شرایط سعی کنید از هر چیزی که اهمیت دارد نمونه برداری کنید وضعیت ورودی و خروجی‌ها را چک کنید. از عملکرد مدار مطمئن شوید با ولتاژ گیری قسمت‌های مختلف ببینید آیا ولتاژها در بازه‌ای هستند که انتظار دارید یا نه!

ممکن است تمام این نکات بدیهی به نظر برسد، اما پیداکردن هر سرنخ کوچک و بی اهمیتی به حل مسئله کمک کند.

برای نمونه با حضور در محل بهره برداری آن دستگاهی که در تابستان کار نمی‌کرد و با ولتاژ گیری قسمت‌های مختلف مشخص شد قسمت تقویت سیگنال آنالوگ درست کار نمی‌کند. در حالی که اول فکر می‌کردم از خرابی امپ یا یکی از خازن مقاومت‌ها باشد، ولی بعد کاشف به عمل آمد به‌خاطر رطوبت هواست که تأثیر نامطلوبی بر روی عملکرد دستگاه دارد و مشکل با یک اسپری پلاستیک حل شد.

 

فکر می‌کنم اگر این نکات خیلی بدیهی و پایه‌ای رو برای خطایابی و پیدا کردن ریشه یک مشکل انجام بدهید، هیچ مشکلی نباشد که نتوانید خطایابی کنید. این مقاله صِرف یادآوری گام‌هایی است که احتمالاً همه میدانیم باید انجام بدهیم، ولی در شرایطی فراموششان می‌کنیم و سر درگم می‌شویم!

انتشار مطالب با ذکر نام و آدرس وب سایت سیسوگ، بلامانع است.

شما نیز میتوانید یکی از نویسندگان سیسوگ باشید.   همکاری با سیسوگ

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

17 دیدگاه در “باگ های جهنمی را چطور خطایابی کنیم!

  1. نیما گفت:

    مشکلی که اخیرا برای من پیش آمده این بود که برد و برنامه ای که دوسالی هست دارم ازش میزنم و استفاده میکنم، وارد وقفه DMA مربوط به قرائت ADC نمیشد!!
    اول به میکرو شک کردم و نزدیک بود دوتا میکروی یک میلیونی رو بندازم دور!!
    بعد تر متوجه شدم میکروها فقط رو اون برد خاص مشکل دارن و جالبتر اینکه با مونتاژ برد دیگه ای که همراه همون برد خراب ساخته شده بود و با همون سری قطعات خرید شده همون میکروهای درست کار کردن:|

    1. Zeus . گفت:

      متشکرم دوست عزیز که تجربتون رو با ما به اشتراک گذاشتید
      الان با این قیمت های میکروکنترلر دیگه نمیشه اول حتی به میکرو هم شک کرد.

  2. محمد طیبی گفت:

    گاهی در حین طراحی فراموش می کنیم گام های مشخص منطقی را برداریم هرچند در ذهنمان داریم. در اینطور مواقع توضیح مراحل کار و منطق طراحی برای یک شخص دیگر از روی کار انجام شده مفید است.
    شما توضیح می دهید و متوجه می سوید نایی را خودتان طبق منطقی کا در حال شرحش هستید پیش نرفته اید.

    1. Zeus . گفت:

      😐 ببخشید من متوجه نشدم منظور شما نشدم !!!

      1. محمد طیبی گفت:

        برای من چند بار پیش امده که منطق طراحی رو در ذهنم دارم اما درست پیاده نکردم. هر بار که مدارو چک می گنم هم متوجه اشتباه خودم نمیشم. فقط وقتی متوجه میشم که دوباره به یک نفر دیگه با صدای بلند توضیح میدم مدارم چطور کار می کنه. اونجاست متوجه میشم که یک جایی رو اشتباه طراحی کردم ولی از زبر چشمم در میرفته

        1. Zeus . گفت:

          میدونی من این حالت رو وقتی تجربه میکنم که مدت زمان زیادی تمرکز کردم برای حل باگ و اون چیز بدیهی از ذهنم دور میمونه (احتمالا به دلیل خستگی) که مثلا اگر برای اون روز ادامه ندم و فردا برگردم خیلی سریع مشکل رو میبینم
          و برام سوال میشه چرا دیروز ندیدمش – نکته خیلی خوبی رو اشاره کردید، متشکرم

  3. Esmail.dadkhah Esmail.dadkhah گفت:

    سلام نمی دونستم چطوری براتون پیام بزار اینجا می نویسم.
    این هفته فرکانس برق شهری به شدت افت داشت.من عدد 49.65 را ثبت کردم. ساعت 11.45 شب نجف اباد وقتی که حتی اصفهان توی خاموشی بود.
    این امار هم گفته های من را اثبات می کنه.
    https://www.igmc.ir/Power-grid-status-report
    به نظر شما این مشکل می تونه برای تجهیزات مشکل ایجاد کنه.
    در ضمن در سال 82 به همین شکل شبکه توزیع برق ایران فروپاشید.
    آیا ممکنه دوباره این اتفاق بیفته
    ***************************************************************
    ***این خبر مربوط به سال 1390 که به حادثه 1382 اشاره می کنه*-*
    https://www.tabnak.ir/fa/news/172761/%D9%87%D8%B4%D8%AF%D8%A7%D8%B1-%D9%86%DA%A9%D9%86%D8%AF-%D8%AE%D8%A7%D9%85%D9%88%D8%B4%DB%8C-%D9%87%D8%A7%DB%8C-%D9%81%D8%B1%D9%88%D8%B1%D8%AF%DB%8C%D9%86-82-%D8%AA%DA%A9%D8%B1%D8%A7%D8%B1-%D8%B4%D9%88%D8%AF
    با این همه، قطع گازرسانی به نیروگاه های اصلی کشور همانند نیروگاه قم، عسلویه، آبادان و خرمشهر، علاوه بر بروز خاموشی های مقطعی، امکان ایجاد یک خاموشی گسترده در سطح شبکه سراسری کشور همانند آنچه در فروردین سال ۸۲ اتفاق افتاد را نیز می تواند فراهم نماید.
    ************************************************************************
    لطف می کنید در این مورد یه مقاله کاری بنوسید. ممنون

    1. Zeus . گفت:

      سلام دوست عزیز اگه اون اتفاق تکرار بشه که فاجعه است – فاجعه تمام عیار دوستی تعریف میکرد تنها یک یا دو نیروگاه در کشور داریم که در موقع قطع کامل مکان راه اندازی دارن – اون سال هم اگر اون نیروگاه ها نبودن فاجعه میشد
      ولی من تخصص زیادی در خصوص برق قدرت ندارم – از دوستان میپرسم ببینم چیزی دستگیرم میشه یا نه – اگر شد مقاله ای در خصوصش می نویسم

      1. esmail.dadkhah گفت:

        بسیار سپاسگزارم

  4. علی گفت:

    سلام و درود
    واقعا لذت بردم مطلب قشنگی بود منو میبرد به زمانهایی که ساعتها در گیر باگهای سیستم بودم و نا امید
    ولی بعد از شاید هزاران رفع باگ به یک چیز مطمئن شدم دیگری چیزی وجود ندارد که من نتوانم بر طرفش کنم حتی روزها اگر طول بکشه ولی حتما برطرف میشه و این ایمان جدیدا به برطرف کردن راحتر باگها خیلی کمک من بوده
    بازم ممنون از مطالب فوق العادتون

    1. Zeus . گفت:

      سلام و درود بر شما
      واقعا بعضی باگ ها پیداکردنشون خیلی خیلی سخت تر از حل کردنشونه، مثل همین باگ اخری ولی خوب با تلاش و زمان گذاشتن و تمرکز کردن مشکلی نیست که حل نشود.
      متشکرم برای انرژی مثبتی که دادید.

  5. محمد گفت:

    سلام
    خیلی مقاله مفیدی بود ممنونم
    من هم یک موردی که اخیرا برام پیش اومده و هنوز نتوستم حلش کنم رو میگم شاید کسی بتونه کمک کنه
    یک برد زدم که روش ای سی شبکه داره و موقع کار کردن هم کمی داغ میکنه که طبیعی هست…این برد جنسش فایبر هست و زیر ای سی هم زمین رو پلیگان کردم و چندتا هم ویا زدم و از زیر هم زمین رو پخش کردم که به خوبی حرارت ای سی رو دفع میکنه و موقع کار کل برد تقریبا گرم میشه و خنک کاری انجام میشه
    دقیقا همون برد رو با چاپ محافظ(چاپ سبز) زدم ولی سرعت شبکه به شدت افت میکنه، وقتی یک فن میزارم به سمت برد درست میشه….
    راه های زیادی رو تست کردم یکم بهتر شد ولی بازهم سرعت افت میکنه..
    مثلا هیت سینک گذاشتم..ای سی رو برداشتم و چاپ محافظ زیر ای سی رو با تیغ تراشیدم همچنین چاپ محافظ لایه پشت زیر ای سی رو هم تراشیدم و قلع اندود کردم …
    این هم بگم که بعد این کارها بازهم کل برد مثل اون برد بدون چاپ محافظ گرم نمیشه و مشخصه حرارت تو کل برد پخش نمیشه

    یعنی کلا چاپ محافظ رو بیخیال باید بشم؟؟؟

    1. Zeus . گفت:

      متشکرم دوست عزیز
      این مشکلی که میگید یه مقدار عجیبه برام – مگه از آیسی شبکه ای استفاده میکنید که اینقدر داغ میکنه ؟!من تاحالا چنین تجربه ای نداشتم در خصوص داغ کردن آیسی شبکه
      بعد داغ میکنه دما چقدر میشه ؟

      1. محمد گفت:

        خیلی ممنونم از پاسختون
        خداروشکر مشکل حل شد و اینجوری که به نظر میاد مشکل از ای سی شبکه بود
        با تعویض ای سی شبکه درست شد
        من حدود 12 عدد از این ای سی از یک فروشگاه گرفتم و تا الان 7 تاشون رو استفاده کردم و این یکی اینجوری شد..
        ممکنه بین ای سی ها یکی تقلبی باشه یا حین مونتاژ عیب دارش کردم؟

        1. Zeus . گفت:

          سلام دوست عزیز
          خوشحالم که مشکل رو پیدا کردید
          ممکنه آیسی اورجینال نبوده باشند و درصدی خرابی توی پارت هایی که غیر اورجینال هستند وجود داره
          تعجب کردم گفتید داغ میکنه آیسی شبکه واقعا

          1. محمد گفت:

            راهی برای تشخیص اورجینال بودن نیست؟
            یعنی باید مونتاژ بشه و تو مرحله کنترل کیفیت متوجه این مشکل شد؟