Difference between revisions of "Slow controls"

From GlueXWiki
Jump to: navigation, search
(EPICS on Linux)
(VME based)
Line 29: Line 29:
 
=== VME based ===  
 
=== VME based ===  
  
* This approach would require a VME crate with a controller and an OMS motor driver card.  
+
* This approach would require two VME crate with a controller in each (one in tagger hall and one in Hall D) and OMS motor driver cards.  
 
* Currently we are trying to avoid VME based systems, but harp applications need to have a VME scaler module. Therefore, for harp systems this would be a convenient way of doing it since the motor and the scaler module can be easily synchronized through a single VME bus.  
 
* Currently we are trying to avoid VME based systems, but harp applications need to have a VME scaler module. Therefore, for harp systems this would be a convenient way of doing it since the motor and the scaler module can be easily synchronized through a single VME bus.  
 
* Software from other halls and accelerator division can be used  saving us on labor cost.
 
* Software from other halls and accelerator division can be used  saving us on labor cost.
 
* The hardware cost can be  high ~ $???? for a VME crate and 4 cards.  
 
* The hardware cost can be  high ~ $???? for a VME crate and 4 cards.  
* Software development cost is probably going to be low.  
+
* Software development cost is probably going to be low.
 
+
  
 
=== PLC based ===  
 
=== PLC based ===  

Revision as of 12:05, 19 April 2011

General


EPICS on Linux

Motor Applications

We need to plan for the following motor-based applications:\

  • Goniometer (5 axis)
  • Tagger harp (1 axis)
  • Tagger dump harp (1 axis)
  • Tagger microscope (4 axis)
  • Collimator table (1 axis)
  • Converter/photon harp (1 axis)
  • TAC (1 axis) ?
  • Gamma profiler (1 axis) ?

This means 11 axes in tagger hall, 4 axes in the hall. We can consider the three options shown below.

VME based

  • This approach would require two VME crate with a controller in each (one in tagger hall and one in Hall D) and OMS motor driver cards.
  • Currently we are trying to avoid VME based systems, but harp applications need to have a VME scaler module. Therefore, for harp systems this would be a convenient way of doing it since the motor and the scaler module can be easily synchronized through a single VME bus.
  • Software from other halls and accelerator division can be used saving us on labor cost.
  • The hardware cost can be high ~ $???? for a VME crate and 4 cards.
  • Software development cost is probably going to be low.

PLC based

  • PLC may be the cheapest way of doing it. For 18 axes of motion we probably will need about $16K; $14K for 9 AMCI 3202 modules for 1756, and approximately $2K for a 1756 chassis with a communication module.
  • We will need to develop the software nearly from scratch.
  • Implementing harp scans can be problematic because of the synchronization issue between the scalers and the motor read-backs.


Newport XPS based

  • A new module for controlling multiple motor drivers from Newport with Newport XPS-DRV00 pass-through cards can be used.
  • This approached apparently is not used in JLab.
  • Mark Rivers uses these devices at APS and he developed EPICS support for this. In fact his SNL applications is probably directly usable for us, so little software development would be needed for this. He is using the pulse output from XPS to strobe the scaler module, and keeps the positions of the motors (encoders) in XPS to later synchronize with the scaler FIFO values. This is exactly what we are looking for.
  • Mark Rivers is working on changing this application to work without state code.
  • This is an expensive option. The price for 3 XPS-C6 units fully equipped with six XPS-DRV00 cards would cost us $23K.
  • Software development cost is probably going to be low since we can nearly copy APS' application.

PLC