CCR and VPL Uses RRS feed

  • Question

  • I've been pouring over the MRDS for the past two days at work and it got me thinking.  I deal with automation that typically has vendor supplied software(Agilent Technologies, High Res Bio, Beckman Coulter, Hamilton are a few) which controls their lab research equipment ranging from small single purpose devices to complex automated robot work cells that might comprise many of these small devices.  Could VPL and CCR be developed to run these cells which have many processes to perform during operation (pick plate from here and place there, dispense liquid into plate, move plate here, perform shaking action, etc).  The whole purpose is to develop a single framework/common platform from which all systems throughout the R&D organization can use in lieu of many vendor supplied solutions on many different machines.  Thank you for responding

    Jeff Nagle

    Saturday, March 8, 2014 5:00 AM

All replies

  • Hi, Jeff.

    First of all, I am not in a good position to answer your question, I have not tried VPL and I have not adapted existing hardware to DSS. By now I am focused on simulation and programming robots inside it. But anyway I do not see hordes of developers willing to answer.

    MRDS consists of four distinct parts:

    1. CCR - that is for concurrency and coordination, they say that it is superseded by TPL in last versions of .Net framework, that it was TPL predecessor. I know for sure that it is powerful, it is hard to learn and yield returns are awkward and deprive me of return values in normal way (await/async in TPL is redemption)

    2. DSS - that's for services, every program is service, services can talk to each other, find each other, stop each other, etc. So DSS is dsshost that runs user services, all necessary infrastructural services and technology to create such services (which are inherently concurrent and use CCR for that reason)

    3. Simulation engine - that's for simulation, special service that allows to simulate real world physics

    4. VPL - that's for the people who are afraid of (reasonably) CCR and DSS and C#. I still don't know either anybody has managed to craft anything of production quality using VPL.

    To accomplish your task you need to adapt every device to DSS (so that you can control it), i.e create a service communicating with the device with the help of vendor supplied drivers and utilities. That requires deep understanding of DSS and CRR (so somebody is going to have to study it thoroughly) and of these devices too. That's an investment.
    The concurrent code will be written with hard to grasp, little bit obsolete, but capable CRR (you need a strong developer). By the way I don't know, if it is possible to use MRDS with .net 4.5, I am going to find it out (seems that not).
    You isn't going to use simulation engine, so no value in it.
    And when you're done adapting your devices to MRDS you expect to pass the system to less coding guys to program processes on VPL, don't you? So, the main question is if there exists a VPL success story.

    Personally I like and use MRDS much. You can harness it, but it will take time and diligence. My answer will hardly help, but here it is.


    Wednesday, March 12, 2014 6:35 PM
  • Hi Jeff,

    All excellent questions and concerns.  I encourage you to heed Matvey's advice and might add the following:

    1.  VPL is an excellent tool for simple proof-of-concept efforts.  However, it is not well suited for complex scenarios.  Although it will hide many of the gory details of how the CCR/DSS work behind the scenes, there within lies the problem.  Even the RDS team, documentation, and this forum suggest limited use of the VPL tool.  Regardless, it is a pretty cool tool for getting something working lickidy splick, especially if you're wanting a deployment across multiple nodes/computers.

    2.  I can understand your vision of wanting a single framework/platform to integrate your physical devices across the enterprise with what is usually a data driven business process.  It is impressive that you are pondering such a solution seeing how most industrial automationists' event horizons flat line with anything beyond a desktop application.  I'm just being honest here.  However, said enterprise vision can be achieved and is exactly what I've done with my NOMAD City framework built entirely from RDS.  This is not some vaporware dream, as I have developed production implementations using NOMAD City for clients such as Boeing, SRS Medical, and FIAlab Instruments.  I am currently working on a project at Agilent Technologies in Santa Clara, CA that will use NOMAD City components to integrate the GC/MS products with their OpenLab platform.  I would be happy to discuss the NOMAD City platform with you in greater detail.

    3.  Matvey's suggestion to embrace TPL is a good one.  For starters, the support for TPL (as compared to RDS) is much better.  And by better, I mean MUCH better.  Also, because it descended from CCR, it's followed a natural evolution of being easier to understand/implement/market than its ancestors.  Again, just being honest.

    Hope some of the above garbly goo helps in some way/shape/form.  I realize I've mostly generalized stuff, but feel free to ask for more detail.


    Dennis M. Knippel

    Friday, March 14, 2014 8:06 PM