Is there a way to disable security so I do not need to set logins/passwords on App Station identical to computers outside DeltaV network when accessing data from DeltaV reporter? If so, please describe.
You could run some tunneling software (Softing/Kepware/Matricon) on the App station, tunneled to your outside PC. The tunnel client on the app station would run under the DeltaVAdmin account, but the client side tunnel can run under any login.
Not ideal I know, as you would need to purchase tunneling software.
The other thing that MIGHT work is using the "RUN AS" when starting programs or services on the client.
You can be logged in under USER1, but as long as the OPCREMOTE and EXCEL are run as DeltaVAdmin it should still work.
Can you explain why you need to disable security?
In reply to BobHuba:
It is inconvenient, to have to change passwords on an OPC server, when passwords are changed on an office computer -- i.e. someone changes their password, and Excel breaks. Also, some office personnel, do not want to give out their passwords for input into the Application Station. I would prefer it if the password could simply be embedded in the function calls or OPC request, particularly for a read-only account. I have not yet investigated whether the Historical Web Services (HWS)/XML would allow this sort of functionality. I understand the 'run as' concept, that would work for a custom-built OPC client, though still require a user be set up on each client computer. I preferred the way PI Excel Add-In worked in that regard; I could just use same password for all computers.
In reply to Frank Seipel:
Can you clarify what app we are discussing... I am trying to help or at least understand the issue.
Note we have two Excel spreadsheet applications – one based on OPC DA and one based on the DeltaV Continuous Historian. Since PI DataLink is mentioned in the customer’s original text (PI DataLink is the Excel addin for the PI Server), I will assume they are referring to the DeltaV CH Excel addin. The DeltaV CH Excel addin (called DeltaV Reporter) does not use OPC, it uses the historian’s internal API, which is based on .Net Remoting
Frank is discussing DeltaV Reporter, per his first message.
I have not determined a way to handle this request, although I have tried and can see the applicable parallel between OSI's client setup.
Two potential options, in lieu of being able to do this through client configuration:
1. Domain trusts - if the DeltaV domain is set up to trust the enterprise domain, there is a good chance the client can be allowed access while logged in to excel as their enterprise account. There are steps required on the DeltaV system to add enterprise domain users as members of DeltaV windows groups (and even in the Deltav database).
2. Excel as a terminal application. Install Excel and DeltaV Reporter on a terminal server in the DeltaV domain. Publish excel as a terminal application. Have users use remote desktop connection to access just excel (by specifying it as a startup program in mstsc) using a generic Deltav domain account with read only credentials.
I haven't tried these options, but they may be worth investigating.
In reply to Youssef.El-Bahtimy:
OK I saw that but as DeltaV Reporter does not use OPC per my reply I do not understand the comments about OPC in relation to DeltaV Reporter. This is why I was asking for clrification
Sorry Bob. I think I mis-steered the conversation that way.
In reply to Travis Neale:
Youssef, thanks for your response, currently we have a small system, DV is on a workgroup, the remaining office computers are in a domain. At some point we may try these suggestions.
Also, I resolved my second issue, accessing DV data from MS Access with VBA. In case it's of any use to someone, I am posting. First sample below gets a PV from server @ 192.168.5.221; second fetches historical data from same server. It is necessary to go to Tools|References in VBA editor and check OPC HDA Automation 1.0 and OPC Automation 2.0 to execute these samples. I also installed OPC Remote first & made sure username/password matched, for some peculiar reason, on this client PC, the Windows login username is different than the one reported by echo %USERNAME% in DOS, once I understood that I was able to set up a DV account on App Station with same credentials as the username reported in DOS window.
Private Sub Command0_Click()
Dim srvOPC As opcServer
Dim intClientHandle As Long
Dim RetVal
Set srvOPC = New opcServer
srvOPC.Connect "OPC.DeltaV.1", "192.168.5.221"
srvOPC.OPCGroups.Add "Group1"
intClientHandle = srvOPC.OPCGroups(1).ClientHandle
srvOPC.OPCGroups(1).OPCItems.AddItem "LI-0603/ALM1/PV.CV", intClientHandle
srvOPC.OPCGroups(1).OPCItems(1).Read OPCDevice
RetVal = srvOPC.OPCGroups(1).OPCItems(1).Value
MsgBox (RetVal)
Set grpOPC = Nothing
srvOPC.OPCGroups.RemoveAll
srvOPC.Disconnect
End Sub
Private Sub Command6_Click()
Dim HDAServer As OPCHDAServer
Set HDAServer = New OPCHDAServer
HDAServer.Connect "DeltaV.OPCHDAsvr", "192.168.5.221"
Set HDAItems = HDAServer.OPCHDAItems
HDAItems.AddItem "LI-0603/ALM1/PV.CV", 3 'Client Handle is 3
Dim ItemHandle(1) As Long
Dim ReturnValues() As Variant
Dim Errors() As Long
'only one item
ItemHandle(1) = HDAItems(1).ServerHandle
'SyncReadRaw (ByRef StartTime, ByRef EndTime, NumValues As Long, Bounds As Long, NumItems As Long, ServerHandles() As Long, ByRef ItemValues() As Variant, ByRef Errors() As Long)
HDAItems.SyncReadRaw "NOW-1M", "NOW", 0, True, 1, ItemHandle, ReturnValues, Errors
For Each Value In ReturnValues
For Each tstValue In Value
Test = MsgBox(tstValue & " - " & tstValue.TimeStamp & " - " & tstValue.Quality)
Next tstValue
Next Value
HDAItems.RemoveAll
HDAServer.Disconnect
Set HDAServer = Nothing
Set HDAItems = Nothing
hi Travis,
Is it possible to create a duplicate DeltaVAdmin account (with a different name and password) to be used on tunnel client on the app station rather than using DeltaVAdmin itself?
I was facing similar issue and tried to create a duplicate DeltaVAdmin account with all properties matching to that of the original DeltaVAdmin account. I created it on Local as well as domain level. But when we tried to use opcwatchit under that account it doesn't work. It works only under actual DeltaVadmin account. Am I missing something here?
thanks,
Bhushan
In reply to bhushank4:
I want to say it should be possible, but I can't say for sure, and it probably wouldn't be a good idea.
DeltaV sets some of it's DCOM to run as the DeltaVAdmin identity, which would be hard to work around, and would probably cause you more problems then the one you're trying to solve.
Frank,
I read through your script and saw the "Read OPCDevice" function. I'm not sure, but if this creates a device read, you should know that this initiates a call to the source data and forces an update. That is not a problem if you are making a one time call. but if you are calling multiple values continuously, Device Reads can burden the controller with extra communication load. If the module is in the Virtual controller, this will not make much difference.
When creating an item in a group, the OPC Server initiates a connection via DeltaV to the source module, and DeltaV sends the initial value, which is stored in the OPC cache. DeltaV will from then on update the cache by exception based on the parameter value, module execution rate or OPC Update rate requested (which ever is slower). The controller treats this like any other deltaV unsolicited communication request.
However, when a Device Read is made, the OPC server initiates a specific call to the source controller for the current value, and this is treated as a higher priority request at the controller (higher than medium priority modules). Asking for one value from time to time is of no issue. Asking for hundreds of values per second can consume CPU time and starve lower priority module execution. DeltaV will report low CPU and module slippage, if it occurs, but someone will need to know what may be causing the issue.
DeltaV recommends no more than 20 such reads (or writes) per second to a controller. The controller can send thousands of values per second with unsolicited communications. These Device REads come at a much higher cost....
Andre Dicaire