Update on Solenoid PLC Summer 2016
Solenoid PLC system update ongoing since Summer 2016 includes clock synchronization, Ethernet/ASCII communication issues, and mass flow calculation problems with proposed solutions for each. The update involves syncing the clock, addressing communication problems, and adapting mass flow calculations to ensure accurate data flow. Suggestions and feedback are welcomed.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Solenoid PLC Update: Summer 2016 (ongoing)
Solenoid Clock Sync ntp1.jlab.org 1756-EWEB(halldeweb1) module gets time from ntp1.jlab.org, one minute update interval Halldeweb1 then propagates NTP time to solenoid controller wall clock Controller wallclock propagates through all solenoid PLC chassis Set clock command inserted into the PLC to Danfysik ASCII commands. Update interval ~4 hours halldeweb1 1756 Controller wallclock MPS Comms Routine SOE
Solenoid Clock Sync, continued Problem: Ethernet/ASCII comms to set clock. The command must be processed in PLC, sent to Ethernet module, sent to NBX module, converted to ASCII, then sent and processed by Danfysik Solenoid PLC controller Solenoid Ethernet module NBX435 Module Danfysik Proposed Solution: Simulate PLC SOE time stamp and Danfysik first time stamp from all MPS/SOE common interlocks to calculate the average processing time. Use that average time to offset the actual time being sent to the Danfysik. Lots of assumptions, time can only be offset by 1 second resolution Is it necessary? We will play with this process but don t have to implement an offset as long as the delay is known Cannot try until early august
Mass Flow Calculations Problem: Mass flow program calculated VCL flow based on last received ASCII current reading from Danyfisyk. If communications is lost(like when fuse blows) the VCL flow does not update in case of dump/current change. Solution: Mass flow program now will change the current source to PXI current in situations when the ASCII current reading is not updating, it will switch back once it starts updating again. It might be better to keep the mass flow program on PXI current? Thoughts/suggestions welcome
