DnD vs Labview. How Dnd can substitute Labview in LHC control system, what needs to be done. Timofei B. Bolshakov, James F. Patrick

DnD vs Labview. DnD and Labview has similair structure and appearance:  Interactive Builder  Runtime (integrated with Builder for Labview) ‏  Component Libraries  Web Interface (Dnd) ‏

Strength Dnd - Integration into control system: security,  safety,  logging,  control over source,  retrofitting old lib's  Web interface Labview – support of National Instruments:  code quality,  support + documentation,  hardware drivers,  publicity,  experienced users,  rich components library

Weakness Dnd – small group of developers: documentation,  training,  code quality  component library should be extended  uncertainty Labview – is too general, market is different:  model – not aimed for integration  price (and you still need specialists !) ‏  slower development cycle  experienced users :-) ‏  National Instruments

Why some of Labview strongest points are not important. Experienced users may bring much harm – fast prototyping of not integrated projects brings tremendous risk Device drivers does not matter, because all of the devices should be controlled by FESA Commercial companies have their own life and view on the future of products, LHC should work and be upgradable for decades

What do we need to bring DnD closer to being accepted at LHC Better understand CERN requirements and applications where DnD should be used. Component libraries – more computational pipes, including JMathLib, Beanshell Refactoring source code, writing additional documentation, tutorials, tests Main – we need at least one enthusiast on CERN side

CERN Requirements. Several CERN concerns were not addressed in Requirements document:  - Ability to release the DnD project as self-contained web startable application  - Save project in standard CVS, versioning  - Layered representation  - Remote debugging / monitoring of layers

Component libraries. At first glance this is a big problem, in reality it is NOT. Most used components does not include complicated transforms. Complicated transforms are EASY to include: JMathLib (analog of MatCad), Beanshell (interpreted Java), other scripting languages. Scripts should not dominate the scene !!!

We should use Open Tools!!!

Component libraries. What should be really included:  - Bitmap picture as background  - Limited amount of scripts (should be discussed and specified) ‏  - Layering with JMS interface to layers (should be used the CERN one – JAPC monitoring) ‏  - new Plotting components : JdataViewer (may be modified), 3D from JmathLib,...

Component libraries. What people really demand (our experience):  - Highly tuned “special engineering symbols” : look at cryo library  - Extended support of all aspects of control system.  - Better / Standard plotting package

CERN support. DnD should not substitute Labview in general, it should substitute Labview in concrete CERN/LHC environment. Only insiders can tell what components CERN need. And as detailed as possible. Software should be used ASAP. And users should apply pressure on developers.

Conclusions Unregulated and uncontrolled Labview projects will be a disaster (FNAL operators experience). Labview projects are HARD to document (FNAL instrumentation group experience). Component Libraries are not the Show Stopper. DnD will not be useful without the really strong support from CERN side.