Акылдуу аддитивдик өндүрүш системасы роботтон, ширетүүчү аппараттан же 3D принтерден гана турбайт. Термалдык камера, термопара, машинанын абалы, ширетүү тогу, чыңалуу, зым берүү ылдамдыгы жана башка көптөгөн маалымат булактары бир эле өндүрүш процессин бир убакта көзөмөлдөшү керек. Маселе бул түзмөктөрдүн көбү ар башка өндүрүүчүлөр тарабынан иштелип чыгып, TCP, UDP, OPC-UA же өндүрүүчүгө таандык программалык камсыздоо сыяктуу бири-биринен айырмаланган байланыш ыкмаларын колдонушунда. Georgia Institute of Technology изилдөөчүлөрүнүн бул эмгеги ар башка түзмөктөрдү бир гана туруктуу протоколго мажбурлоонун ордуна, ар бир түзмөк байланышын өз алдынча Python модулуна айлантып, бул модулдарды борбордук көп агымдуу архитектурада бириктирген альтернативдүү ыкманы сунуштайт.

Сунушталган түзүлүш wire-arc additive manufacturing (WAAM) системасында көрсөтүлдү. Эксперименттик түзүлүштө Fanuc LR Mate 200iD/7L роботунан TCP аркылуу 10 Hz позиция маалыматы, Fronius TPS 400i ширетүү системасынан OPC-UA аркылуу 20 Hz ширетүү маалыматы, FLIR инфракызыл камерасынан 30 Hz термалдык сүрөт жана Raspberry Pi ге туташтырылган төрт термопарадан UDP аркылуу 10 Hz температура маалыматы чогултулду. Ар бир маалымат үлгүсүнө борбордук компьютердеги жалпы NTP убакыт шилтемесине ылайык убакыт белгиси кошулуп, ар башка жыштык жана протоколдордогу өлчөөлөрдү жалпы өндүрүш убакыт сызыгында салыштыруу максат кылынды.

Эмгектин негизги идеясы бардык өндүрүш жабдууларын бир эле байланыш протоколунда иштетүү эмес, ар бир түзмөк өзүнүн табигый байланыш формасын сактап туруп, борбордук архитектурага стандарттуу маалымат чыгышы менен туташуусун камсыз кылуу. Ошентип жаңы сенсор кошулганда бүт архитектураны кайра жазуунун ордуна, ошол түзмөк үчүн гана жаңы байланыш модулун иштеп чыгууга болот. Бирок эмгек белгилүү бир WAAM лабораториялык системасында гана демонстрация берет; архитектуранын бардык аддитивдик өндүрүш машиналары менен автоматтык шайкештигин, өнөр жай масштабындагы кечигүү көрсөткүчтөрүн же жабык циклдеги сапатты контролдоодогу өндүрүш пайдасын азырынча көрсөткөн эмес.

Аддитивдик өндүрүштө эмне үчүн “санарип архитектура” керек?

Аддитивдик өндүрүш процессинде физикалык бөлүктүн катмар-катмар түзүлүшү процесстин көрүнгөн бөлүгү гана. Заманбап системада бир убакта көптөгөн санарип маалыматтар пайда болот:

• роботтун же CNCнин позициясы,
• ширетүү тогу жана чыңалуусу,
• зым берүү ылдамдыгы,
• жылуулук киргизүү жана кубат,
• термалдык камера сүрөттөрү,
• термопара температуралары,
• оптикалык сүрөттөр,
• акустикалык сигналдар,
• машинанын абалы жана ката билдирүүлөрү.

Бул маалыматтар бөлүктө эмне үчүн көңдөй, жарака, геометриялык четтөө же термалдык деформация пайда болгонун түшүнүүгө маанилүү болушу мүмкүн. Ошол эле маалыматтар кийинки этапта машиналык үйрөнүү моделдеринин киргизүүсү же реалдуу убакыттагы башкаруу циклдеринин кайтарым байланышы катары да колдонулушу мүмкүн.

Бирок физикалык жактан бир эле өндүрүш уячасында турган түзмөктөр санарип жактан бир эле тилде сүйлөшү керек эмес.

Негизги маселе — ар башка өндүрүүчүлөрдүн ар башка байланыш ыкмалары

Бир робот өндүрүүчү TCP socket билдирүүлөрүн жана өзүнө таандык программалоо тилин колдонушу мүмкүн. Ширетүүчү кубат булагы OPC-UA серверин камсыз кылышы мүмкүн. Бир камера өндүрүүчү өзүнүн SDKсын колдонсо, башка сенсор UDP пакетин жөнөтүшү мүмкүн.

Изилдөөчүлөрдүн көйгөйүн төмөнкүчө жыйынтыктоого болот:

Ар башка протоколдор + ар башка үлгү алуу жыштыктары + ар башка өндүрүүчү программалары → бөлүнүп кеткен өндүрүш маалыматы.

Ал эми процесс талданганда изилдөөчү, мисалы, муну билгиси келет:

Робот так ушул координатада турганда ширетүү тогу канча эле, термалдык камерадагы максималдуу температура канча болду жана ошол эле учурда пластинадагы төрт термопара эмнени өлчөдү?

Муну жооптоо үчүн маалыматтарды жалпы убакыт контекстине жайгаштыруу керек.

ROS эмне үчүн түздөн-түз чечим катары тандалган жок?

Эмгек Robot Operating Systemди (ROS) көп компоненттүү системалардын байланышы жана башкаруусу үчүн маанилүү ыкма катары баалайт. Бирок авторлор өздөрүнүн колдонуу максаты жагынан ROSтун операциялык система, ишке ашыруу жана алдын ала билим талаптарын чектөөчү деп эсептешет.

MTConnect жана OPC-UA сыяктуу чечимдер да өнөр жай машиналарынын маалыматтарына жетүү үчүн колдонулушу мүмкүн. Бирок изилдөөчүлөрдүн максаты бир протоколду бардык түзмөктөргө таңуулоо эмес, өндүрүүчүгө таандык учурдагы байланыш ыкмаларын бири-биринен көз карандысыз Python модулдары аркылуу борбордук түзүлүшкө туташтыруу.

Бул эмгек ROS, MTConnect же OPC-UA жалпы түрдө жетишсиз экенин далилдеген салыштырма benchmark эмес. Алардын эмгектин контекстиндеги ылайыктуулук чектөөлөрү архитектуралык долбоордун негиздемеси катары талкууланат.

Сунушталган архитектуранын негизги принциби эмне?

Архитектура үч түшүнүккө негизделген:

1. Ар бир жабдык үчүн өз алдынча байланыш модулу.
2. Модулдарды борбордук Python “main” системасы параллелдүү иштетет.
3. Бардык маалыматтар убакыт белгиси менен жалпы маалымат түзүмүндө бириктирилет.

Ошондуктан система монолиттүү эмес, модулдук.

Термопара системасын кошуу керек болгондо Fanuc же Fronius кодун кайра долбоорлоонун ордуна, термопарадан гана маалымат алган жаңы Python скрипти жазылып, негизги агым башкаргычына кошулат.

2-сүрөт: Борбордук архитектура кантип иштейт?

Макаланын 3-бетиндеги 2-сүрөт бүт системанын архитектуралык картасын көрсөтөт.

Борбордо Main Multi-thread Handler жайгашкан. Бул негизги түзүлүш ар түрдүү жабдыктар менен байланышкан төмөнкү программаларды бир убакта иштетет.

Мисалы:

• Fronius Handler → OPC-UA маалыматтарын чогултат,
• Fanuc Handler (Read) → роботтун позициясын жана register маанилерин алат,
• Fanuc Handler (Write) → роботко баштоо же ушул сыяктуу сигналдарды жөнөтө алат,
• FLIR IR Handler → термалдык камера сүрөттөрүн иштетет.

Негизги түзүлүш IP даректерин, системалык параметрлерди жана эксперимент маалыматын өзүнчө сөздүктөрдө сактайт. Чогултулган маалымат кийин өзгөртүлүп, DataFrame/жергиликтүү файл түзүмүнө сакталат.

Python multi-threading бул жерде эмне кылат?

Сенсорлор бири-бирин күтүп калбашы керек. Термалдык камера секундасына 30 сүрөт чыгарса, робот секундасына болгону 10 позиция үлгүсүн жөнөтсө, бүт системаны эң жай түзмөккө ылайык иштетүү маалымат жоготууга алып келиши мүмкүн.

Ошондуктан ар бир байланыш процесси өз алдынча агымда иштетилет.

Бир түзмөктөн келген маалымат queue түзүмүнө калтырылат. Башка агым ушул кезектеги жазууларды борбордук log системасына жазат.

Бул ыкма ар башка түзмөктөрдүн өз табигый маалымат ылдамдыгында иштешине мүмкүнчүлүк берүүнү көздөйт.

Убакыт белгиси эмне үчүн системанын критикалык бөлүгү?

Ар башка жыштыкта жазуу алуу өзүнчө көйгөй эмес; кайсы өлчөө процесстин кайсы учуруна таандык экенин билбөө негизги көйгөй.

Ар бир төмөнкү программа маалымат чекитине компьютердин жалпы NTP убакыт шилтемесин колдонуп убакыт белгисин кошот.

Маалымат жазуусун концептуалдык түрдө:

[сенсор идентификатору + өлчөнгөн мааниси + убакыт белгиси]

түрүндө элестетсе болот.

Ошентип 30 Hz камерадагы сүрөттүн болжол менен кайсы 20 Hz ширетүү үлгүсүнө же 10 Hz робот позициясына туура келгенин кийин аныктоого болот.

Бирок эмгек NTP негизиндеги дал келтирүүнүн абсолюттук убакыт тактыгын же түзмөктөр ортосундагы синхрондоштуруу катасын өлчөгөн эмес.

Fanuc робот менен байланыш кантип түзүлөт?

Эксперименттик түзүлүштүн роботу Fanuc LR Mate 200iD/7L.

Негизги байланыш:

• TCP socket messaging,
• Fanuc R648 жана R636 socket пакеттери,
• Fanucтун KAREL программалоо тили

аркылуу жүргүзүлөт.

Pythonдун ички socket пакеттери робот менен туташууну баштайт; робот KAREL программасы менен байланыш кабыл алып, ширетүү программасы боюнча маалымат жөнөтө алат.

KARELдин аткаруу түзүмүнө байланыштуу маалымат жөнөтүү жана кабыл алуу абалдары ширетүү скриптиндеги register маанилери менен өзгөртүлөт. Катмарлардын ортосунда робот компьютерден улантуу сигналы келгенге чейин күтө алат.

Бул түзүлүш маалыматты окуу менен гана чектелбестен, белгилүү шарттарда компьютерден роботко маалымат жөнөтүүгө да мүмкүнчүлүк берет.

Fronius ширетүү системасы кантип туташат?

Экинчи негизги компонент Fronius TPS 400i ширетүү кубат системасы.

Система өзүнүн OPC Unified Architecture — OPC-UA серверин камтыйт.

Компьютер бул сервер аркылуу:

• ширетүү режими,
• процесс активдүүбү же жокпу,
• ката маалыматы,
• seam номери,
• ширетүү энергиясы,
• ток,
• чыңалуу,
• кубат,
• зым берүү ылдамдыгы

сыяктуу маалыматтарды окуй алат.

Python тарабында асинхрондук программалоо колдонулуп, OPC-UA сервери экспериментте 20 Hz аралык менен суралган.

FLIR термалдык камера эмне үчүн өзүнчө thread талап кылат?

Термалдык камера байланышы FLIRдин Spinnaker SDKсы жана PySpin колдонмосу аркылуу жүргүзүлөт.

Камера чийки радиометриялык маалыматты окуп, берилген emissivity маанисине жараша температурага айландыра алат.

Эмгек маанилүү практикалык көйгөйдү билдирет: сүрөттү ошол эле handler ичинде дискке сактоо камера ылдамдыгын болжол менен 30 fpsтен 10 fpsке чейин төмөндөтүшү мүмкүн.

Изилдөөчүлөр ошондуктан сүрөттү сактоону өзүнчө threadге бөлгөн. Камеранын маалымат агымын дискке жазуу процессинен ажыратуу камеранын жогорку табигый үлгү алуу ылдамдыгын сактоону көздөйт.

Термопара кошуу модулдуулукту кантип көрсөтөт?

Макаланын 4-бетиндеги 3(b)-сүрөт эмгектин “модулдук” деген талабын түздөн-түз визуалдаштырат.

Алгачкы архитектурада жок термопаралар кийин Raspberry Pi аркылуу системага кошулган.

Агым:

Термопаралар → Raspberry Pi Thermocouple Reader → UDP → Thermocouple Handler → Main Multi-thread Handler

түрүндө.

Жаңы түзмөк үчүн керектүү негизги иштер булакта үч кадам менен түшүндүрүлгөн:

1. байланыш скриптин башта,
2. маалымат өткөрүлө турган queue түз,
3. процесс бүткөндө байланышты туура жап.

Бул модулдуулук жаңы сенсордун автоматтык табылышы дегенди билдирбесин да көрсөтөт. Сенсорго мүнөздүү байланыш коду дагы эле иштелип чыгышы керек.

Экспериментте эмне өндүрүлгөн?

Архитектуранын иштешин көрсөтүү үчүн wire-arc additive manufacturing менен беш катмарлуу, бир тигиштүү Aluminum 5183 дубал өндүрүлгөн.

Дубалдын узундугу:

152,4 mm

деп берилген.

Негиз болсо Aluminum 6061 ден:

50,8 × 203,2 mm

өлчөмүндө даярдалган.

Бул эксперимент учурунда төрт көз карандысыз маалымат агымы бир убакта жазылган.

4-сүрөт эмне үчүн эмгектин эң маанилүү визуалдарынын бири?

Төртүнчү беттеги 4-сүрөт архитектура схемасын гана эмес, чыныгы эксперимент маалыматтары бир процессте кантип бириккенин көрсөтөт.

Визуалда:

• IR камеранын термалдык өлчөөсү,
• Fanuc роботунун үч өлчөмдүү позициясы,
• Fronius ширетүү системасынын маалыматтары,
• төрт термопаранын температура ийри сызыгы

бир эле WAAM процессинин контекстинде көрсөтүлгөн.

Термалдык камера мисалында максималдуу температура 509,36 °C болуп көрүнөт.

Бул маани эмгектин негизги натыйжалуулук жыйынтыгы эмес; 4-сүрөттө көрсөтүлгөн белгилүү бир процесс учуруна таандык термалдык өлчөө мисалы.

Ар башка жыштыктагы маалыматтар кантип иштетилет?

Булакта ар бир маалымат агымы өзүнүн баштапкы жыштыгында жазылып, убакыт белгилери менен булактын башталышына тегизделет.

Эксперимент учурунда Python logging механизми маалыматты сенсор түрүнө карабастан мүмкүн болушунча тез жазат. Негизги программа токтотулганда CSV кайра талданып, сенсорлор боюнча уюштурулат.

Бул ыкманын маанилүү артыкчылыктарынын бири чийки маалыматтын табигый жыштыгын сактоого мүмкүнчүлүк берет.

Изилдөөчү кийин муктаждыгына жараша маалыматты:

• ошол жыштыкта калтыра алат,
• downsample кыла алат,
• аралык маанилерди баалоо менен чечилишти жогорулата алат,
• ар башка сенсорлор менен чекиттен-чекитке салыштыра алат.

Термопара менен IR камера эмне үчүн бирге баалуу?

IR камера беттик температура жөнүндө жогорку мейкиндиктик жана убакыттык чечилиш бере алат, бирок туура температура эсептөө emissivity маанисине көз каранды.

Термопара болсо белгилүү физикалык чекиттерде түз температура шилтемесин бере алат.

Авторлор өзгөчө алюминий системасында термопараларды IR камеранын emissivity жөндөөлөрүн текшерүү үчүн бир түрдүү ground truth катары колдонсо болорун белгилешет.

Бул маалыматтарды бириктирүү көп маалымат чогултуу үчүн гана эмес, бир сенсорду башка сенсор аркылуу текшерүү үчүн да колдонулушу мүмкүн экенин көрсөтөт.

Реалдуу убакыттагы башкаруу мүмкүнбү?

Архитектура маалыматты гана жазган бир багыттуу система катары долбоорлонгон эмес. Борбордук компьютер эсептөөдөн кийин айрым машиналарга кайра маалымат жөнөтө алат.

Булакта берилген мисал — термалдык маалыматта белгилүү өзгөрүү табылганда роботтун позициясын муздаак аймактарга багыттап, бөлүк боюнча бир калыптагы температура градиентин алууга аракет кылуу.

Бул күчтүү колдонуу сценарийи, бирок маанилүү илимий чек төмөнкүдөй:

Эмгек бул конкреттүү адаптивдүү термалдык башкаруу алгоритмин колдонуп, бөлүктүн сапатындагы жакшыртууну өлчөгөн эмес.

Демек, архитектура мындай кайтарым байланыш циклине техникалык негиз бере алат; жабык циклдин натыйжалуулугу келечекте өзүнчө текшерилиши керек.

Машиналык үйрөнүү үчүн кандай артыкчылык болушу мүмкүн?

Ар башка сенсор маалыматтарын убакыт боюнча дал келтирүү машиналык үйрөнүү үчүн өзгөчө маанилүү.

Мисалы, эмгек 30 Hz термалдык камера маалыматын эки 15 Hz төмөнкү топтомго бөлүүгө болорун талкуулайт.

Бир 15 Hz маалымат топтому:

• ширетүү параметрлери,
• робот позициясы,
• термалдык маалыматтар

менен бирге моделди үйрөтүүдө колдонулушу мүмкүн; калган 15 Hz чекиттер божомол натыйжалуулугун текшерүүдө колдонулушу мүмкүн.

Бул сценарий эмгекте сунуш катары берилген. Макаланын өз эксперименттеринде ушул дизайн менен үйрөтүлүп, тактыгы билдирилген жаңы ML модели жок.

Эмгек эмнени колдойт?

• Ар башка өндүрүүчү жана протоколдору бар WAAM компоненттерин Python негизиндеги модулдук борбордук архитектурага туташтырууга болот.
• TCP, OPC-UA, Ethernet жана UDP негизиндеги маалымат агымдарын бир эле экспериментте бирге жазууга болот.
• Ар бир сенсор өзүнүн маалымат чогултуу жыштыгында иштей алат.
• Убакыт белгилерин ар башка жыштыктагы маалымат агымдарын бир эле өндүрүш процесси боюнча байланыштыруу үчүн колдонсо болот.
• Жаңы сенсор модулун учурдагы негизги түзүлүштү толугу менен кайра долбоорлобой эле кошууга болот.
• Борбордук компьютер маалымат алуу менен гана чектелбейт; айрым машина байланыштарында кайра маалымат жөнөтүү инфраструктурасын түзүүгө болот.
• Чогултулган бириккен маалымат процесстен кийинки анализ, сенсорду текшерүү, машиналык үйрөнүү жана келечектеги кайтарым байланыштуу башкаруу системалары үчүн негиз боло алат.

Эмгек эмнени далилдебейт?

• Архитектура дүйнөдөгү бардык аддитивдик өндүрүш системалары менен түздөн-түз шайкеш экенин далилдебейт.
• Жаңы түзмөк байланыш скрипти жазылбай туруп системага автоматтык туташаарын көрсөтпөйт.
• Убакыт синхрондоштуруунун абсолюттук тактыгын өлчөбөйт.
• Тармак кечигүүсү, пакет жоголушу жана jitter үчүн сандык benchmark бербейт.
• Өтө көп сенсор болгон учурда масштабдуулук чегин өлчөбөйт.
• ROS, MTConnect же башка архитектураларга салыштырмалуу сандык натыйжалуулук артыкчылыгын көрсөтпөйт.
• Жабык цикл процессти башкаруу бөлүктүн сапатын жогорулатарын эксперимент аркылуу көрсөтпөйт.
• Чогултулган маалыматтар менен жаңы машиналык үйрөнүү алгоритминин тактыгын өлчөбөйт.
• Өндүрүлгөн Aluminum 5183 үлгүсүнүн механикалык касиеттеринде архитектурага байланыштуу жакшыртууну далилдебейт.

Эмгектин Ыкмасы жана Жыйынтыктары

Эксперименттик системанын физикалык компоненттери

Байланыш протоколдору

Маалымат иштетүү чынжыры

Эмгектин программалык агымы жөнөкөйлөштүрүлгөндө:

Түзмөк → түзмөккө мүнөздүү Python байланыш скрипти → queue → борбордук multi-thread handler → timestamp + маалымат жазуусу → logging → CSV → сенсор боюнча кайра уюштуруу

түрүндө.

Бул дизайндын маанилүү жагы сенсор маалыматы борбордук колдонмого келгенге чейин өзүнүн түзмөккө мүнөздүү байланыш катмарында чечмеленет.

Ошентип борбордук система ар бир түзмөктүн деталдуу протоколун бир эле код блогунда башкарууга милдеттүү болбойт.

NTP убакыт шилтемеси

Төмөнкү модулдар жалпы компьютердеги NTP убакыт шилтемеси менен маалымат чекиттерине убакыт белгисин кошот.

Бул ыкма ар башка маалымат агымдарын булактын башталышынын тегерегинде тегиздөөгө мүмкүндүк берет.

Бирок булакта:

• NTP offset,
• clock drift,
• пакет кечигүүсү,
• timestamp белгисиздиги,
• синхрондоштуруу катасы

үчүн сандык өлчөө берилген эмес.

Беш катмарлуу демонстрация

3-сүрөт көрсөткөн модулдук кошуу

Термопаралардын баштапкы архитектурага кийин кошулушу эмгектин модулдук дизайнынын эң түз демонстрациясы.

Raspberry Piдеги термопара окугуч температура массивин чыгарат. Thermocouple Handler бул маалыматты борбордук түзүлүш күткөн форматка айландырып, негизги multi-thread handlerга өткөрөт.

Башка түзмөктөрдүн байланыш коддору бул кошууда кайра жазылган эмес.

4-сүрөт көрсөткөн маалыматтарды бириктирүү

4-сүрөттө төрт физикалык маалымат булагы бир өндүрүш окуясынын айланасында визуалдаштырылган.

Ошентип изилдөөчү ошол эле убакыт аралыгында:

• жылуулук булагынын позициясын,
• IR максималдуу температурасын,
• ширетүү кубат системасынын жүрүм-турумун,
• пластинадагы төрт температура өлчөөсүн

бирге карай алат.

Бул эмгек үчүн “бир маалымат агымы” деген бардык сенсорлор бир жыштыкта бирдей өлчөө чыгарат деген эмес, ар башка маалымат агымдарын жалпы убакыт жана жазуу түзүмү аркылуу бирге талдоого болот дегенди билдирет.

Маалыматтын чечилиши кийин өзгөртүлүшү мүмкүн

Макала эки башка маалымат иштетүү сценарийин талкуулайт.

Чечилишти жогорулатуу: 10 Hz термопара өлчөөлөрүнүн ортосунда 30 Hz IR камера же Kalman фильтри сыяктуу ыкмалардан пайдаланып аралык маанилер бааланышы мүмкүн.

Чечилишти төмөндөтүү: IR камеранын 30 Hz маалыматы төмөн жыштыктагы жана ишенимдүү башка сенсор менен чекиттен-чекитке салыштыруу үчүн downsample кылынышы мүмкүн.

Мындан тышкары булутка жөнөтүлгөн маалымат көлөмүн чектөө керек болгон системаларда төмөн жыштыктагы маалымат агымы түзүлүшү мүмкүн.

Булар архитектура сунуштаган маалымат иштетүү мүмкүнчүлүктөрү; макалада бул фильтрлөө ыкмаларынын баарынын натыйжалуулугу салыштырмалуу сыналган эмес.

Эмгектин күчтүү жактары

• Чыныгы WAAM жабдыгында практикалык демонстрация жүргүзүлүшү.
• Төрт ар башка маалымат булагынын бир убакта колдонулушу.
• TCP, UDP жана OPC-UA сыяктуу ар башка байланыш ыкмаларынын бир архитектурада болушу.
• Ар башка табигый үлгү алуу жыштыктарынын сакталышы.
• Жаңы термопара модулу кийин кошулуп, модулдуулуктун көрсөтүлүшү.
• Убакыт белгиси бар маалымат түзүмүнүн процесс талдоо үчүн борборлоштурулушу.
• Робот байланышы окуу менен гана чектелбестен, кайра жазуу мүмкүнчүлүгүнүн болушу.
• Программалык түзүлүштүн Python сыяктуу кеңири колдонулган изилдөө тилинде иштелип чыгышы.

Эмгектин негизги чектөөлөрү

Эмгек кыска форматтагы Manufacturing Letters макаласы болгондуктан архитектуранын кең масштабдуу натыйжалуулук баалоосу жүргүзүлгөн эмес.

Өзгөчө төмөнкү өлчөөлөр жетишпейт:

• учтан-учка маалымат кечигүүсү,
• timestamp синхрондоштуруу катасы,
• пакет жоготуу көрсөткүчү,
• узак мөөнөттүү система туруктуулугу,
• максималдуу бир убактагы сенсор саны,
• CPU жана RAM жүгү,
• тармак өткөрүү жөндөмдүүлүгү талабы,
• башкаруу циклинин жооп берүү убактысы,
• башка санарип архитектуралар менен сандык benchmark.

Мындан тышкары тест бир гана изилдөө WAAM уячасында жүргүзүлгөн. Ар башка бренддеги роботтор, CNC системалары, лазердик AM машиналары же өнөр жай завод тармактары ушундай эле оңой интеграциялана алары өзүнчө текшерилиши керек.

Өнөр жайда колдонууда дагы эмнелер керек?

Изилдөө лабораториясында модулдук маалымат чогултуу архитектурасын түзүү менен үзгүлтүксүз иштеген өнөр жай өндүрүш инфраструктурасы бирдей ишенимдүүлүк талаптарына ээ эмес.

Чыныгы завод колдонмосунда ошондой эле:

• колдонуучу уруксаттары,
• тармак коопсуздугу,
• өнөр жай түзмөктөрүн сертификациялоо,
• байланыш үзүлгөндө коопсуз жүрүм-турум,
• маалымат бүтүндүгү,
• камдык көчүрмө,
• версия башкаруу,
• протокол өзгөргөндө тейлөө,
• реалдуу убакыт башкаруусунун коопсуздук чектери

сыяктуу маселелер өзүнчө каралышы керек. Булак эмгек булардын баарын чечилди деп эсептебейт.

Түркиядагы өндүрүш системалары үчүн мааниси

Эмгекте Түркиядагы завод, робот же AM системасында тест жок. Ошондуктан система конкреттүү түрк өнөр жай объектинде түз иштейт деген жыйынтык чыгарууга болбойт.

Бирок изилдөөнүн негизги архитектуралык идеясы бренд жана протокол ар түрдүүлүгү жогору өндүрүш жайлары үчүн жалпы изилдөө ыкмасын сунуштайт. Мисалы, ар башка өндүрүүчүлөрдүн роботтору, ширетүү системасы, CNC, термалдык камера жана процесс сенсорлору бар уячада ар бир түзмөк үчүн өзүнчө байланыш модулу иштелип чыгып, жалпы убакыт белгиси бар маалымат катмарына өткөрүлүшү мүмкүн.

Жергиликтүү өнөр жай колдонмосунда өзгөчө колдонулган PLC/CNC/робот протоколдору, киберкоопсуздук эрежелери, реалдуу убакыт талаптары жана завод тармак инфраструктурасы үчүн өзүнчө текшерүү жүргүзүлүшү керек.

Булак жана Ыкма Эскертүүсү

Оригиналдуу изилдөөнүн толук аталышы: A proposal of a modular and customizable digital architecture for additive manufacturing

Авторлор: Kathryn Kelly, Christopher Saldana, Kyle Saleeby.

Авторлордун ирети: Булак эмгектеги ирет толугу менен сакталган.

Жооптуу автор: Kathryn Kelly.

Тең салым/тең биринчи автор: Булакта тең салым тууралуу билдирүү жок.

Мекеме 1: Georgia Institute of Technology, George W. Woodruff School of Mechanical Engineering, Atlanta, Georgia, USA.

Мекеме 2: Georgia Institute of Technology, Georgia Tech Manufacturing Institute, Atlanta, Georgia, USA.

Булак түрү: Рецензияланган кыска форматтагы изилдөө/колдонмо макаласы; Manufacturing Letters ичинде “Letters” катары жарыяланган.

Журнал: Manufacturing Letters.

Жарыялоочу: Elsevier Ltd. on behalf of Society of Manufacturing Engineers (SME).

Том: 49.

Беттер: 13–18.

DOI: 10.1016/j.mfglet.2026.06.008

Жөнөтүлгөн дата: 2 Апрель 2026.

Ревизия датасы: 2 Июнь 2026.

Кабыл алынган дата: 9 Июнь 2026.

Онлайн жарыя: 22 Июнь 2026.

Расмий DOI шилтемеси: https://doi.org/10.1016/j.mfglet.2026.06.008

Рецензия абалы: Manufacturing Letters журналынын жарыяланган рецензияланган кыска изилдөө форматы. Журналдын расмий автордук колдонмосу макалалар рецензиядан өтөрүн билдирет.

Лицензия: Creative Commons Attribution-NonCommercial 4.0 — CC BY-NC 4.0.

Preprint абалы: Каралган файл акыркы жарыяланган Manufacturing Letters макаласы.

Эксперимент системасы: Fanuc LR Mate 200iD/7L робот манипулятору, Fronius TPS 400i CMT ширетүү системасы, FLIR IR камера, төрт термопара жана Raspberry Pi.

Демонстрация: Aluminum 5183 колдонулуп, Aluminum 6061 негизинде 152,4 mm узундуктагы, беш катмарлуу бир тигиштүү WAAM дубал.

Негизги программалык архитектура: Python multi-threading, queue, logging, түзмөккө мүнөздүү handler скрипттери жана убакыт белгиси бар борбордук маалымат чогултуу.

Байланыш ыкмалары: Fanuc үчүн TCP/KAREL; Fronius үчүн OPC-UA; FLIR үчүн Ethernet/Spinnaker/PySpin; Raspberry Pi термопара системасы үчүн UDP.

Маалымат жыштыктары: Fanuc 10 Hz; Fronius 20 Hz; FLIR 30 Hz; термопаралар 10 Hz.

Убакыт синхрондоштуруу: Модулдар борбордук компьютердеги жалпы NTP убакыт шилтемесине ылайык убакыт белгисин коёт. Макалада синхрондоштуруу катасынын сандык benchmarkу берилген эмес.

Каржылоо: Макалада өзүнчө каржылоо билдирүүсү жок. CRediT салымдарында Kyle Saleeby үчүн Funding acquisition ролу көрсөтүлгөн.

Кызыкчылыктардын кагылышы: Авторлор эмгекке таасир этиши мүмкүн болгон белгилүү каржылык кызыкчылык же жеке мамиле жок экенин билдиришкен.

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.

Код жеткиликтүүлүгү: Булак макала колдонулган тест кодун Georgia Tech Manufacturing Instituteдан суроо боюнча алууга болорун жана эмгек аяктагандан кийин GTMI GitHub аккаунтунда толугу менен жарыялоо пландалганын билдирет. Бул билдирүү булак макаланын жарыяланган убактагы абалын чагылдырат.

Маалымат жеткиликтүүлүгү: Макалада өзүнчө Data Availability Statement жок. Эмгектин негизги максаты архитектураны жана үлгү маалымат агымдарын көрсөтүү.

Негизги методологиялык чек: Архитектура бир WAAM изилдөө системасында сыналган. Макалада учтан-учка latency, jitter, packet loss, NTP синхрондоштуруу катасы, ресурс колдонуу же көп сандагы сенсорлордо масштабдуулук benchmarkу жок.

Модулдуулук чеги: Архитектурага жаңы түзмөк кошуу үчүн тиешелүү сенсор/машина менен байланыша алган түзмөккө мүнөздүү Python скрипти иштелип чыгышы керек. Эмгек plug-and-play жабдык табууну сунуштабайт.

Башкаруу чеги: Борбордук компьютерден машинага маалымат жазуу мүмкүнчүлүгү архитектураны кайтарым байланыштуу башкарууда колдонууга шарт түзөт; бирок эмгекте термалдык кайтарым байланыш менен автоматтык робот оңдоосунун бөлүк сапатына таасири эксперимент аркылуу өлчөнгөн эмес.

Машиналык үйрөнүү чеги: Маалымат архитектурасын ML моделдеринде колдонууга болору талкууланган; макала өзү чогулткан маалыматта жаңы машиналык үйрөнүү моделинин натыйжалуулугун билдирбейт.

Илимий мазмун чеги: Бул Verianla текстиндеги архитектура, жабдык, байланыш протоколдору, сенсор жыштыктары, эксперимент геометриясы жана колдонуу сценарийлери оригиналдуу эмгекке негизделген. Тышкы булак библиографиялык жазууну жана журналдын рецензия абалын текшерүү үчүн гана колдонулган.