LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Arrays in NI OPC Client/Server?

Hi all,
one of our clients uses LabVIEW DSC to collect data from a third-party OPC server supporting arrays behind the variant data type. Unfortunately, the NI OPC client doesn´t support this. There is no possibility to change the OPC server (e.g. usage of binary strings). Does someone have an idea?
0 Kudos
Message 1 of 24
(6,620 Views)
FrankyBoy,

a way to get these OPC arrays into LabVIEW is through DataSocket. I've tested it with the Softing's Demo DA Server and it seemed to work. You should be able to get the Demo Server from the web (www.softing.com)
I've attached my example VI if you want to explore.

The problem there is that once you have the value in LabVIEW you would need to feed it back to the DSC Engine as single values through Memory Tags if you want to log them or if you need somehow alarming...
A more consuming, but nicer implementation would be to write a small VI-based server with those Datasocket VIs and feed it directly to the DSC Engine.

Both workarounds are hassles and we can just hope that NI will support measurement waveform datatypes or/and all OLE-Active
X-OPC-Variant datatypes in the near future tightly integrated to the DSC Engine.

Hope this helps (to workaround the limitation)
Roland

PS: The OPC standard does not require to have all the datatypes implemented or supported - I think.
Message 2 of 24
(6,615 Views)


Good workaround Roli! 5 Stars for you (last one is invisible)!

By the way, it must be noted that the DataSocket performance could deteriorate as the number of items increase (as compared to tags being read by the engine).

I guess you can read only the Array items using DataSocket and the rest using DSC Engine.

Have a good weeknd y'all!

Khalid


0 Kudos
Message 3 of 24
(6,615 Views)
Hi Roland,
thanks for your answer (Khalid is right - 5 stars!). We passed on the information to our client and hope to workaround the limitation. We`ll give you further information after receiving some response.
Thanks again!
Frank
0 Kudos
Message 4 of 24
(6,615 Views)
I am using Labview DSC with Kepware to read large blocks(200-2000) of plc registers to create analog stripcharts inside Labview. I was having difficulty with some of the datapoints not updating inside the tag engine at times. I had to modify my datablock to include checksum registers at the end of the data. The checksums are calculated in plc logic for each group of 100 plc registers. Then I made labview read the data block until calculated checksums in Labview matched plc checksums. This really improved reliability of data transfer. My checksums are using CRC16 format for Modbus TCP/IP communications. My application has to read several hundred tags in less than .2 seconds before they get reset in the plc logic.
0 Kudos
Message 5 of 24
(6,615 Views)

Hi,

This is interesting. I would really appreciate if you can give more details of your issue. Like, are you reading a group of Tags? And if some of them don't update, you read all of them over again? And the checksum helps in determining all were read succesfully? Why couldn't you re-read only those tags which didn't "make thru'"? Were there any issues with input queue being compacted on the DSC side?

In your app, were you only reading data from Kepware? Or writing to it as well? Were there any issues with the writing of data from DSCEngine to Kepware as well? Like, output queue overflows?

Sorry for the barrage of questions. This info' will be useful to other users, and to the NI Technical Support team. Maybe they
can verify these issues and come up with a solution, or at least document them in a KB article.

Thanks in advance!

Khalid

0 Kudos
Message 6 of 24
(6,615 Views)
I have two Momentum plc's setup on ethernet transmitting to Kepware with the I/O scanner feature in the plc. This is a write only from the plc to Kepware. The computer ethernet card has been multi-homed with two different ip addresses. Each plc transmits to different ip addresses. The plc's send 250 registers in one plc and 600 registers in the other. I have some other machines that send over 2000 from a single plc. I am recording the power used to machine aluminum cylinder heads and cylinder blocks. I use labview to stripchart the power used for each toolpass. One of these stations has 16 different toolpasses and the other has 32 different toolpasses. Eight or sixteen toolpasses each for LH or RH cylinder heads. I make a n
ew piece every 95 seconds. I write the tool profile data to a binary tag for each toolpass and store in Citadel. I also can view historical data to watch max. or avg. trending by toolpass. I have the tags in groups, but I pass the whole array of tagnames to the multiple read vi. When a boolean tag turns off, I read the whole group of analog registers for that station. I could not really tell which registers did not update. That is why I added the checksum calculation. I am not aware of any issues with the input queue being compacted. I do have some data bits being written back to kepware for alarms signals. I have not seen any output queue oveflows. I'll try to attach my application as an llb, and the scf and kepware files, but it is quite large. This was my first application for labview, so it could probably be written much differently. I could not get two of the integrators to even give me a quote on this application, so I muddled through it myself.
0 Kudos
Message 7 of 24
(6,615 Views)
This sounds like you have a successful LabVIEW process automation application with the whole set of DSC features.
Concerning the update problem... I could see several locations where the problem could occure.
1. In the Client Read Multiple... but I doubt
2. In the DSC Engine... check all limits and group deadband and scaling settings. With so many tag there might be a small misconfiguration where the deadband (%) is not matching the scaling?
3. The server (OPC server, Kepware) might not update the values from the PLC.

2. could be troubleshooted with e.g. the Tag Monitor tool.
3. could be troubleshooted with another OPC client which is updating with the same settings the values from the OPC server.

A yeah, I'v
e forgot a possible 4. problem location: a mysterious bug in the DSC Module. But to proof that would require an isolated replication of the problem.

It looks like you worked around the problem and you found a successful solution. You might talk to your NI sales rep or NI marketing to turn your solution into a customer solution paper.

Thanks for sharing your application.
Roland
0 Kudos
Message 8 of 24
(6,615 Views)
For question 2 - here are the settings from my scf file. update deadband is set to 0 or always. Scaling is set to N/A or none. Log resolution is either 0, 0.01, or 1. I/O group update rate =.050 for kepware tags and 0 for DSC memory tags. Anything much faster that .050 for kepware reads would not return data at times. I think there was a change in the DSC6.1 version to correct this issue. I am not sure how low DSC7.0 can bet set. I/O group deadband=0. Are there any other settings that I should look at?? Is the Tag Monitor data really the same data that is available in the DSC tag engine?? I remember seeing data that would show up in the tag monitor but would not get into the tag engine. It has been awhile since
I have used the tag monitor.
For question 3 -- From my experience with the KEPWARE program, it seems to have exceptional performance. Since it works with so many different plc brands, I would think the code has really been stressed and tested.

The nagging question in the back of my mind --
Was the tag engine designed to operate for such a high speed/high data load interface between it and an OPC server? How fast/hard has it been tested?? With so much software and hardware involved, it becomes really difficult to pinpoint where a timing/performance issue is located. I am running this application on an 850Mhz PIII machine with 256Meg of ram. Maybe 512Meg of ram. I have another machine that I want to setup that will have around 8-10k tags inside kepware and the tag engine.
0 Kudos
Message 9 of 24
(6,615 Views)
I agree with Roland -- this is a good DSC application, congratulations! I have not looked at your files yet; will comment IF I can think of any way to avoid the missing data issue.

You will definitely want to mention your NI Sales contact in case they're interested in publishing a User Solution -- read "free publicity" for you.

You could also present your app as a paper at the NI Week Paper Contest. I believe the deadline for this has passed, but never hurts to try (maybe you can get in for next year's?):

http://ni.com/niweek/contest.htm

Regards,

Khalid

0 Kudos
Message 10 of 24
(6,619 Views)