Lookout 6.1 Pot Object Remote Connection Behavior

[T@TPCG]

I want to be able to change the value of MainSetpointPot from the Main process, the Modbus Serial PLC(connected to a touchscreen), or the Client process. Here's my general setup.

Lookout 6.1
Server process-Server Objects with connections:
  MainDataTable.Setpoint < MainModbus.Setpoint < MainSetpointPot(Local Position Source Property)
  MainSetpointPot.reset < MainDataTable.Setpoint
  MainSetpointPot.resetValue < MainDataTable.Setpoint

Client process-Client Objects with Connections:(On different computer over Ethernet)
  ClientSetpointPot(Remote Position Source Property) > MainSetpointPot.value

I realize that MainDataTable.Setpoint is a numeric value connected to a logical member but, the value change works fine from the Server or the PLC, but the MainSetpointPot.value will not change value from the remoted ClientSetpointPot. It does not return a "Remote position source is not writeable." error in the alarm window; It only snaps back to the original position source value of MainSetpointPot.

Does the MainSetpointPot.resetValue triggered by (MainSetpointPot.reset < MainDataTable.Setpoint) prevent a valid remote connection to MainSetpointPot.value from ClientSetpointPot? Is this a bug in the Pot Object, being that nothing is directly connected to MainSetpointPot.value?

I can make this task work with a NetDDE method, but I'm looking for a non-NetDDE solution for future compatibilities when NetDDE support is no longer available.

Terry Parks, Engineering Analyst
Terrebonne Parish Consolidated Government (T.P.C.G.)
Public Works - Pollution Control

[Tulong]

If it works fine with the process running on the server, you may want to check your symbolic link from the client pot to the server pot.  I know it sounds a little crazy, but you never know.  I have seen people (including myself) working on a client process that's running on a server, but forget to use a symbolic link instead.  They just tie in locally to the server process and everything was running fine until they try to run it on a remote client.  That's the reason why I always work on a server when I am editing server process, and on a client while editing a client process.

[T@TPCG]

Tulong,

If I disconnect MainSetpointPot.reset and MainSetpointPot.resetValue the remote connection works, but I lose other functionality. The server and client processes are programmed and tested on separate Development machines on the same network. I do use a symbolic link but omitted it from my setup for simplicity. The only other clue I have from other research is a timing issue on the snapDelay. I'm still thinking possible bug. Thanks for the reply.

[Tulong]

By looking at your code, I just realize that this should never work because you use the same numeric value source for both MainSetpointPot.reset and MainSetpointPot.resetValue.  Here is why, when you change your ClientSetpointPot which in turn will write to  MainSetpointPot on the server.  The minute the value of  MainSetpointPot on the server changed, it will reset itself back to your reset value, and this will happen everytime your MainSetpointPot.value changed.  As you have mentioned earlier about numeric value tied to a logical value, you can get away with this by creating a push button and use it for MainSetpointPot.reset.

[T@TPCG]

From further testing your idea about the numeric to logical connection has merit. If I connect say,
    MainSetpointPot.reset < (MainDataTable.Setpoint<>MainModbus.Setpoint)

    MainSetpointPot.resetValue < MainDataTable.Setpoint
the remote connection works, the MainSetpointPot.value changes to the MainDataTable.Setpoint when the poll is complete and changed data passes from the modbus member to the table member.

This works most of the time, but fails in some input device combinations. I guess what I really need is a way to turn a numerical value into a toggled logical true signal when the numeric changes value. This way whenever the numeric table value changes it will trigger the reset automatically. Maybe no bug after all. Thanks.

[Tulong]

Just out of curiousity, why would you want to use reset while all you have described is just to be able to change the setpoint on server side.  Is there a reason for you to use the reset function?

[T@TPCG]

In my original post I stated I wanted to be able to change it from the client process. This is on a SCADA network with 150 sewer pump stations supporting several clients already. I already do it with NetDDE, but support for NetDDE is being phased out. This new methodology may also move forward to a Forced Drainage project we have in the works.

[Tulong]

If that is all you want, then just remove the MainSetpointPot.reset and MainSetpointPot.resetValue and it should work. 

ClientSetpointPot>URL: [ServerLink]\MainSetpointPot.value

MainDataTable.Setpoint = MainSetpointPot

MainModbus.Setpoint = MainDataTable.Setpoint

MainSetpointPot = Local

[T@TPCG]

This proposed solution does not reset the MainSetpointPot when the value changes independently at the modbus object(Pump Station PLC). I realize this is a squirrelly problem. I'm gonna miss NetDDE.

[Tulong]

Ah ha... now I think I got what you've been trying to say.  You want to be able to change the setpoint either at a remote client or at a touch screen located nearby the Modbus (should have read your question for carefully ).  Try this:

ClientSetpointPot>URL: [ServerLink]\MainModbus.Setpoint

and if you want to log data into your table as well, then add this:

MainDataTable.Setpoint = MainSetpointPot

When you change your setpoint locally (at the touch screen), the value will be written back to ClientSetpointPot due to two-way connection.

When you make a change in your remote client, you may see the ClientSetpointPot value flips back to the old value for a momment (depended on how fast your connection is) and then it will update itself with the new value that you just put in (after finishing writing to the Modbus).