Update on Solenoid PLC Summer 2016
Solenoid PLC Update: Summer
2016 (ongoing)
Solenoid Clock Sync
•
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
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
•
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…
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.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
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.
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
