ONS Instruction Not Energizing OTE in Studio 5000 Ladder Logic — figure 1

Arahan ONS Tidak Mengaktifkan OTE dalam Logik Tangga Studio 5000

Arahan ONS tercetus tetapi gegelung OTE tidak pernah terkunci dalam Studio 5000 kerana one-shot hanya benar untuk satu imbasan. Gunakan OTL/OTU atau logik pe...

Monitor dalam talian kadangkala menunjukkan bit storan ONS berubah keadaan, sedangkan OTE yang dimaksudkan tidak pernah kelihatan mengaktifkan penghidup pam atau solenoid. Dalam Studio 5000 Logix Designer, ini biasanya bukan disebabkan kad output yang rosak. ONS ialah pengesan pinggir menaik yang hanya bernilai benar untuk satu penilaian rutin. OTE menulis keadaan rungnya pada setiap imbasan tanpa pengunci dalaman. Apabila kedua-duanya dipasangkan secara terus, anda menghasilkan denyutan satu imbasan—selalunya 5–20 ms—yang secara praktikal diabaikan oleh kontaktor, VFD, malah animasi HMI, manakala kadar paparan IDE yang lebih perlahan terlepas denyutan itu sepenuhnya.

Arahan ONS Tidak Mengaktifkan OTE dalam Logik Tangga Studio 5000 — rajah 1

Intuisi logik geganti tidak terpakai di sini: penulisan Logix selama 10 ms tidak sama dengan sesentuh tambahan yang dikekalkan.

Fizik imbasan

Imbasan Pinggir input Output ONS Tag OTE
n-1 0 0 0
n 0→1 1 1 (satu imbasan)
n+1 1 0 0
n+2 1 0 0

Penghidup sebenar biasanya memerlukan arahan kukuh selama 50–100 ms. Laluan ONS→OTE tunggal tidak dapat menyediakannya. Tetingkap pemantauan Studio 5000 mengambil sampel jauh lebih perlahan daripada tempoh tugas, jadi kebarangkalian untuk menangkap denyutan 10 ms adalah rendah—menyebabkan timbulnya mitos bahawa “ONS tidak pernah terpicu.”

Peregangan diagnostik

  • TOF selari (praset 1–2 s) pada peristiwa ONS; pantau .TT/.DN dalam IDE
  • Tambah 1.0 pada pembilang REAL bagi setiap pinggir; jejak kiraan tersebut
  • Gunakan Studio Trend dengan sampel kira-kira 10 ms pada tag OTE untuk melihat kitar tugas sebenar
Arahan ONS Tidak Mengaktifkan OTE dalam Logik Tangga Studio 5000 — rajah 2

Corak penguncian atau OTL/OTU menukarkan keputusan satu detik kepada arahan operasi yang berterusan.

Penyelesaian A — OTL / OTU

[Pump1_RunCmd_ONS] ----(OTL Pump1_RunCmd)
[Pump1_Stop_PB]    ----(OTU Pump1_RunCmd)
[Pump1_Fault]      ----(OTU Pump1_RunCmd)

Ingat bahawa pengunci kekal merentasi kitaran kuasa secara lalai. Tambahkan tetapan semula pada imbasan pertama atau semasa penyelenggaraan untuk output yang tidak boleh menghidupkan semula motor selepas but semula.

Penyelesaian B — penguncian kendiri di sekeliling OTE

|--[Start_ONS]-+----------(OTE RunCmd)--|
|              |                        |
|--[RunCmd]----+                        |
|--[Stop_PB]---/                        |

Ini ialah analogi penghidup tiga wayar yang disokong secara meluas dalam amalan pengaturcaraan Logix: ONS menyediakan pinggir mula; sesentuh RunCmd yang dikunci mengekalkan OTE sehingga henti atau interlok membuka laluan.

Penyelesaian C — bit keadaan serta OTE arahan

Untuk peralatan berjujukan, gunakan OTL pada langkah Selected apabila pinggir berlaku, gerakkan OTE Start semasa Selected aktif dan maklum balas Running tidak aktif, kemudian gunakan OTU pada Selected apabila maklum balas diterima. HMI masih melihat arahan Start sebenar sementara pengunci mengawal langkah tersebut.

Konteks utama/sandaran dan perangkap

Pensiri pam berdasarkan jam operasi biasanya menyalahgunakan ONS pada perbandingan “pam ini kini menjadi utama”. Selepas membetulkan struktur pinggir-ke-arahan, tambahkan pemasa operasi minimum (pencegahan kitaran pendek), perencat putaran pam utama, dan laluan OTU ketika berlaku kerosakan. Buat rujukan silang pada tag OTE untuk mengesan gegelung pendua yang muncul kemudian dalam imbasan dan secara senyap menulis ganti nilai 1 yang telah dikunci dengan 0. Utamakan satu pemilik gegelung bagi setiap BOOL.

Periksa juga topologi cabang: laluan selari yang memintas ONS boleh menyebabkan OTE kekal palsu walaupun bit storan berkelip, dan rutin kedua yang menulis BOOL yang sama boleh membatalkan penguncian kendiri yang sempurna satu tugas kemudian. Apabila beberapa pengguna memerlukan denyutan tersebut, gerakkan satu BOOL perantaraan daripada ONS sekali sahaja, kemudian sebarkan logik yang dikunci atau dilatch daripada bit itu.

// Peregangan sementara — buang sebelum pentauliahan akhir
[Pump1_Start_ONS] ---(TOF Stretch_Timer, 2.0 s)
[Stretch_Timer.TT] ---(OTE Diagnostic_Stretch_On)

Dengan peregangan ini, Diagnostic_Stretch_On kekal kelihatan dalam IDE dan pada penunjuk berkelip HMI, sekali gus membuktikan kadar pinggir sebelum anda mempercayai logik penguncian kendiri pengeluaran. Padamkan atau nyahaktifkan laluan diagnostik selepas FAT supaya operator tidak terus memburu lampu servis yang kekal menyala.

Gunakan peraturan pemilikan ini secara konsisten merentas platform PLC dan PAC supaya suntingan syif malam tidak memperkenalkan semula rung ONS→OTE tanpa pengunci dalam pakej seterusnya.

Tentang Penulis

Mark Townsend | Jurutera Automasi Kanan – Sistem Allen-Bradley

Mark Townsend ialah jurutera automasi kanan dengan pengalaman lebih 18 tahun menggunakan platform Allen-Bradley, merangkumi ControlLogix, CompactLogix dan SLC-500 legasi. Tugas hariannya melibatkan logik RSLogix / Studio 5000 serta pelancaran HMI FactoryTalk View pada sistem lama dan armada campuran.

Arahan ONS Tidak Mengaktifkan OTE dalam Logik Tangga Studio 5000

Arahan ONS tercetus tetapi gegelung OTE tidak pernah terkunci dalam Studio 5000 kerana one-shot hanya benar untuk satu imbasan. Gunakan OTL/OTU atau logik pengekalan sebaliknya.

Monitor dalam talian kadangkala menunjukkan bit storan ONS berubah keadaan, sedangkan OTE yang dimaksudkan tidak pernah kelihatan mengaktifkan penghidup pam atau solenoid. Dalam Studio 5000 Logix Designer, ini biasanya bukan disebabkan kad output yang rosak. ONS ialah pengesan pinggir menaik yang hanya bernilai benar untuk satu penilaian rutin. OTE menulis keadaan rungnya pada setiap imbasan tanpa pengunci dalaman. Apabila kedua-duanya dipasangkan secara terus, anda menghasilkan denyutan satu imbasan—selalunya 5–20 ms—yang secara praktikal diabaikan oleh kontaktor, VFD, malah animasi HMI, manakala kadar paparan IDE yang lebih perlahan terlepas denyutan itu sepenuhnya.

Arahan ONS Tidak Mengaktifkan OTE dalam Logik Tangga Studio 5000 — rajah 1

Intuisi logik geganti tidak terpakai di sini: penulisan Logix selama 10 ms tidak sama dengan sesentuh tambahan yang dikekalkan.

Fizik imbasan

Imbasan Pinggir input Output ONS Tag OTE
n-1 0 0 0
n 0→1 1 1 (satu imbasan)
n+1 1 0 0
n+2 1 0 0

Penghidup sebenar biasanya memerlukan arahan kukuh selama 50–100 ms. Laluan ONS→OTE tunggal tidak dapat menyediakannya. Tetingkap pemantauan Studio 5000 mengambil sampel jauh lebih perlahan daripada tempoh tugas, jadi kebarangkalian untuk menangkap denyutan 10 ms adalah rendah—menyebabkan timbulnya mitos bahawa “ONS tidak pernah terpicu.”

Peregangan diagnostik

  • TOF selari (praset 1–2 s) pada peristiwa ONS; pantau .TT/.DN dalam IDE
  • Tambah 1.0 pada pembilang REAL bagi setiap pinggir; jejak kiraan tersebut
  • Gunakan Studio Trend dengan sampel kira-kira 10 ms pada tag OTE untuk melihat kitar tugas sebenar
Arahan ONS Tidak Mengaktifkan OTE dalam Logik Tangga Studio 5000 — rajah 2

Corak penguncian atau OTL/OTU menukarkan keputusan satu detik kepada arahan operasi yang berterusan.

Penyelesaian A — OTL / OTU

[Pump1_RunCmd_ONS] ----(OTL Pump1_RunCmd)
[Pump1_Stop_PB]    ----(OTU Pump1_RunCmd)
[Pump1_Fault]      ----(OTU Pump1_RunCmd)

Ingat bahawa pengunci kekal merentasi kitaran kuasa secara lalai. Tambahkan tetapan semula pada imbasan pertama atau semasa penyelenggaraan untuk output yang tidak boleh menghidupkan semula motor selepas but semula.

Penyelesaian B — penguncian kendiri di sekeliling OTE

|--[Start_ONS]-+----------(OTE RunCmd)--|
|              |                        |
|--[RunCmd]----+                        |
|--[Stop_PB]---/                        |

Ini ialah analogi penghidup tiga wayar yang disokong secara meluas dalam amalan pengaturcaraan Logix: ONS menyediakan pinggir mula; sesentuh RunCmd yang dikunci mengekalkan OTE sehingga henti atau interlok membuka laluan.

Penyelesaian C — bit keadaan serta OTE arahan

Untuk peralatan berjujukan, gunakan OTL pada langkah Selected apabila pinggir berlaku, gerakkan OTE Start semasa Selected aktif dan maklum balas Running tidak aktif, kemudian gunakan OTU pada Selected apabila maklum balas diterima. HMI masih melihat arahan Start sebenar sementara pengunci mengawal langkah tersebut.

Konteks utama/sandaran dan perangkap

Pensiri pam berdasarkan jam operasi biasanya menyalahgunakan ONS pada perbandingan “pam ini kini menjadi utama”. Selepas membetulkan struktur pinggir-ke-arahan, tambahkan pemasa operasi minimum (pencegahan kitaran pendek), perencat putaran pam utama, dan laluan OTU ketika berlaku kerosakan. Buat rujukan silang pada tag OTE untuk mengesan gegelung pendua yang muncul kemudian dalam imbasan dan secara senyap menulis ganti nilai 1 yang telah dikunci dengan 0. Utamakan satu pemilik gegelung bagi setiap BOOL.

Periksa juga topologi cabang: laluan selari yang memintas ONS boleh menyebabkan OTE kekal palsu walaupun bit storan berkelip, dan rutin kedua yang menulis BOOL yang sama boleh membatalkan penguncian kendiri yang sempurna satu tugas kemudian. Apabila beberapa pengguna memerlukan denyutan tersebut, gerakkan satu BOOL perantaraan daripada ONS sekali sahaja, kemudian sebarkan logik yang dikunci atau dilatch daripada bit itu.

// Peregangan sementara — buang sebelum pentauliahan akhir
[Pump1_Start_ONS] ---(TOF Stretch_Timer, 2.0 s)
[Stretch_Timer.TT] ---(OTE Diagnostic_Stretch_On)

Dengan peregangan ini, Diagnostic_Stretch_On kekal kelihatan dalam IDE dan pada penunjuk berkelip HMI, sekali gus membuktikan kadar pinggir sebelum anda mempercayai logik penguncian kendiri pengeluaran. Padamkan atau nyahaktifkan laluan diagnostik selepas FAT supaya operator tidak terus memburu lampu servis yang kekal menyala.

Gunakan peraturan pemilikan ini secara konsisten merentas platform PLC dan PAC supaya suntingan syif malam tidak memperkenalkan semula rung ONS→OTE tanpa pengunci dalam pakej seterusnya.

Tentang Penulis

Mark Townsend | Jurutera Automasi Kanan – Sistem Allen-Bradley

Mark Townsend ialah jurutera automasi kanan dengan pengalaman lebih 18 tahun menggunakan platform Allen-Bradley, merangkumi ControlLogix, CompactLogix dan SLC-500 legasi. Tugas hariannya melibatkan logik RSLogix / Studio 5000 serta pelancaran HMI FactoryTalk View pada sistem lama dan armada campuran.

Tinggalkan komen

Sila ambil perhatian, komen perlu diluluskan sebelum ia diterbitkan.