QRing: טבעת למשול בם ולאתרם

פרויקט עם ארדואינו, קוד פייתון במחשב, הדפסה בתלת-ממד ועוד דברים טובים, שעוזר לקטלג ולאתר קצת יותר בקלות רכיבים (וכל דבר אחר שקשה לזהות במבט חטוף אבל יש עליו ברקוד)

משדר המערכת בפעולה מול ברקוד

עם השנים צברתי הרבה שקיות של Digikey, Mouser ועוד, עם נגדים, קבלים ושאר רכיבי SMD זעירים. כולן נראות אותו הדבר, ורק הכיתוב על המדבקה – בפונט קטן ומעצבן – יכול לומר לי מה יש בפנים. לכן, חיפוש של רכיב ספציפי יכול להיות עסק מתיש. אפשר כמובן לכתוב בטוש עבה על כל שקית מה יש בתוכה, וזה יעזור אם אני מחפש, נניח, נגד 1K. אבל מה אם אני צריך למצוא קבל מדגם ספציפי מאוד, שמתאים למתח מסוים ועם טולרנס מסוים וכו' – אם אנסה לכתוב את כל הפרטים האלה על השקית, זה כבר יהיה יותר גרוע מהמדבקה.

זה, בכל אופן, היה התירוץ הלא-משכנע שלי לבנות את QRing – מערכת קוראת ברקודים, עם יחידת שידור אלחוטית שקל לנייד ברחבי חדר העבודה, ותוכנה במחשב שתקלוט את המידע, תבצע את החיפוש וההתאמה הדרושים ותודיע לי כאשר הברקוד – ובעקבותיו הרכיב הנכון – נמצאו.

החומרה מבוססת כמובן על המודול GM60 סורק הברקודים הקטנטן שהצגתי כאן לאחרונה. המודול עובד במתח 3.3V, שמתאים גם למשדר/מקלט HC-11 החביב עליי. אז אחרי שהגדרתי פרמטרים תואמים לשתי יחידות HC-11, חיברתי אחת מהן ואת ה-GM60 אל מייצב מתח פשוט מדגם MCP1700-3302E שניזון מסוללת 16340 נטענת, חיברתי את ה-TX של הסורק ל-RX של המשדר, והאלקטרוניקה של החלק הראשון של הפרויקט הייתה מוכנה. אבל כדי שאוכל לעבוד עם זה בשטח, ושזה יהיה נוח יותר מאשר קורא ברקודים רגיל שצריך להחזיק ביד וללחוץ על הכפתור, הרכבתי את הכול על "טבעת" שעיצבתי ב-Tinkercad ושלקחה למדפסת התלת-ממד שלי ארבע שעות וחצי. לא אביזר אופנתי או מעודן במיוחד, אבל עושה את העבודה ולא צריך להניח אותו בצד כשפותחים ארגזים ושולפים שקיות. למעשה, אם ממש רוצים, אפשר אפילו להקליד או לכתוב כשהטבעת הזו על האצבע.

דגם ה"טבעת" ב-Tinkercad
דגם ה"טבעת" ב-Tinkercad

בצד המחשב, חשבתי בהתחלה לחבר מתאם USB-to-UART שיעביר את המידע מה-HC-11 הקולט. יש לי אפילו מדריך לתקשורת סריאלית בפייתון. אך אז נזכרתי בלוח ארדואינו מיקרו סיני שיושב אצלי במגירה, שיכול לדמות מקלדת USB, והחלטתי להשתמש בו במקום. כרגיל, יש יתרונות וחסרונות לשתי הגישות.

הטבעת לקראת סיום ההדפסה
הטבעת לקראת סיום ההדפסה

תוכנית הפייתון במחשב תבקש ממני, קודם כל, להקליד את מילות המפתח הרלוונטיות לחיפוש הנוכחי, למשל "1uF". אחרי זה היא תקבל (כך או אחרת) את המחרוזות שסורק הברקודים ישדר, ותחפש אותן בטבלה שהכנתי מבעוד מועד. כל שורה בטבלה כוללת את הברקוד (שיכול להיות ארוך מאוד, למשל קודי QR שמוצאים על שקיות רכיבים) ואת הפירוט של מה שהוא מסמל. את זה אני צריך לכתוב לבד, בסגנון "resistor,100K,0805,1%". אם תהיה (או לא תהיה) התאמה בין מילות המפתח לבין תיאור הפריט, התוכנית תיתן פידבק מיידי.

הטבעת האחת, מוכנה לסריקה! כן, אפשר ליצור משהו עוד יותר קומפקטי
הטבעת האחת, מוכנה לסריקה! כן, אפשר ליצור משהו עוד יותר קומפקטי

כשאני מחטט בארגז עם שקיות וסורק אותן, כנראה לא ארצה להסתכל כל פעם על המסך: עדיף שהמשוב יהיה קולי. בעזרת כלי TTS (טקסט-לדיבור) אונליין יצרתי שני קובצי MP3, אחד שאומר "No" ואחד שאומר "Target found". בפייתון קל מאוד להשמיע קובצי MP3: מתקינים את הספריה playsound (עם הפקודה pip install playsound ב-CMD), בתחילת הקוד כותבים import playsound, ואיפה שצריך את הסאונד עצמו כותבים פקודה כמו

playsound.playsound('NO.mp3', False)

בבדיקות מקדימות עליתי על מספר בעיות. ראשית, העדפתי שמהירות השידור תהיה מקסימלית כמובן, אך הסתבר שב-115200 באוד זה יותר מדי בשביל ה-HC-11, והמידע הגיע משובש גם מטווח קצר. ייתכן שאם הייתי מעביר את המודולים למצב "תגובה מהירה" (FU3) זה היה עוזר, אבל זה גם היה מבזבז לי סתם את הסוללה במשדר כשאין שידור, אז ירדתי ל-57600 באוד.

שנית, כשהקוד לארדואינו היה ממש פשוט (רק שולח דרך אובייקט Keyboard כל תו שמתקבל מ-Serial1), מחרוזות ארוכות נקטעו. הנחתי שהסיבה היא שהכתיבה איטית יותר מהקריאה, והתווים הנכנסים מצטברים ב-buffer הפנימי עד שהוא עולה על גדותיו ודברים מתחילים להתפספס. אפשר לשנות את גודל ה-buffer בקוד המקור של ספריות ארדואינו, אבל זה ישפיע על כל תוכניות הארדואינו האחרות שאקמפל וייצור בעיות מסוגים אחרים בהמשך. במקום זה יצרתי buffer תווים משלי, בגודל 1000 בייטים, ושלחתי אותו במלואו רק שעבר מספיק זמן מאז התו האחרון שנקלט.

גם זה לא תמיד עבד: כעת הבחנתי בברקודים (אחרים) שרק התווים הראשונים שלהם הגיעו למחשב. בדיבוג קצת יותר מדוקדק זיהיתי שהם מכילים תווים שאינם ניתנים להצגה, למשל תו ASCII מספר 30, ושזה שיגע קצת את האובייקט Keyboard. הוספתי תנאי שלא מכניס ל-buffer תווים שקטנים מ-32 (רווח), אבל אז המחשב לא קיבל את תווי סוף השורה (13 ו-10) מהסורק. הוספתי אותם "ידנית" לקצה ה-buffer מיד לפני השידור, והעניין סודר.

הבעייה הרביעית, שאותה אי אפשר לפתור עם שינויים בקוד, היא שה-GM60 צריך די הרבה אור. ברקודים שנקלטו בקלות בחדר מואר באור שמש (לא ישיר) לא תמיד נקלטו באור נורות, אף על פי שהוא היה חזק יחסית.

למען האמת, גם כשהאור מספיק, הסריקה לא מיידית, ובזמן שעובר עד שאני מצליח לסרוק את הקוד ולקבל את המשוב כנראה הייתי מספיק כבר לסובב את השקית ולקרוא את הטקסט מהמדבקה. אבל למערכת הסריקה יש יתרון משמעותי כשמחפשים יותר מרכיב יחיד. למשל, אם צריך עשרה דגמי נגדים וקבלים שונים בשביל להרכיב איזשהו לוח, יהיה קשה לזכור את כולם בעל-פה. אז במקום לעבור על כל השקיות פעמיים או שלוש, אפשר לבנות את התוכנה בצד המחשב כך שתקבל כמה קבוצות של מילות מפתח, קבוצה אחת לכל רכיב דרוש, ותחפש את כולן בכל פעם שמגיע ברקוד חדש.

את פרטי הרכיבים מהשקיות שלי אני מזין פעם אחת לתוך קובץ CSV באקסל (אפשר להשתמש בטבעת כדי "להקליד" את הברקודים לתוך התאים, כאילו השתמשתי במקלדת – זה אחד היתרונות של השימוש בארדואינו במקום בחיבור סריאלי רגיל). קוד הפייתון המאולתר-מאוד שלי קורא את הקובץ הזה, וכן קובץ נוסף עם פרטי החיפוש הספציפי. למה בקובץ נפרד ולא בהקלדה לתוכנית עצמה? מן הסתם אוסיף את אופציית ההקלדה בהמשך, אך סביר להניח שיהיו משימות חיפוש של יותר מרכיב אחד שיחזרו על עצמן, ואז עדיף לשמור אותן בצד גם לפעם הבאה במקום להקליד הכול מחדש.

סרטון הסבר והדגמה של הפרויקט, באנגלית:

להרשמה
הודע לי על
0 Comments
Inline Feedbacks
הראה את כל התגובות