WIll using a multiprocessor system improve DSC Tag Engine performance?

[Kevin_R]

We are developing a multiple workstation vacuum chamber automation control application using the DSC.

The chambers under control each have a set of process controllers (Opto22 "Ultimate Brains") running the fundamental interlock and process mechanisms via their own software. The brains are set up for communication via OPC, thus LabVIEW can monitor the IO states of the system as well as variable values in the brain software via DSC tags. In addition, LV can manipulate variables to make requests that the brain software branch to different subroutines. The other ("control") workstations in the system pass requests to the brains via the software on the monitoring workstation, so as to ensure that requests are enqueued properly.

The problem is at this point there are 1300 tags configured for the DSC, and the workstation responsible for monitoring them shows near 100% CPU load all the time; most of that taken by the DSC Engine. This is with only half of the final project's chambers installed and active. As a result, it sometimes takes several attempts for a control workstation to successfully pass a request to the brains via the monitoring workstation.

We are concerned that performance will only worsen as we bring the additional chambers online.

Would adding a second processor to the workstation improve performance? If dual processors would help, would additional processors help more?

Note: we are examining which tags we monitor all the time and are going to try to reduce that list to those tags critical for normal operation, with an option to temporarily expand monitoring to the larger list for debugging purposes. I am concerned that even if that helps now, the problem will get worse again as we bring additional components on line. Is it the sheer number of tags defined for the DSC engine that gates the load on the engine, or the number that we are actively reading with our program?

Thanks for any illumination you can offer.

Kevin R

[Vineet_A.]

Hello Kevin,

The only thing limiting number of tags in LabVIEW DSC are system resources. Memory and CPU speeds play a large part of that, so using a multiprocessor system should improve performance. I'm honestly not sure how much of an improvement will happen, but since LabVIEW 7.1 is optimized for multiprocessor execution, LabVIEW DSC should show some improvement.

It sounds like your best bet is just to try it out.

Does anyone else have any experience with LabVIEW DSC on multiprocessor systems?

Regards,
Vineet A.

[Kevin_R]

I have a partial answer. We've swapped in the dual processor machine and see some improvement. The processor load was still hovering around 100%, though.

More importantly, we think we've learned something about how the DSC engine is actually working. The monitoring workstation not only runs the DSC engine to trade data with the other workstations, but an OPC server to handle transactions with the "brains". So any requests for data from the brains really are routed via the monitoring workstation.

We had built one common tag database because we thought that would simplify programming. We did some tests today, however, and discovered that if we stop the tag engines on the control workstations, processor load drops dramatically on the monitoring workstation.

What we've realized is that apparently if a read tag exists in a machine's database, the DSC fetches its value, regardless of whether our LabVIEW software ever actually uses the value. We deleted most of the brain tags from the control workstation databases, leaving only the LV memory tags and the few brain tags actually used by our vis. So now the monitoring workstation is not being asked to query those 1000 tags by 3 different tag engines, only by the one using it.

CPU load is down to about 73% now (because the monitoring workstation is still itself watching those 1000 tags). That's still high, but we have a better idea what is going on.

So -- is there any way to have the DSC engine only fetch a tag value when you really need it, rather than always fetching every tag in the database?

[unclebump]

I have a rather large DSC application that uses 2700 tags inside the Kepware OPC server. The computer has 512Meg of ram, 800Mhz processor and windows 2000. Task manager shows 50-75% processor usage. Task manager shows DSCengine uses 57Meg, Labview 47Meg, Citadel 15Meg, Kepware 14Meg. I am using ethernet communication to four Modicon Momentum plc's. I have the ethernet card, in the computer, setup as multihomed. It has four addresses assigned to it. Each plc writes data to an individual ip address. The plc's use the I/O scanner feature to transmit the data directly into Kepware without Kepware having to read it from the plc. I am not continuously reading all of this data out of the tag engine. I use it for stripcharting purposes. When a cycle ends, I read a large block of tags and display it on a graph. I had to add CRC-32 checksums to the data in the plc. Then I have labview read the source data until the labview calculated checksum matches the checksum generated in the plc logic. Usually this takes 1-3 reads. I use binary string memory tags to store the stripchart array inside the Citadel database. I have this running on both Labview 6.1 and 7.0. My largest application will have around 9000 tags when I get around to programming it. Right now I use array data format for all of the graphic display. I want to switch to waveform data and use the mask and limit testing for profile checking. I am running into an issue where I can't create a constant from a waveform to use in a cluster shift register. It seems like a waste having to convert from array to waveform for profile checking and then back to array for storage purposes. I could send some files if you want to see them.

[Vineet_A.]

Kevin,

Depending on how fast your data is changing, one option is to reduce the update rate for tag I/O groups on the server. You can do this from the control workstations through the tag configuration editor, by going to the "Connection" tab of your tag configuration settings. After clicking on the "Edit..." button, you can specify the deadband and maximum update rate at which the server will send tag data. Increasing the update time should reduce the CPU usage on the monitoring station.

If you'd like to only read tags on demand, there's also the option of using a datasocket read instead of the DSC tag engine. You can directly read the OPC tag item using the same OPC URL, but your control workstations might start to slow down as the number of tags you are reading increases. Datasocket reads are not optimized for many OPC items, as the DSC tag engine is.

Are all tags being logged on the monitoring workstation as well?
Another option is to query the Citadel database directly, instead of going through the DSC tag engine. You can use the Historical Database VIs to do this by specifying the database URL and tag name.

I hope this helps.

Regards,
Vineet A.