Mfumo mahiri wa utengenezaji ongezaji haujumuishi tu roboti, mashine ya kulehemu au printa ya 3D. Kamera ya joto, thermocouple, nafasi ya mashine, mkondo wa kulehemu, volteji, kasi ya kulisha waya na vyanzo vingine vingi vya data vinapaswa kufuatilia mchakato uleule wa uzalishaji kwa wakati mmoja. Tatizo ni kwamba vifaa vingi kati ya hivi vinatengenezwa na wazalishaji tofauti na hutumia mbinu tofauti za mawasiliano kama TCP, UDP, OPC-UA au programu maalum za mtengenezaji. Utafiti huu wa watafiti wa Georgia Institute of Technology unapendekeza mbinu mbadala ambayo, badala ya kulazimisha vifaa tofauti kutumia itifaki moja isiyobadilika, hugeuza kila muunganisho wa kifaa kuwa moduli huru ya Python na kuunganisha moduli hizo katika usanifu wa kati wa nyuzi nyingi.

Muundo uliopendekezwa ulionyeshwa kwenye mfumo wa wire-arc additive manufacturing (WAAM). Katika mpangilio wa majaribio, data ya nafasi ya 10 Hz ilikusanywa kutoka kwa roboti ya Fanuc LR Mate 200iD/7L kupitia TCP, data ya kulehemu ya 20 Hz kutoka kwa mfumo wa kulehemu wa Fronius TPS 400i kupitia OPC-UA, picha za joto za 30 Hz kutoka kwa kamera ya infrared ya FLIR, na data ya joto ya 10 Hz kutoka kwa thermocouple nne zilizounganishwa kwenye Raspberry Pi kupitia UDP. Kila sampuli ya data iliongezewa muhuri wa muda kulingana na rejea ya pamoja ya muda ya NTP katika kompyuta kuu, ili vipimo vya masafa na itifaki tofauti viweze kulinganishwa kwenye mstari mmoja wa wakati wa uzalishaji.

Wazo kuu la utafiti si kufanya vifaa vyote vya uzalishaji vitumie itifaki moja ya mawasiliano, bali kuwezesha kila kifaa kuhifadhi njia yake ya asili ya mawasiliano huku kikiunganishwa na usanifu wa kati kupitia pato la data lililosanifiwa. Kwa njia hii, sensor mpya inapoongezwa, badala ya kuandika upya usanifu mzima, moduli mpya ya mawasiliano inaweza kutengenezwa kwa kifaa hicho pekee. Hata hivyo, utafiti unaonyesha tu demonstrasheni kwenye mfumo maalum wa maabara wa WAAM; bado haujaonyesha utangamano wa moja kwa moja wa usanifu huo na mashine zote za utengenezaji ongezaji, utendaji wa ucheleweshaji katika kiwango cha viwanda, au faida ya uzalishaji katika udhibiti wa ubora wa mzunguko funge.

Kwa nini “usanifu wa kidijitali” unahitajika katika utengenezaji ongezaji?

Katika mchakato wa utengenezaji ongezaji, kujengwa kwa sehemu ya kimwili tabaka baada ya tabaka ni sehemu inayoonekana tu ya mchakato. Katika mfumo wa kisasa, taarifa nyingi za kidijitali hutokea kwa wakati mmoja:

• nafasi ya roboti au CNC,
• mkondo na volteji ya kulehemu,
• kasi ya kulisha waya,
• uingizaji wa joto na nguvu,
• picha za kamera ya joto,
• joto la thermocouple,
• picha za macho,
• ishara za akustiki,
• hali ya mashine na ujumbe wa hitilafu.

Data hizi zinaweza kuwa muhimu katika kuelewa kwa nini porosity, nyufa, upotovu wa kijiometri au deformation ya joto hutokea kwenye sehemu. Data hizo hizo pia zinaweza kutumika katika hatua za baadaye kama pembejeo za modeli za ujifunzaji wa mashine au kama mrejesho wa mizunguko ya udhibiti wa wakati halisi.

Hata hivyo, vifaa vilivyo katika seli moja ya uzalishaji kimwili si lazima viongee lugha moja kidijitali.

Tatizo kuu ni mbinu tofauti za mawasiliano za wazalishaji tofauti

Mtengenezaji mmoja wa roboti anaweza kutumia ujumbe wa TCP socket na lugha yake maalum ya programu. Chanzo cha nguvu cha kulehemu kinaweza kutoa seva ya OPC-UA. Mtengenezaji mmoja wa kamera anaweza kutumia SDK yake mwenyewe huku sensor nyingine ikituma pakiti ya UDP.

Tatizo la watafiti linaweza kufupishwa hivi:

Itifaki tofauti + masafa tofauti ya usampulishaji + programu tofauti za wazalishaji → data ya uzalishaji iliyotawanyika.

Hata hivyo, wakati wa kuchambua mchakato, kile ambacho mtafiti angependa kujua kinaweza kuwa kwa mfano:

Roboti ilipokuwa hasa kwenye kiratibu hiki, mkondo wa kulehemu ulikuwa kiasi gani, joto la juu zaidi kwenye kamera ya joto lilikuwa kiasi gani, na thermocouple nne kwenye sahani zilipima nini wakati huo huo?

Ili kujibu hili, data lazima ziwekwe katika muktadha mmoja wa wakati.

Kwa nini ROS haikuchaguliwa kama suluhisho la moja kwa moja?

Utafiti unatathmini Robot Operating System (ROS) kama mbinu muhimu kwa mawasiliano na udhibiti wa mifumo yenye vipengele vingi. Hata hivyo, waandishi wanaona mahitaji ya ROS kuhusu mfumo wa uendeshaji, utekelezaji na maarifa ya awali kuwa yenye kikwazo kwa madhumuni yao ya matumizi.

Suluhisho kama MTConnect na OPC-UA pia zinaweza kutumika kufikia data za mashine za viwandani. Hata hivyo, lengo la watafiti si kutumia itifaki moja kwa vifaa vyote, bali kuunganisha njia zilizopo za mawasiliano maalum za watengenezaji kwenye mfumo wa kati kupitia moduli za Python zilizo huru kutoka kwa kila moja.

Utafiti huu si benchmark ya kulinganisha inayothibitisha kwa ujumla kwamba ROS, MTConnect au OPC-UA hazitoshi. Vikwazo vya kufaa kwao katika muktadha wa utafiti vinajadiliwa kama msingi wa uamuzi wa usanifu.

Kanuni kuu ya usanifu uliopendekezwa ni ipi?

Usanifu umejengwa juu ya dhana tatu:

1. Moduli huru ya mawasiliano kwa kila kifaa.
2. Moduli kuendeshwa sambamba na mfumo wa kati wa Python “main”.
3. Data zote kuunganishwa katika muundo mmoja wa data kwa muhuri wa muda.

Kwa hiyo mfumo si monolithic, bali ni wa moduli.

Wakati mfumo wa thermocouple unahitaji kuongezwa, badala ya kubuni upya msimbo wa Fanuc au Fronius, script mpya ya Python inayopokea data kutoka kwa thermocouple pekee huandikwa na kuongezwa kwa msimamizi mkuu wa nyuzi.

Kielelezo 2: Usanifu wa kati unafanyaje kazi?

Kielelezo 2 katika ukurasa wa 3 wa makala kinaonyesha ramani ya usanifu wa mfumo mzima.

Katikati kuna Main Multi-thread Handler. Muundo huu mkuu huendesha kwa wakati mmoja programu ndogo zinazowasiliana na vifaa tofauti.

Kwa mfano:

• Fronius Handler → hukusanya data za OPC-UA,
• Fanuc Handler (Read) → hupokea nafasi ya roboti na thamani za register,
• Fanuc Handler (Write) → inaweza kutuma ishara za kuanza au zinazofanana na hizo kwa roboti,
• FLIR IR Handler → huchakata picha za kamera ya joto.

Muundo mkuu pia huhifadhi anwani za IP, vigezo vya mfumo na taarifa za jaribio katika kamusi tofauti. Data iliyokusanywa baadaye inaweza kubadilishwa na kuhifadhiwa katika muundo wa DataFrame/faili za ndani.

Python multi-threading inafanya nini hapa?

Sensor hazipaswi kusubiri moja nyingine. Ikiwa kamera ya joto inazalisha picha 30 kwa sekunde huku roboti ikituma sampuli 10 tu za nafasi kwa sekunde, kuendesha mfumo mzima kulingana na kifaa cha polepole zaidi kunaweza kusababisha upotevu wa data.

Kwa hiyo kila mchakato wa mawasiliano huendeshwa katika uzi huru.

Data inayotoka kwenye kifaa huwekwa kwenye muundo wa queue. Uzi mwingine huandika rekodi zilizo kwenye foleni hii kwenye mfumo wa kati wa log.

Mbinu hii inalenga kuruhusu vifaa tofauti kufanya kazi kwa kasi zao za asili za data.

Kwa nini muhuri wa muda ni sehemu muhimu ya mfumo?

Kurekodi kwa masafa tofauti si tatizo lenyewe; tatizo kuu ni kutokujua kipimo kipi kinahusiana na wakati gani wa mchakato.

Kila programu ndogo huongeza muhuri wa muda kwenye nukta ya data kwa kutumia rejea ya pamoja ya muda ya NTP ya kompyuta.

Rekodi ya data, kimawazo:

[kitambulisho cha sensor + thamani iliyopimwa + muhuri wa muda]

inaweza kufikiriwa katika muundo huu.

Kwa njia hii, inaweza kubainishwa baadaye ni sampuli ipi ya kulehemu ya 20 Hz au nafasi ipi ya roboti ya 10 Hz inayokaribiana na picha fulani ya kamera ya 30 Hz.

Hata hivyo, utafiti haukupima usahihi kamili wa muda wa ulinganishaji unaotegemea NTP au hitilafu ya usawazishaji kati ya vifaa.

Mawasiliano na roboti ya Fanuc yanawekwaje?

Roboti ya mpangilio wa majaribio ni Fanuc LR Mate 200iD/7L.

Mawasiliano makuu:

• TCP socket messaging,
• pakiti za Fanuc R648 na R636 socket,
• lugha ya programu ya KAREL ya Fanuc

hutumika.

Pakiti za socket zilizojengewa ndani ya Python huanzisha muunganisho na roboti; roboti hukubali muunganisho kupitia programu ya KAREL na inaweza kutuma data katika programu nzima ya kulehemu.

Kwa sababu ya muundo wa utekelezaji wa KAREL, hali za kutuma na kupokea data hubadilishwa kupitia thamani za register katika script ya kulehemu. Kati ya tabaka, roboti inaweza kusubiri hadi ipokee ishara ya kuendelea kutoka kwa kompyuta.

Muundo huu hauwezeshi kusoma data pekee, bali pia kutuma taarifa kutoka kwa kompyuta kwenda kwa roboti chini ya masharti fulani.

Mfumo wa kulehemu wa Fronius unaunganishwaje?

Kipengele cha pili kikuu ni mfumo wa nguvu wa kulehemu wa Fronius TPS 400i.

Mfumo unahifadhi seva yake ya OPC Unified Architecture — OPC-UA.

Kupitia seva hii, kompyuta inaweza kusoma taarifa kama:

• hali ya kulehemu,
• kama mchakato uko hai au la,
• taarifa za hitilafu,
• nambari ya seam,
• nishati ya kulehemu,
• mkondo,
• volteji,
• nguvu,
• kasi ya kulisha waya

.

Kwa upande wa Python, programu asinkronasi ilitumika kuuliza seva ya OPC-UA katika jaribio kwa kipindi cha 20 Hz.

Kwa nini kamera ya joto ya FLIR inahitaji thread tofauti?

Muunganisho wa kamera ya joto hufanywa kupitia Spinnaker SDK ya FLIR na programu ya PySpin.

Kamera inaweza kusoma data ghafi za radiometriki na kuzibadilisha kuwa joto kulingana na thamani ya emissivity iliyotolewa.

Utafiti unaripoti tatizo muhimu la vitendo: kuhifadhi picha kwenye diski ndani ya handler hiyo hiyo kunaweza kupunguza kasi ya kamera kutoka takriban 30 fps hadi 10 fps.

Kwa hiyo watafiti walitenga uhifadhi wa picha kwenye thread tofauti. Kutenganisha mtiririko wa data wa kamera na uandishi wa diski kunalenga kuhifadhi kasi ya juu zaidi ya asili ya usampulishaji wa kamera.

Kuongeza thermocouple kunaonyeshaje umoduli?

Kielelezo 3(b) katika ukurasa wa 4 wa makala kinaonyesha moja kwa moja dai la “moduli” la utafiti.

Thermocouple ambazo hazikuwepo katika usanifu wa kwanza ziliongezwa baadaye kupitia Raspberry Pi.

Mtiririko ni:

Thermocouple → Raspberry Pi Thermocouple Reader → UDP → Thermocouple Handler → Main Multi-thread Handler

.

Hatua kuu zinazohitajika kwa kifaa kipya zinaelezwa katika chanzo kwa hatua tatu:

1. anzisha script ya mawasiliano,
2. unda queue ambayo data itahamishiwa,
3. funga muunganisho kwa usahihi mchakato unapokamilika.

Hii pia inaonyesha kuwa umoduli haumaanishi ugunduzi wa moja kwa moja wa sensor mpya. Msimbo maalum wa mawasiliano wa sensor bado lazima uendelezwe.

Nini kilitengenezwa katika jaribio?

Ili kuonyesha utendaji wa usanifu, ukuta wa tabaka tano, mshono mmoja wa Aluminum 5183 ulitengenezwa kwa wire-arc additive manufacturing.

Urefu wa ukuta:

152,4 mm

uliripotiwa.

Sehemu ya msingi ilitengenezwa kwa Aluminum 6061 yenye vipimo:

50,8 × 203,2 mm

.

Katika jaribio hili, mitiririko minne huru ya data ilirekodiwa kwa wakati mmoja.

Kwa nini Kielelezo 4 ni mojawapo ya vielelezo muhimu zaidi vya utafiti?

Kielelezo 4 katika ukurasa wa nne hakionyeshi tu mchoro wa usanifu, bali pia jinsi data halisi za majaribio zinavyounganishwa katika mchakato mmoja.

Katika taswira:

• kipimo cha joto cha kamera ya IR,
• nafasi ya pande tatu ya roboti ya Fanuc,
• data za mfumo wa kulehemu wa Fronius,
• mikondo ya joto ya thermocouple nne

zinaonyeshwa katika muktadha mmoja wa mchakato wa WAAM.

Katika mfano wa kamera ya joto, joto la juu zaidi linaonekana kuwa 509,36 °C.

Thamani hii si matokeo makuu ya utendaji wa utafiti; ni mfano wa kipimo cha joto katika wakati maalum wa mchakato unaoonyeshwa katika Kielelezo 4.

Data za masafa tofauti zinachakatwaje?

Katika chanzo, kila mtiririko wa data hurekodiwa katika masafa yake ya asili na kuoanishwa na mwanzo wa chanzo kwa kutumia mihuri ya muda.

Wakati wa jaribio, utaratibu wa Python logging hurekodi data kwa kasi iwezekanavyo bila kujali aina ya sensor. Programu kuu inapositishwa, CSV huchanganuliwa upya na kupanga data kulingana na sensor.

Moja ya faida muhimu za mbinu hii ni uwezo wa kuhifadhi masafa ya asili ya data ghafi.

Mtafiti anaweza baadaye, kulingana na hitaji:

• kuacha data katika masafa yale yale,
• kuifanya downsample,
• kuongeza resolution kupitia makadirio ya thamani za kati,
• kuilinganisha nukta kwa nukta na sensor tofauti.

Kwa nini thermocouple na kamera ya IR zina thamani pamoja?

Kamera ya IR inaweza kutoa resolution ya juu ya anga na muda kuhusu joto la uso, lakini hesabu sahihi ya joto inategemea thamani ya emissivity.

Thermocouple inaweza kutoa rejea ya moja kwa moja ya joto katika sehemu maalum za kimwili.

Waandishi wanaeleza kuwa hasa katika mfumo wa alumini, thermocouple zinaweza kutumika kama aina ya ground truth kuthibitisha mipangilio ya emissivity ya kamera ya IR.

Hii inaonyesha kuwa fusion ya data inaweza kutumika si tu kukusanya data zaidi, bali pia kuthibitisha sensor moja kwa kutumia sensor nyingine.

Je, udhibiti wa wakati halisi unawezekana?

Usanifu haukubuniwa kama mfumo wa njia moja wa kurekodi data pekee. Kompyuta kuu inaweza kutuma taarifa kurudi kwenye baadhi ya mashine baada ya kufanya hesabu.

Mfano uliotolewa katika chanzo ni kuelekeza nafasi ya roboti kuelekea maeneo baridi zaidi pale mabadiliko fulani yanapogunduliwa katika data ya joto, ili kujaribu kupata gradient ya joto iliyo sawia zaidi katika sehemu nzima.

Hii ni hali yenye nguvu ya matumizi, lakini mpaka muhimu wa kisayansi ni huu:

Utafiti haukutekeleza algoriti hii maalum ya udhibiti wa joto unaobadilika na kupima uboreshaji wa ubora wa sehemu.

Kwa hiyo usanifu unaweza kutoa msingi wa kiufundi kwa mzunguko kama huo wa mrejesho; utendaji wa mzunguko funge unapaswa kuthibitishwa tofauti katika siku zijazo.

Inaweza kuwa na faida gani kwa ujifunzaji wa mashine?

Kuoanisha data za sensor tofauti kwa wakati ni muhimu sana kwa ujifunzaji wa mashine.

Kwa mfano, utafiti unajadili uwezekano wa kugawanya data ya kamera ya joto ya 30 Hz katika seti mbili ndogo za 15 Hz.

Seti moja ya data ya 15 Hz:

• vigezo vya kulehemu,
• nafasi ya roboti,
• taarifa za joto

inaweza kutumika pamoja katika kufundisha modeli; nukta nyingine za 15 Hz zinaweza kutumika kupima utendaji wa utabiri.

Hali hii imetolewa kama pendekezo katika utafiti. Hakuna modeli mpya ya ML iliyofundishwa kwa muundo huu na kuripotiwa usahihi wake katika majaribio ya makala yenyewe.

Utafiti unaunga mkono nini?

• Vipengele vya WAAM kutoka kwa wazalishaji na itifaki tofauti vinaweza kuunganishwa kwenye usanifu wa kati wa moduli unaotegemea Python.
• Mitiririko ya data inayotegemea TCP, OPC-UA, Ethernet na UDP inaweza kurekodiwa pamoja wakati wa jaribio moja.
• Kila sensor inaweza kuendeshwa katika masafa yake ya ukusanyaji data.
• Mihuri ya muda inaweza kutumika kuhusianisha mitiririko ya data ya masafa tofauti katika mchakato uleule wa uzalishaji.
• Moduli mpya ya sensor inaweza kuongezwa bila kubuni upya kabisa muundo mkuu uliopo.
• Kompyuta kuu haijawekewa kikomo cha kupokea data pekee; katika baadhi ya miunganisho ya mashine, miundombinu ya kutuma taarifa za kurudi inaweza kuanzishwa.
• Data iliyounganishwa inaweza kuwa msingi wa uchambuzi baada ya mchakato, uthibitishaji wa sensor, ujifunzaji wa mashine na mifumo ya baadaye ya udhibiti yenye mrejesho.

Utafiti hauthibitishi nini?

• Hauthibitishi kwamba usanifu unaendana moja kwa moja na mifumo yote ya utengenezaji ongezaji duniani.
• Hauonyeshi kwamba kifaa kipya kitaunganishwa moja kwa moja bila kuandikwa script ya mawasiliano.
• Haupimi usahihi kamili wa usawazishaji wa muda.
• Hautoi benchmark ya kiasi kwa ucheleweshaji wa mtandao, upotevu wa pakiti na jitter.
• Haupimi kikomo cha scalability katika idadi kubwa sana ya sensor.
• Hauonyeshi ubora wa utendaji wa kiasi dhidi ya ROS, MTConnect au usanifu mwingine.
• Hauonyeshi kwa majaribio kwamba udhibiti wa mchakato wa mzunguko funge huongeza ubora wa sehemu.
• Haupimi usahihi wa algoriti mpya ya ujifunzaji wa mashine kwa kutumia data iliyokusanywa.
• Hauthibitishi uboreshaji unaotegemea usanifu katika sifa za kimitambo za sampuli iliyotengenezwa ya Aluminum 5183.

Mbinu na Matokeo ya Utafiti

Vipengele vya kimwili vya mfumo wa majaribio

Itifaki za mawasiliano

Mlolongo wa uchakataji data

Mtiririko wa programu wa utafiti ukirahisishwa ni:

Kifaa → script ya mawasiliano ya Python maalum kwa kifaa → queue → central multi-thread handler → timestamp + rekodi ya data → logging → CSV → kupanga upya kulingana na sensor

.

Jambo muhimu katika muundo huu ni kwamba data ya sensor hutatuliwa katika tabaka lake maalum la mawasiliano kabla ya kufika katika programu kuu.

Kwa njia hii mfumo wa kati hauhitaji kusimamia itifaki ya kina ya kila kifaa katika block moja ya msimbo.

Rejea ya muda ya NTP

Moduli ndogo huongeza mihuri ya muda kwenye nukta za data kwa kutumia rejea ya muda ya NTP katika kompyuta ya pamoja.

Mbinu hii huruhusu mitiririko tofauti ya data kuoanishwa karibu na mwanzo wa chanzo.

Hata hivyo, chanzo hakitoi kipimo cha kiasi kwa:

• NTP offset,
• clock drift,
• ucheleweshaji wa pakiti,
• kutokuwa na uhakika wa timestamp,
• hitilafu ya usawazishaji

.

Demonstrasheni ya tabaka tano

Ongezeko la moduli linaloonyeshwa na Kielelezo 3

Kuongezwa kwa thermocouple baadaye kwenye usanifu wa awali ni demonstrasheni ya moja kwa moja zaidi ya muundo wa moduli wa utafiti.

Kisomaji cha thermocouple kwenye Raspberry Pi hutengeneza safu ya joto. Thermocouple Handler hubadilisha data hii kuwa muundo unaotarajiwa na mfumo wa kati na kuihamisha kwa main multi-thread handler.

Misimbo ya mawasiliano ya vifaa vingine haikuandikwa upya wakati wa ongezeko hili.

Fusion ya data inayoonyeshwa na Kielelezo 4

Katika Kielelezo 4, vyanzo vinne vya data vya kimwili vinaonyeshwa kuzunguka tukio moja la uzalishaji.

Kwa njia hii, mtafiti anaweza kuchunguza kwa pamoja katika kipindi kilekile:

• nafasi ya chanzo cha joto,
• joto la juu la IR,
• tabia ya mfumo wa nguvu wa kulehemu,
• vipimo vinne vya joto kwenye sahani

.

Katika utafiti huu, usemi “mtiririko mmoja wa data” haumaanishi sensor zote kutoa aina moja ya kipimo katika masafa yale yale, bali mitiririko tofauti ya data kuweza kuchambuliwa pamoja kupitia muundo wa pamoja wa muda na rekodi.

Resolution ya data inaweza kubadilishwa baadaye

Makala inajadili hali mbili tofauti za uchakataji data.

Kuongeza resolution: Kati ya vipimo vya thermocouple vya 10 Hz, thamani za kati zinaweza kukadiriwa kwa kutumia kamera ya IR ya 30 Hz au mbinu kama Kalman filter.

Kupunguza resolution: Data ya 30 Hz ya kamera ya IR inaweza kufanyiwa downsample kwa kulinganisha nukta kwa nukta na sensor nyingine yenye masafa ya chini na inayotegemewa.

Pia, katika mifumo ambayo kiasi cha data kinachotumwa kwenye wingu lazima kipunguzwe, mtiririko wa data wa masafa ya chini unaweza kutengenezwa.

Haya ni uwezo wa uchakataji data unaotolewa na usanifu; makala haijajaribu kwa kulinganisha utendaji wa mbinu hizi zote za uchujaji.

Nguvu za utafiti

• Demonstrasheni ya vitendo kwenye vifaa halisi vya WAAM.
• Matumizi ya wakati mmoja ya vyanzo vinne tofauti vya data.
• Kuwepo kwa mbinu tofauti za mawasiliano kama TCP, UDP na OPC-UA katika usanifu mmoja.
• Kuhifadhi masafa tofauti ya asili ya usampulishaji.
• Kuongezwa baadaye kwa moduli mpya ya thermocouple na kuonyesha umoduli.
• Kuweka muundo wa data wenye mihuri ya muda kuwa wa kati kwa uchambuzi wa mchakato.
• Kuwepo kwa uwezo wa kuandika kurudi, si kusoma tu, katika muunganisho wa roboti.
• Muundo wa programu umetengenezwa kwa lugha ya utafiti inayotumiwa sana kama Python.

Vikwazo vikuu vya utafiti

Kwa sababu utafiti ni makala ya muundo mfupi katika Manufacturing Letters, tathmini ya utendaji wa usanifu katika kiwango kikubwa sana haikufanywa.

Hasa, vipimo hivi havipo:

• ucheleweshaji wa data kutoka mwisho hadi mwisho,
• hitilafu ya usawazishaji wa timestamp,
• kiwango cha upotevu wa pakiti,
• uthabiti wa muda mrefu wa mfumo,
• idadi ya juu ya sensor za wakati mmoja,
• mzigo wa CPU na RAM,
• mahitaji ya bandwidth ya mtandao,
• muda wa mwitikio wa mzunguko wa udhibiti,
• benchmark ya kiasi dhidi ya usanifu mwingine wa kidijitali.

Zaidi ya hayo, jaribio lilifanyika katika seli moja ya utafiti ya WAAM. Inapaswa kuthibitishwa tofauti kama roboti za chapa tofauti, mifumo ya CNC, mashine za AM zinazotegemea leza au mitandao ya viwanda ya kiwanda zinaweza kuunganishwa kwa urahisi sawa.

Nini kingine kinahitajika wakati wa matumizi ya viwandani?

Kujenga usanifu wa moduli wa ukusanyaji data katika maabara ya utafiti na miundombinu ya uzalishaji wa viwandani inayofanya kazi bila kukoma hazina mahitaji sawa ya kutegemewa.

Katika matumizi halisi ya kiwanda, masuala yafuatayo pia yanapaswa kushughulikiwa tofauti:

• uidhinishaji wa watumiaji,
• usalama wa mtandao,
• uthibitishaji wa vifaa vya viwandani,
• tabia salama wakati muunganisho unakatika,
• uadilifu wa data,
• hifadhi nakala,
• usimamizi wa matoleo,
• matengenezo wakati itifaki zinabadilika,
• mipaka ya usalama ya udhibiti wa wakati halisi

. Utafiti wa chanzo hauchukulii masuala haya yote kuwa yameshatatuliwa.

Maana yake kwa mifumo ya uzalishaji nchini Uturuki

Utafiti haujafanya majaribio kwenye kiwanda, roboti au mfumo wa AM nchini Uturuki. Kwa hiyo haiwezi kuhitimishwa kwamba mfumo utafanya kazi moja kwa moja katika kituo maalum cha viwanda cha Uturuki.

Hata hivyo, wazo kuu la usanifu wa utafiti linatoa mbinu ya jumla ya utafiti kwa vituo vya uzalishaji ambavyo vina utofauti mkubwa wa chapa na itifaki. Kwa mfano, katika seli yenye roboti, mfumo wa kulehemu, CNC, kamera ya joto na sensor za mchakato kutoka kwa wazalishaji tofauti, moduli tofauti ya muunganisho inaweza kutengenezwa kwa kila kifaa na kuhamishwa kwenye tabaka la data lenye muhuri wa muda wa pamoja.

Katika matumizi ya viwandani ya ndani, uthibitishaji tofauti unahitajika hasa kwa itifaki za PLC/CNC/roboti zinazotumika, sheria za usalama wa mtandao, mahitaji ya wakati halisi na miundombinu ya mtandao wa kiwanda.

Dokezo la Chanzo na Mbinu

Jina kamili la utafiti asilia: A proposal of a modular and customizable digital architecture for additive manufacturing

Waandishi: Kathryn Kelly, Christopher Saldana, Kyle Saleeby.

Mpangilio wa waandishi: Mpangilio katika utafiti wa chanzo umehifadhiwa kama ulivyo.

Mwandishi anayewajibika: Kathryn Kelly.

Mchango sawa/uandishi wa kwanza wa pamoja: Hakuna tamko la mchango sawa katika chanzo.

Taasisi 1: Georgia Institute of Technology, George W. Woodruff School of Mechanical Engineering, Atlanta, Georgia, USA.

Taasisi 2: Georgia Institute of Technology, Georgia Tech Manufacturing Institute, Atlanta, Georgia, USA.

Aina ya chanzo: Makala fupi ya utafiti/matumizi iliyopitiwa na rika; imechapishwa kama “Letters” ndani ya Manufacturing Letters.

Jarida: Manufacturing Letters.

Mchapishaji: Elsevier Ltd. on behalf of Society of Manufacturing Engineers (SME).

Juzuu: 49.

Kurasa: 13–18.

DOI: 10.1016/j.mfglet.2026.06.008

Tarehe ya kuwasilishwa: 2 Aprili 2026.

Tarehe ya marekebisho: 2 Juni 2026.

Tarehe ya kukubaliwa: 9 Juni 2026.

Uchapishaji mtandaoni: 22 Juni 2026.

Kiungo rasmi cha DOI: https://doi.org/10.1016/j.mfglet.2026.06.008

Hali ya mapitio ya rika: Ni muundo mfupi wa utafiti uliopitiwa na rika na kuchapishwa katika Manufacturing Letters. Mwongozo rasmi wa waandishi wa jarida unaeleza kwamba makala hupitia mapitio ya rika.

Leseni: Creative Commons Attribution-NonCommercial 4.0 — CC BY-NC 4.0.

Hali ya preprint: Faili iliyochunguzwa ni makala ya mwisho iliyochapishwa katika Manufacturing Letters.

Mfumo wa majaribio: Manipulator ya roboti ya Fanuc LR Mate 200iD/7L, mfumo wa kulehemu wa Fronius TPS 400i CMT, kamera ya FLIR IR, thermocouple nne na Raspberry Pi.

Demonstrasheni: Ukuta wa WAAM wa tabaka tano, mshono mmoja wenye urefu wa 152,4 mm, ukitumia Aluminum 5183 juu ya msingi wa Aluminum 6061.

Usanifu mkuu wa programu: Python multi-threading, queue, logging, script za handler maalum kwa kifaa na ukusanyaji wa data wa kati wenye mihuri ya muda.

Mbinu za mawasiliano: TCP/KAREL kwa Fanuc; OPC-UA kwa Fronius; Ethernet/Spinnaker/PySpin kwa FLIR; UDP kwa mfumo wa thermocouple wa Raspberry Pi.

Masafa ya data: Fanuc 10 Hz; Fronius 20 Hz; FLIR 30 Hz; thermocouple 10 Hz.

Usawazishaji wa muda: Moduli huweka mihuri ya muda kulingana na rejea ya pamoja ya NTP katika kompyuta kuu. Makala haitoi benchmark ya kiasi ya hitilafu ya usawazishaji.

Ufadhili: Makala haina tamko tofauti la ufadhili. Katika michango ya CRediT, Kyle Saleeby ametajwa katika jukumu la Funding acquisition.

Mgongano wa maslahi: Waandishi walitangaza kuwa hakuna maslahi ya kifedha yanayojulikana au mahusiano ya kibinafsi yanayoweza kuathiri utafiti.

Michango ya CRediT: Kathryn Kelly: Writing – review & editing, Writing – original draft, Validation, Software, Methodology, Investigation, Formal analysis, Conceptualization. Christopher Saldana: Writing – review & editing, Supervision. Kyle Saleeby: Writing – review & editing, Resources, Funding acquisition, Formal analysis, Data curation.

Upatikanaji wa msimbo: Makala ya chanzo inasema kwamba msimbo wa majaribio uliotumiwa unaweza kupatikana kutoka Georgia Tech Manufacturing Institute kwa ombi na kwamba baada ya kukamilika kwa utafiti ulipangwa kuchapishwa kikamilifu katika akaunti ya GTMI GitHub. Kauli hii inaonyesha hali iliyokuwepo wakati wa uchapishaji wa makala ya chanzo.

Upatikanaji wa data: Makala pia haina Data Availability Statement tofauti. Lengo kuu la utafiti ni kuonyesha usanifu na mitiririko ya mfano ya data.

Mpaka mkuu wa kimbinu: Usanifu ulijaribiwa kwenye mfumo mmoja wa utafiti wa WAAM. Makala haina benchmark ya end-to-end latency, jitter, packet loss, hitilafu ya usawazishaji wa NTP, matumizi ya rasilimali au scalability katika idadi kubwa ya sensor.

Mpaka wa umoduli: Ili kuongeza kifaa kipya kwenye usanifu, lazima itengenezwe script ya Python maalum kwa kifaa inayoweza kuwasiliana na sensor/mashine husika. Utafiti haupendekezi ugunduzi wa vifaa wa plug-and-play.

Mpaka wa udhibiti: Uwezo wa kuandika data kutoka kompyuta kuu kwenda kwenye mashine unafanya iwezekane kutumia usanifu kwa udhibiti wenye mrejesho; hata hivyo, athari ya marekebisho ya moja kwa moja ya roboti kwa mrejesho wa joto kwenye ubora wa sehemu haikupimwa kwa majaribio katika utafiti.

Mpaka wa ujifunzaji wa mashine: Imejadiliwa kwamba usanifu wa data unaweza kutumika kwa modeli za ML; makala hairipoti utendaji wa modeli mpya ya ujifunzaji wa mashine kwenye data iliyokusanywa na yenyewe.

Mpaka wa maudhui ya kisayansi: Usanifu, vifaa, itifaki za mawasiliano, masafa ya sensor, jiometri ya jaribio na hali za matumizi katika makala hii ya Verianla zinategemea utafiti asilia. Chanzo cha nje kilitumika tu kuthibitisha rekodi ya bibliografia na hali ya mapitio ya rika ya jarida.