LabVIEW DSC Slow in reading and writing tag values... Why?

[MichaelAivaliotis]

Sow it turns out I got involved in creating an HMI interface with LabVIEW that interfaces to a PLC. Oh joy!

I started off by using datasocket and OPC to read and write values to the PLC. It turns out that this method becomes unusable for anything larger than 100 variables. The data transfer is painfully slow. This has been confirmed by NI support.

So then I convinced the customer to go with the LabVIEW DSC module. I started adding tags in the DSC engine and everything started to go well. Now I have about 320 tags setup in the engine and it is again painfully slow to transfer data back and forth. How slow? It takes over 5 seconds to get a variable change to show up in the PLC. Unbelievable!

Ok, so now I'm looking at the hardware interface to the Allen Bradly PLC. It is a serial connection at 19200 baud. Yes, I agree, this could be the bottle-neck. However does anyone out there have any experience with the DSC engine? Before I go shelling out cash for new hardware (ethernet connection). How can I make sure that this is not an inherent problem with the DSC engine and nothing to do with the hardware?

[MichaelAivaliotis]

Just to add to my post. I was looking at the upgrade options for my hardware and found that Allen Bradley has a faster ethernet controller for the SLC-500 line, It's the SLC 5/05 which supports ethernet communications. Just my luck... the there isn't an OPC driver for this!! NI, is there an OPC driver in the works for this?

[chrisger]

hi

maybe you can reduce data transport by widening the updata deadbands (see tag configuration).

best regards
chris

[MichaelAivaliotis]

---

@chrisger wrote:
hi

maybe you can reduce data transport by widening the updata deadbands (see tag configuration).

best regards
chris

---

I changed the deadbands to very wide but it made no difference. Also the bulk of the values don't change often. They are discrete. The bulk of the Analog values are just sent to the PLC once since they are used as control parameters. They aren't used for reading constantly changing values.

[Donald]

Michael,

"Allen Bradley has a faster ethernet controller for the SLC-500 line, It's the SLC 5/05 which supports ethernet communications. … is there an OPC driver in the works for this?

Check out the following links to items in the Lookout board which discuss a couple of options. The suggestion to try using the SL5/04 driver object is probably a good one.

http://forums.ni.com/ni/board/message?board.id=190&message.id=534&query.id=0
http://forums.ni.com/ni/board/message?board.id=190&message.id=1205

" … over 5 seconds to get a variable change to show up in the PLC. Unbelievable! … 320 tags … serial connection at 19200 baud … the bulk of the values don't change often. They are discrete."
Something does smell fishy. Although I haven't used AB, I've got a Direct Logic system with ~200 tags at 9600 baud that has no problem at 1 Hz.

"The bulk of the values don't change often. They are discrete."
Are you reading/configuring the discrete bits as bits or as words/boolean arrays? Just trying to get a better idea of how things are set up.

"I got involved in creating an HMI interface with LabVIEW that interfaces to a PLC. Oh joy!"
It can be lots of fun. Unfortunately, you've started just after the demise of the separate LVDSC board. If you don’t get a good response here, you may want to try the Lookout board. Good luck.

[Ben]

There are a lot of things that can help speed things up. I have done close to 2000 with sub second updates. The PLC's in question where all ethernet based. NI was able to help me fat finger my way through configuraing the Lookout OPC server.

The update rates can be affected by the update rates specified in the tag engine as well as the OPC server.

When last I looked there was some fine print in the tag read function as well. At that time the read tag VI would perform better if the tag that is queried is the same as aws queried the last time that node executed. It acted as if it cached some connection info that let it read faster than if the tag name changed (from the last call of that node) and had do some admin to switch to the new tag. I admit I am doing a lot of guessing here.

I optimized things by restructuring my tag reads so that I used unique tag reads for each tag instead of reading them in a loop. This alos let the tag reads execute in parallel.

The tag reads were grouped by the data structure in the PLC and had unique VI's for each PLC (approx. 50).

I beieve I used templates (it was about three years ago and memory fails me, and I do not have that code on this machine).

The tags values were served to the rest of the application using an action engine construct.

After tuning all of the update rates, and deadbands, we ended up being able to support user requests initiated from the PLC's and serve a central DB with good response time.

I hope some of this helps,

Ben

[MichaelAivaliotis]

One thing that sucks on this new board is that you can't quote an individual post... Hmmm

In any case, I just wanted to respond and close the loop on this. I finaly solved the problem by upgrading the PLC processor to one that supports ethernet. Now the whole system is blazing fast... I had to go with the RSLINX OPC driver from Allen bradley since the NI OPC server did not support this processor.

Thank's for all the replies.