හැමෝටම ආයුබෝවන්.
අපි, Victor Antipov සහ Ilya Aleshin, Python PyUSB හරහා USB උපාංග සමඟ වැඩ කිරීමේ අපගේ අත්දැකීම් සහ ප්‍රතිලෝම ඉංජිනේරු විද්‍යාව ගැන ටිකක් කතා කරන්නෙමු.
මුදලටය
2019 දී, රුසියානු සමූහාණ්ඩුවේ රජයේ නියෝගය අංක 224 “හඳුනාගැනීමේ මාධ්‍යයන් සමඟ දුම්කොළ නිෂ්පාදන ලේබල් කිරීම සඳහා වන නීති රීති අනුමත කිරීම සහ හඳුනාගැනීමේ මාධ්‍යයන් සමඟ අනිවාර්ය ලේබල් කිරීමකට යටත්ව භාණ්ඩ සංසරණය අධීක්ෂණය කිරීම සඳහා රාජ්‍ය තොරතුරු පද්ධතියක් ක්‍රියාත්මක කිරීමේ විශේෂාංග දුම්කොළ නිෂ්පාදන සම්බන්ධයෙන්” බලාත්මක විය.
1 ජූලි 2019 වන දින සිට නිෂ්පාදකයින් විසින් සෑම දුම්කොළ පැකට්ටුවක්ම ලේබල් කිරීමට අවශ්ය බව ලේඛනය පැහැදිලි කරයි. විශ්ව හුවමාරු ලේඛනයක් (UDD) ක්‍රියාත්මක කිරීමත් සමඟ සෘජු බෙදාහරින්නන් මෙම නිෂ්පාදන ලබා ගත යුතුය. ගබඩා, අනෙක් අතට, මුදල් ලේඛනය හරහා ලේබල් නිෂ්පාදන විකිණීම ලියාපදිංචි කිරීමට අවශ්ය වේ.
එසේම, 1 ජූලි 2020 සිට, ලේබල් නොකළ දුම්කොළ නිෂ්පාදන සංසරණය තහනම් වේ. මෙයින් අදහස් කරන්නේ සියලුම සිගරට් ඇසුරුම් විශේෂ Datamatrix තීරු කේතයකින් සලකුණු කළ යුතු බවයි. එපමණක් නොව - වැදගත් කරුණක් - Datamatrix සාමාන්‍ය නොවන නමුත් ප්‍රතිලෝම නොවන බව පෙනී ගියේය. එනම්, සුදු මත කළු කේතය නොව, අනෙක් අතට.
අපි අපගේ ස්කෑනර් යන්ත්‍ර පරීක්ෂා කළ අතර, ඒවායින් බොහොමයක් ප්‍රබෝධමත්/නැවත පුහුණු කළ යුතු බව පෙනී ගියේය, එසේ නොමැතිනම් ඔවුන්ට මෙම තීරු කේතය සමඟ සාමාන්‍යයෙන් ක්‍රියා කිරීමට නොහැකි වේ. මෙම සිදුවීම් හැරීම අපට දැඩි හිසරදයක් සහතික කළේය, මන්ද අපගේ සමාගමට විශාල භූමි ප්‍රදේශයක් පුරා විසිරී ඇති වෙළඳසැල් රාශියක් ඇත. මුදල් රෙජිස්ටර් දස දහස් ගණනක් - සහ ඉතා සුළු කාලයක්.
කළ යුතුව තිබුණේ කුමක්ද? විකල්ප දෙකක් තිබේ. පළමුව: ස්ථානීය ඉංජිනේරුවන් විසින් ස්කෑනර් යන්ත්‍ර ශ්‍රමිකව ප්‍රබෝධමත් කර සකස් කරයි. දෙවනුව: අපි දුරස්ථව වැඩ කරන අතර, වඩාත් සුදුසු වන්නේ, එක් පුනරාවර්තනයකදී එකවර බොහෝ ස්කෑනර් ආවරණය කිරීමයි.
පළමු විකල්පය, පැහැදිලිවම, අපට සුදුසු නොවේ: අපි සංචාරය කරන ඉංජිනේරුවන් සඳහා මුදල් වියදම් කිරීමට සිදු වනු ඇත, සහ මෙම නඩුවේ ක්රියාවලිය පාලනය කිරීම සහ සම්බන්ධීකරණය කිරීම අපහසු වනු ඇත. නමුත් වැදගත්ම දෙය නම්, මිනිසුන් වැඩ කරනු ඇත, එනම්, අපට බොහෝ දෝෂ ඇති විය හැකි අතර, බොහෝ විට, නියමිත කාලය සපුරා නොගැනීමයි.
දෙවන විකල්පය එක් දෙයක් සඳහා නොවේ නම්, සෑම කෙනෙකුටම හොඳයි. සමහර වෙළෙන්දන්ට අවශ්ය සියලුම මෙහෙයුම් පද්ධති සඳහා අපට අවශ්ය දුරස්ථ ෆ්ලෑෂ් කිරීමේ මෙවලම් තිබුණේ නැත. අනික ඩෙඩ්ලයින් ඉවර වෙන නිසා මට ඔලුවෙන් හිතන්න උනා.
මීළඟට, අපි Debian 9.x OS සඳහා අතින් ගෙන යා හැකි ස්කෑනර් සඳහා මෙවලම් සකස් කළ ආකාරය අපි ඔබට කියමු (අපගේ සියලුම මුදල් රෙජිස්ටර් Debian මත ඇත).
ප්‍රහේලිකාව විසඳන්න: ස්කෑනරයක් ෆ්ලෑෂ් කරන්නේ කෙසේද
වික්ටර් ඇන්ටිපොව් වාර්තා කරයි.
වෙළෙන්දා විසින් සපයන ලද නිල උපයෝගීතාව වින්ඩෝස් යටතේ ක්‍රියා කරයි, සහ IE සමඟ පමණි. උපයෝගීතාවයට ස්කෑනරය ෆ්ලෑෂ් කර වින්‍යාසගත කළ හැකිය.
අපගේ ඉලක්ක පද්ධතිය Debian බැවින්, අපි Debian මත usb-redirector server එකක් සහ Windows මත usb-redirector client එකක් ස්ථාපනය කළෙමු. usb-redirector utilities භාවිතා කරමින්, අපි ස්කෑනරය Linux යන්ත්‍රයකින් Windows යන්ත්‍රයකට යොමු කළෙමු.
වින්ඩෝස් වෙළෙන්දෙකුගේ උපයෝගිතා ස්කෑනරය දුටු අතර එය සාමාන්‍ය ලෙස දැල්වීය. මේ අනුව, අපි පළමු නිගමනය කළා: කිසිවක් මෙහෙයුම් පද්ධතිය මත රඳා නොපවතී, එය දැල්වෙන ප්රොටෝකෝලය පිළිබඳ කාරණයකි.
හරි. අපි වින්ඩෝස් යන්ත්‍රයේ ෆ්ලෑෂ් කිරීම ධාවනය කර, ලිනක්ස් යන්ත්‍රයේ ඩම්ප් ඉවත් කළෙමු.
අපි ඩම්ප් එක WireShark තුළට පුරවා ... දුකට පත් විය (මම කුණු කසළේ සමහර විස්තර මඟ හරිමි, ඒවා කිසිදු උනන්දුවක් නොදක්වයි).
කුණු කන්ද අපට පෙන්වූ දේ:
Wireshark විසින් විනිශ්චය කරන 0000-0030 ලිපිනයන් USB සේවා තොරතුරු වේ.
අපි 0040-0070 කොටස ගැන උනන්දු විය.
MOCFT අක්ෂර හැර එක් සම්ප්‍රේෂණ රාමුවකින් කිසිවක් පැහැදිලි නොවීය. මෙම අක්ෂර ස්ථිරාංග ගොනුවේ අක්ෂර මෙන්ම රාමුවේ අවසානය දක්වා ඉතිරි අක්ෂර බවට පත් විය (ස්ථිරාංග ගොනුව උද්දීපනය කර ඇත):
fd 3e 02 01 fe යන සංකේත වලින් අදහස් කළේ කුමක්ද, Ilya වැනි මට පුද්ගලිකව අදහසක් නොතිබුණි.
මම පහත රාමුව දෙස බැලුවෙමි (සේවා තොරතුරු මෙහි ඉවත් කර ඇත, ස්ථිරාංග ගොනුව උද්දීපනය කර ඇත):
පැහැදිලි වූයේ කුමක්ද? පළමු බයිට් දෙක යම් ආකාරයක නියත බව. සියලුම පසුකාලීන කොටස් මෙය තහවුරු කළේය, නමුත් සම්ප්‍රේෂණ වාරණ අවසන් වීමට පෙර:
නියතය වෙනස් වී ඇති බැවින් (උද්දීපනය කර ඇත) සහ අමුතු තරම්, ගොනුවේ කොටසක් තිබූ බැවින් මෙම රාමුව ද මෝඩ විය. ගොනුවේ මාරු කළ බයිට් ප්‍රමාණයෙන් පෙන්නුම් කළේ බයිට් 1024 ක් මාරු කර ඇති බවයි. ඉතිරි බයිට් වලින් අදහස් කරන්නේ කුමක්දැයි මම නැවතත් නොදනිමි.
පළමුවෙන්ම, පැරණි BBS අන්වර්ථ නාමයක් ලෙස, මම සම්මත සම්ප්‍රේෂණ ප්‍රොටෝකෝල සමාලෝචනය කළෙමි. ප්රොටෝකෝලය බයිට් 1024ක් සම්ප්රේෂණය කර නැත. මම දෘඩාංග අධ්‍යයනය කිරීමට පටන් ගත් අතර 1K Xmodem ප්රොටෝකෝලය හමු විය. එය 1024 සම්ප්රේෂණය කිරීමට ඉඩ දී ඇත, නමුත් අවවාදයක් සහිතව: පළමුව 128 ක් පමණි, සහ දෝෂ නොමැති නම් පමණක්, ප්රොටෝකෝලය සම්ප්රේෂණය කරන ලද බයිට් ගණන වැඩි කළේය. මම වහාම බයිට් 1024 ක් මාරු කළා. මම සම්ප්‍රේෂණ ප්‍රොටෝකෝල අධ්‍යයනය කිරීමට තීරණය කළෙමි, විශේෂයෙන් X-මොඩමය.
මොඩමයේ වෙනස්කම් දෙකක් විය.
පළමුව, CRC8 සහාය ඇති XMODEM පැකේජ ආකෘතිය (මුල් XMODEM):
දෙවනුව, CRC16 සහාය ඇති XMODEM පැකට් ආකෘතිය (XmodemCRC):
SOH, පැකේජ අංකය සහ CRC සහ පැකේජ දිග හැර එය සමාන බව පෙනේ.
මම දෙවන සම්ප්‍රේෂණ වාරණයේ ආරම්භය දෙස බැලුවෙමි (සහ නැවතත් ස්ථිරාංග ගොනුව දුටුවෙමි, නමුත් දැනටමත් බයිට් 1024 කින් ඉන්ඩෙන්ට් කර ඇත):
මම හුරුපුරුදු ශීර්ෂය fd 3e 02 දුටුවෙමි, නමුත් ඊළඟ බයිට් දෙක දැනටමත් වෙනස් වී ඇත: එය 01 fe, සහ 02 fd බවට පත් විය. දෙවන කොටස දැන් අංක 02 ලෙස සටහන් කර ඇති බව මම දුටුවෙමි, එය තේරුම් ගත්තේ ය: මා ඉදිරිපිට සම්ප්‍රේෂණ වාරණයේ අංකනය විය. පළමු 1024 ගියර් 01, දෙවැන්න 02, තෙවැන්න 03 සහ එසේ ය (නමුත් හෙක්ස්, ඇත්ත වශයෙන්ම). නමුත් fe සිට fd දක්වා වෙනස් වීමෙන් අදහස් කරන්නේ කුමක්ද? ඇස් 1 කින් අඩු වීමක් දුටුවේය, ක්‍රමලේඛකයින් 0 නොව 1 සිට ගණන් කරන බව මොළය මතක් කර දුන්නේය. නමුත් පළමු වාරණ 1 සහ 0 නොවේ ඇයි? මෙම ප්‍රශ්නයට පිළිතුර මට තවමත් හමු වී නැත. නමුත් දෙවන කොටස ගණනය කරන්නේ කෙසේදැයි මට වැටහුණි. දෙවන කොටස FF - (අඩු) පළමු කොටසේ අංකයට වඩා වැඩි දෙයක් නොවේ. මේ අනුව, දෙවන කොටස = 02 (FF-02) = 02 FD ලෙස නම් කරන ලදී. පසුව කුණු කන්ද කියවීමෙන් මගේ අනුමානය තහවුරු විය.
එවිට සම්ප්රේෂණය පිළිබඳ පහත පින්තූරය මතු වීමට පටන් ගත්තේය:
සම්ප්රේෂණය ආරම්භය
fd 3e 02 - ආරම්භය
01 FE - සම්ප්‍රේෂණ කවුන්ටරය
මාරු කිරීම (බ්ලොක් 34, බයිට් 1024 මාරු කර ඇත)
fd 3e 1024 බයිට් දත්ත (බයිට් කුට්ටි 30 කට බෙදා ඇත).
සම්ප්රේෂණය අවසානය
fd 25
ඉතිරි දත්ත බයිට් 1024 ට පෙළගැස්විය යුතුය.
බ්ලොක් සම්ප්‍රේෂණ අවසන් රාමුව මොන වගේද:
fd 25 - බ්ලොක් සම්ප්රේෂණය අවසන් කිරීමට සංඥා. මීළඟ 2f 52 - ඉතිරි ගොනුව බයිට් 1024 දක්වා ප්‍රමාණයෙන්. 2f 52, ප්රොටෝකෝලය අනුව විනිශ්චය කිරීම, 16-bit CRC චෙක්සම් වේ.
පැරණි කාලය සඳහා, මම ගොනුවකින් බයිට් 1024ක් ඇද 16-bit CRC ගණනය කරන වැඩසටහනක් C වලින් සෑදුවෙමි. වැඩසටහන දියත් කිරීමෙන් පෙන්නුම් කළේ මෙය 16-bit CRC නොවන බවයි. නැවතත් මෝඩකම - දින තුනක් පමණ. මේ කාලය පුරාම මම උත්සාහ කළේ චෙක්සම් එකක් නොවේ නම් එය කුමක් විය හැකිද යන්න තේරුම් ගැනීමටයි. ඉංග්‍රීසි භාෂා අඩවි අධ්‍යයනය කරන අතරතුර, X-මොඩමය එහිම චෙක්සම් ගණනය කිරීම් භාවිතා කරන බව මම සොයා ගතිමි - CRC-CCITT (XModem). මම මෙම ගණනය කිරීමේ C ක්‍රියාත්මක කිරීම් කිසිවක් සොයා ගත්තේ නැත, නමුත් මම මෙම චෙක්සම් ඔන්ලයින් ගණනය කරන අඩවියක් සොයා ගත්තෙමි. මගේ ගොනුවේ බයිට් 1024 ක් වෙබ් පිටුවට මාරු කිරීමෙන් පසු, වෙබ් අඩවිය මට ගොනුවෙන් චෙක්සම් වලට සම්පුර්ණයෙන්ම ගැලපෙන චෙක්සම් එකක් පෙන්වීය.
හුරේ! අවසාන ප්‍රහේලිකාව විසඳා ඇත, දැන් මට මගේම ස්ථිරාංග සෑදීමට අවශ්ය විය. ඊළඟට, මම මගේ දැනුම (එය මගේ හිසෙහි පමණක් ඉතිරිව ඇත) ප්‍රබල මෙවලම් කට්ටලයක් වන පයිතන් ගැන හුරුපුරුදු ඉල්යාට ලබා දුන්නෙමි.
වැඩසටහනක් නිර්මාණය කිරීම
ඉල්යා ඇලේෂින් වාර්තා කරයි.
සුදුසු උපදෙස් ලැබුණු පසු, මම ඉතා "සතුටු" විය.
ආරම්භ කළ යුත්තේ කොතැනින්ද? ඒක හරි, මුල ඉඳන්ම. USB පෝට් එකෙන් ඩම්ප් එකක් ගැනීමෙන්.
USB-pcap දියත් කරන්න
උපාංගය සම්බන්ධ කර ඇති වරාය සහ අපි ඩම්ප් සුරකින ගොනුව තෝරන්න.
අපි ස්කෑනරය Windows සඳහා දේශීය EZConfigScanning මෘදුකාංගය ස්ථාපනය කර ඇති යන්ත්‍රයකට සම්බන්ධ කරමු.
එහි අපි උපාංගයට විධාන යැවීම සඳහා අයිතමය සොයා ගනිමු. නමුත් කණ්ඩායම් ගැන කුමක් කිව හැකිද? මට ඒවා ලබා ගත හැක්කේ කොතැනින්ද?
වැඩසටහන ආරම්භ වන විට, උපකරණ ස්වයංක්රීයව ඡන්ද විමසීමක් සිදු කරනු ලැබේ (අපි මෙය ටිකක් පසුව දකිනු ඇත). නිල උපකරණ ලේඛන වලින් පුහුණු තීරු කේත තිබුණි. පෙරනිමිය. මේ අපේ කණ්ඩායමයි.
අවශ්ය දත්ත ලැබී ඇත. wireshark හරහා dump.pcap විවෘත කරන්න.
EZConfigScanning ආරම්භ කරන විට අවහිර කරන්න. ඔබ අවධානය යොමු කළ යුතු ස්ථාන රතු පැහැයෙන් සලකුණු කර ඇත.
මේ සියල්ල පළමු වතාවට දකිද්දී මගේ හිතට දැනුනේ නැති විය. ඊළඟට හෑරීමට කොහෙද යන්න පැහැදිලි නැත.
ටිකක් මොළ කම්පනය සහ-සහ-සහ... ආහා! කුණු ගොඩේ පිටතට - ය inහා in එය පිටතට.
මම URB_INTERRUPT යනු කුමක්දැයි ගූගල් කළෙමි. මේක Data Transfer ක්‍රමයක් කියලා මම දැනගත්තා. සහ එවැනි ක්රම 4 ක් ඇත: පාලනය, බාධා කිරීම්, isochronous, bulk. ඔබට ඔවුන් ගැන වෙන වෙනම කියවිය හැකිය.
USB උපාංග අතුරුමුහුණතෙහි ඇති අන්ත ලක්ෂ්‍ය ලිපින “lsusb –v” විධානය හරහා හෝ pyusb භාවිතයෙන් ලබා ගත හැක.
දැන් අපි මෙම VID සහිත සියලුම උපාංග සොයා ගත යුතුයි. ඔබට විශේෂයෙන් VID:PID මගින් සෙවිය හැක.
එය මේ වගේ ය:
එබැවින්, අපට අවශ්ය තොරතුරු තිබේ: P_INFO විධාන. හෝ DEFALT, විධාන ලියන්නේ කොතැනද යන්න endpoint=03 සහ ප්‍රතිචාරය endpoint=86 ලබා ගත යුතු ස්ථානය. ඉතිරිව ඇත්තේ විධාන හෙක්ස් බවට පරිවර්තනය කිරීම පමණි.
අපි දැනටමත් උපාංගය සොයාගෙන ඇති බැවින්, අපි එය කර්නලයෙන් විසන්ධි කරමු...
... සහ 0x03 ලිපිනය සමඟ අවසන් ලක්ෂ්‍යයට ලියන්න,
... ඉන්පසු 0x86 ලිපිනය සහිත අවසාන ලක්ෂ්‍යයෙන් ප්‍රතිචාරය කියවන්න.
ව්‍යුහගත පිළිතුර:
P_INFOfmt: 1
mode: app
app-present: 1
boot-present: 1
hw-sn: 18072B44CA
hw-rev: 0x20
cbl: 4
app-sw-rev: CP000116BBA
boot-sw-rev: CP000014BAD
flash: 3
app-m_name: Voyager 1450g
boot-m_name: Voyager 1450g
app-p_name: 1450g
boot-p_name: 1450g
boot-time: 16:56:02
boot-date: Oct 16 2014
app-time: 08:49:30
app-date: Mar 25 2019
app-compat: 289
boot-compat: 288
csum: 0x6986අපි මෙම දත්ත dump.pcap හි දකිමු.
මහා! පද්ධති තීරු කේත හෙක්ස් බවට පරිවර්තනය කරන්න. එපමණයි, පුහුණු ක්රියාකාරිත්වය සූදානම්.
ස්ථිරාංග ගැන කුමක් කිව හැකිද? සෑම දෙයක්ම සමාන බව පෙනේ, නමුත් සූක්ෂ්මතාවයක් ඇත.
දැල්වෙන ක්‍රියාවලියේ සම්පූර්ණ ඩම්ප් එකක් ගත් පසු, අප ගනුදෙනු කරන්නේ කුමක් දැයි දළ වශයෙන් අපට වැටහුණි. මෙන්න XMODEM පිළිබඳ ලිපියක්, සාමාන්‍ය වශයෙන් වුවද, මෙම සන්නිවේදනය සිදුවන ආකාරය අවබෝධ කර ගැනීමට ඉතා ප්‍රයෝජනවත් විය: මම එය කියවීමට නිර්දේශ කරමි.
ඩම්ප් එක දෙස බලන විට, රාමු ප්‍රමාණය 1024ක් වන අතර, URB-දත්ත ප්‍රමාණය 64ක් බව ඔබට පෙනෙනු ඇත.
එබැවින් - 1024/64 - අපි බ්ලොක් එකක පේළි 16 ක් ලබා ගනිමු, ස්ථිරාංග ගොනුව වරකට අක්ෂර 1 ක් කියවා බ්ලොක් එකක් සාදන්න. විශේෂ අක්ෂර fd1e3 + වාරණ අංකය සහිත බ්ලොක් එකක පේළි 02ක් සම්පූර්ණ කිරීම.
මීළඟ පේළි 14 fd25 + සමඟ පරිපූරණය කර ඇත, XMODEM.calc_crc() භාවිතයෙන් අපි සම්පූර්ණ කොටසෙහි චෙක්සම් ගණනය කරමු ("FF - 1" CSUM බව තේරුම් ගැනීමට බොහෝ කාලයක් ගත විය) සහ අවසාන, 16 වන පේළිය අතිරේක වේ. fd3e සමඟ.
එය එය බව පෙනේ, ස්ථිරාංග ගොනුව කියවන්න, බ්ලොක් වලට පහර දෙන්න, කර්නලයෙන් ස්කෑනරය විසන්ධි කර එය උපාංගයට යවන්න. නමුත් එය එතරම් සරල නැත. ස්කෑනරය ස්ථිරාංග මාදිලියට මාරු කළ යුතුය,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
මේ කණ්ඩායම කොහෙන්ද?? කුණු කන්දෙන්.
නමුත් 64 සීමාව නිසා අපට සම්පූර්ණ බ්ලොක් එකක් ස්කෑනරය වෙත යැවිය නොහැක:
හොඳයි, NEWAPP දැල්වෙන මාදිලියේ ස්කෑනරය hex පිළිගන්නේ නැත. එමනිසා, ඔබට එක් එක් පේළිය bytes_array පරිවර්තනය කිරීමට සිදුවේ
[253, 10, 22, 78, 44, 78, 69, 87, 65, 80, 80, 13, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]ඉන්පසු මෙම දත්ත ස්කෑනරය වෙත යවන්න.
අපට පිළිතුර ලැබේ:
[2, 1, 0, 0, 0, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]ඔබ XMODEM පිළිබඳ ලිපිය පරීක්ෂා කරන්නේ නම්, එය පැහැදිලි වනු ඇත: දත්ත පිළිගෙන ඇත.
සියලුම අවහිර කිරීම් මාරු කළ පසු, අපි මාරු කිරීම සම්පූර්ණ කරමු END_TRANSFER = 'xfdx01x04'.
හොඳයි, මෙම බ්ලොක් සාමාන්‍ය පුද්ගලයින් සඳහා කිසිදු තොරතුරක් ගෙන නොයන බැවින්, අපි පෙරනිමියෙන් සැඟවුණු මාදිලියේ ස්ථිරාංග ස්ථාපනය කරන්නෙමු. යම් අවස්ථාවක දී, අපි tqdm හරහා ප්‍රගති තීරුවක් සංවිධානය කරන්නෙමු.
ඇත්ත වශයෙන්ම, එය කුඩා දේවල් පිළිබඳ කාරණයක්. ඉතිරිව ඇත්තේ, පිරික්සුම් වලදී වැඩ කිරීමේ ක්රියාවලිය මන්දගාමී නොවන පරිදි, සහ ලොග් වීම එකතු නොකිරීමට, පැහැදිලිව නිර්වචනය කරන ලද වේලාවක ස්ක්‍රිප්ට් වල ස්ක්‍රිප්ට් වල විසඳුම එතීමයි.
ප්රතිඵලය
බොහෝ කාලයක් හා වෑයමක් සහ අපගේ හිස මත හිසකෙස් වැය කර ඇති අතර, අපට අවශ්ය විසඳුම් සංවර්ධනය කිරීමට හැකි වූ අතර, නියමිත කාල සීමාව ද සපුරා ඇත. ඒ අතරම, ස්කෑනර් දැන් ප්‍රබෝධමත් කර මධ්‍යගතව නැවත පුහුණු කර ඇත, අපි සම්පූර්ණ ක්‍රියාවලියම පැහැදිලිව පාලනය කරමු. සමාගම කාලය සහ මුදල් ඉතිරි කර ගත් අතර, අපි මෙම වර්ගයේ ප්‍රතිලෝම ඉංජිනේරු උපකරණවල මිල කළ නොහැකි අත්දැකීම් ලබා ගත්තෙමු.
මූලාශ්රය: www.habr.com