How do I best upgrade a multiworkstation app using DSC from LV7.2 to 8.6?

[Kevin_R]

I have an extended, properly functioning process control and data acquisition application running across multiple workstations (roughly 10). The workstations share information with each other and with process controllers via DSC and OPC.

We're currently running at version 7.1, and this spring we want to update to the current version of Labview (which, by then, will be 8.6.1; we are on the SSP).

I understand that the tag engine/database have changed significantly between 7.1 and the current version of the DSC, and wonder if there is a good roadmap for executing this upgrade to minimize downtime on our tool?

[Ben]

I can't point at a doc but I have been through this and it wasn't easy or fast.

You can save yourself some grief if you can forget about the history since this has to be converted.

The rest of the game... really depends on what your appliation does and finding the new widget that replace the old widget.

Some more details what the application is doing and what parts of DSC it was using to accomplish those task will help us help you.

Take care,

Ben

[Kevin_R]

Hi Ben -- we do not log history or events in the DSC, so that is not an issue.

The application is controlling a multi-chamber (7 connected vacuum chambers arranged in a star configuration) thin film deposition system. The basic control, interlocks, and safety/process security of the vacuum components is done via a series of Opto22 "brains", which are essentially simple processors running programs to control IO for valves and temperature control systems. They communicate with each other via Ethernet.

There is an OPC server for the Opto22 brains, which runs on one workstation dedicated to use as a gateway between LabVIEW and the network of brains. A DSC tag database is set up on that machine to access some of the IO states and variables in the brains, and then the other workstations have tag databases that reference those tags (the brains' communications interfaces can be overwhelmed if too many workstations access them simultaneously, so we use a single workstation as the gateway).  Via the gateway, a workstation may read/manipulate some of the io states directly, and make other requests of the brains' software by setting flag variables in the strategies running therein.

Each chamber also has a complex motion control system for process manipulation, as well as extensive serial/parallel communications to control the gas systems, deposition power supplies, etc.  The process software on each workstation makes available a "snapshot" of its process state available via memory tags in the DSC, so that the workstation controlling the central chamber can detect when a task in an outer chamber is completed and move samples between the different chambers.

All the workstations, brains, and motion control systems are interconnected via an Ethernet network independent of our building intranet. There is one additional workstation that maintains a process database, where each workstation can record each process task and the samples affected by it.

Everything is working at this point, but we recognize that we are overdue to bring the system up to the current level.

In particular, guidance as to a possible way to upgrade the gateway tag DSC database and then the others referencing it in advance of recompiling all the software, if that is possible.

[Ben]

At this point I'm not convinced that DSC is required because non-DSC LV can read and write datasockets to exchange info between the nodes.

I recomend to call support and ask them about a utility to convert your tags to Shared Variables for use with DSC if you choose that route.

Ben

[Kevin_R]

We started with just Datasocket connections.

We're now dealing with several hundred process states and tags, and at least in LV 7.1, the built-in datasocket was incapable of dealing with the load.

Also, we're using the DSC as an OPC client to talk to the OptoOPC server as well as to exchange data between the workstations.

[Ben]

---

Kevin R wrote:
We started with just Datasocket connections.

We're now dealing with several hundred process states and tags, and at least in LV 7.1, the built-in datasocket was incapable of dealing with the load.

Also, we're using the DSC as an OPC client to talk to the OptoOPC server as well as to exchange data between the workstations.

---

Are you sitting down? I ask because I'm going to stay stuff that you may not like.

A high channel count app was one of the reasons for using DSC because its tag engine did not suffer from the ailment that datasockets did in that there load on the CPU scaled linearly with the tag count.

With LV 8 and above the Tag engine was repalced with the shared variable manager or something related.

Since that time I can no longer find the white paper that compared datasocket reads and writes with the Tag Engine or with shared vaibles. So I can no longer state confidently that DSC will be able to out-perform an equivelent number of datasocket connections. (I'll ask for NI support chime in to stomp on this if I am wrong).

In older verson of LV DSC was required to work with OPC servers but if your optoOPC offers data socket access, DSC may no be required.

Just rying to help,

Ben

PS Standby for an NI support engineer to reply regarding speed of tags vs datasockets)

[Kevin_R]

---

Ben wrote:

---

Kevin R wrote:
We started with just Datasocket connections.

We're now dealing with several hundred process states and tags, and at least in LV 7.1, the built-in datasocket was incapable of dealing with the load.

Also, we're using the DSC as an OPC client to talk to the OptoOPC server as well as to exchange data between the workstations.

---

Are you sitting down? I ask because I'm going to stay stuff that you may not like.

A high channel count app was one of the reasons for using DSC because its tag engine did not suffer from the ailment that datasockets did in that there load on the CPU scaled linearly with the tag count.

With LV 8 and above the Tag engine was repalced with the shared variable manager or something related.

---

Actually Ben, you're getting to just the sort of issues I need to know before starting the upgrade.    If there is a newer, better way to do it, then that's the upgrade path to pursue.  

I'll be curious to see what NI may have to say on the subject.

Thanks for your input so far.

[hecmar.arreola]

If v7.2 is stable for you I would wait until NI makes v8.6 stable until upgrading.  LabVIEW 8.2 was probably the best LabVIEW v8 version as far as stability goes.  I don't think you can get v8.2.

[Kevin_R]

We're subscribed to the SSP, so I have copies of every version released since we subscribed.

We can go from 7.1 (technically 7.11) as far up the version chain as we decide is wise.