DnD vs Labview.

1
DnD vs Labview.

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

2
DnD vs Labview.

• DnD and Labview has similair structure and
  appearance
• Interactive Builder
• Runtime (integrated with Builder for Labview)?
• Component Libraries
• Web Interface (Dnd)?

3
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,

4
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

5
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

6
What do we need to bring DnD closer to being
accepted at LHC

• Better craft CERN requirements
• Component libraries more computational pipes,
  including JMathLib, Beanshell, Jython and, may
  be, Jruby
• Refactoring source code, writing additional
  documentation, tutorials, tests
• Main we need at least one enthusiast on CERN
  side

7
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 reprentation
• - Remote debugging / monitoring of layers

8
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 !!!

9
We should use Open Tools!!!

10
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, ...

11
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

12
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.

13
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.