1. f Antiproton Source Embedded Systems and Hardware Support Presented to Controls Working Group November 19, 2003 by Dave Peterson Pbar Engineering Group Leader

2. f November 19, 2003Controls Working Group D. Peterson2 Things other than Applications The way we were Where we are now –Embedded Systems –Other Special Equipment Where we want to be –A sampling of project needs –A Wish List Thoughts and Comments

3. f November 19, 2003Controls Working Group D. Peterson3 A Bit of (my view of Pbar Controls) History In the beginning there was CAMAC and Multibus. –Just about anything else was specially built. –Controls Group provided connection all the way to the field devices (e.g. Beechy Boxes). Then came programmable logic, PALs, PLAs and eventually FPGAs. –Now a single card layout could do many things. –Modification was easy. –Many more field interfaces were built by Pbar (e.g. Power Supply and RF interlocks). The rise and fall and eventual rise of Microcontrollers. –Easier to sequence than PALs. –Required large effort in hardware and software. (The saga of the 058.) –Not always very reliable. –Now tools have become much easier to use. LabVIEW automates bench testing. –Allowed almost anyone to control devices and gather measurements. –Packaged functions save enormous amounts of time. –1 engineer * LabVIEW * 3 weeks = 2 programmers * Pascal * 6 months Programmable Logic Controllers (PLCs) save the day. –PET accelerator vacuum, water and magnets run by two PLCs. –They proved to be inexpensive, robust and flexible. –For these Pbar now handles everything past the end of the Ethernet cable. Ethernet and the Web go everywhere. –Devices communicate quickly. –The parameter page isn’t the only way to see devices.

4. f November 19, 2003Controls Working Group D. Peterson4 Pbar Embedded Systems VME –PBVAC, PBCOOL, BAKER, DRF1, AP0PLC, MWAP10 –AP1001, AP1002, AP5001 –ACCLLRF, E760 LLRF –4 TWT Protection –12 BPM –1 IRM? LabVIEW –Flying Wires? –Damper Measurements –Data logging and beam loss notification –Vacuum bakeout supervision –Fermi Weather Station serial to file converter TDS7000 Scope running Windows 2 Vector Signal Analyzers (VSA) 16 PLCs (www.automationdirect.com)www.automationdirect.com 2 Rabbits (www.zworld.com)www.zworld.com Serial –Microcontroller for Signal Multiplexer via OptiLogic unit –GPS receiver via VME 2 Shutter controllers running Basic

5. f November 19, 2003Controls Working Group D. Peterson5 Other Special Equipment 13 Tektronix TDS3000 Ethernet Scopes (11 dedicated, 2 rovers) GPIB –7 Keithley Voltmeters –4 HP Spectrum Analyzers –2 HP Network Analyzers –2 RF Synthesizers –1 Scope –1 Dynamic Signal Analyzer –1 Universal Counter –1 NMR Teslameter Stepper Motors –CAMAC 057 controlled (31 cards, up to 16 motors per card). –PLC controlled (20 motors now, 40 more on the way). 5 BCD Devices

6. f November 19, 2003Controls Working Group D. Peterson6 The Needs of Future Projects Data acquisition (primarily for beam lines) –Fairly fast (10 - 200Msamples/sec). –Often doesn’t need much memory (a few thousand samples). –Simultaneous channels. An example of a commercial product: http://www.scalaracquisitiontechnology.com/data-acquisition/sat14.htm –Application support for uniformity. Embedded Systems –Support for a variety of commercial cards. –Hard real time processing. –User configurable. –Accelerator state awareness.

7. f November 19, 2003Controls Working Group D. Peterson7 Wish List Scope measurement applications. Interprocess communications for small systems. Machine states available to sub-systems (similar to MDAT?). Would like something smaller and simpler than VME. –Although they are like cute little hairless Furbies ®, sometimes PLCs just aren’t suitable. –I might not need to put a VME crate where I only need a few channels or maybe the channels are distributed far and wide. –Too bad HPIE died. It had time synch and mini VxWorks. Would like to avoid front end tasks in time critical systems (call it “demoocification”). Interactive Graphics.

8. f November 19, 2003Controls Working Group D. Peterson8 Thoughts & Comments Can there be really be standardized hardware and software? –It often helps reduce duplication of effort but sometimes a little competition is healthy. –It is necessary to maintain some variety since one size does not always fit all. –How do I find out what is already in use here? Commercially available devices are becoming smarter, faster, cheaper and networked. Many networked devices have similar protocols. (Well, at least the simple ones I use.) It seems the equipment end becomes a communications issue rather than a hardware issue. Support through OACs seems to be the way to go. The two extremes of utilization –The rapidly deployable diagnostic tools (such as Ethernet scopes). –The inexpensive, specific function systems (such as aspirin under a microswitch).