How top make a setpoint adjustable locally and remotely?

[TheWaterboy]

I've asked this before but I still couldn't make it work. I just can't envision a solution.

Local RTU has a screen to set a handful of setpoints. Historically all adjustments have been made locally using the OI. The Main Plant now wants to control these same setpoints as well over telemetry.

How can that be done? If the Telemetry package contains old setpoints, which it will, it will always overwrite the local ones each poll. In addition the Main Plant would never know the setpoint was changed unless I read it back.

I can envision a complicated readback method that will require multiple reads and writes to each location. I can also imagine sending one set of setpoints to one array location and local ones elsewhere and using a selector at the local to set which setpoint to use. But I don't like the complication of those options.

I'm hoping I just haven't thought of a simple technique for this. I can't be the only one.

 

[Cheeseface]

You need a tag that indicates the owner of the setpoint. The OI is where it gets set to either local or remote owned.

You also need localSetpoint and remoteSetpoint tags. The OI writes to local and DCS writes to remote.

Logic chooses which valut to write into actualSetpoint based on the owner.

 

[TheWaterboy]

Yea, see that's exactly what I want to avoid. That will be in the wrong setting every time. I want to hit each actual setpoint from either side.

I'm gonna have to read these values back at the plant to make this work aren't I?

 

[ASF]

Have you considered a mechanism where each time a setpoint is changed at the local OI, it records a timestamp that the change occurred? Then when a telemetry change is sent, it's sent as a request to change, along with a timestamp that the request was sent. The local SCADA or PLC receives the request, checks that the request timestamp is later than the existing timestamp by at least, say, 10 seconds, and if so, updates the setpoint. If not, it ignores it. You could send back a success or failure message if you wanted, or you could just tell the remote operators that if you try to update a setting and don't see a change after 20 seconds, try again

 

[TheWaterboy]

Now you might just be on to something there . . . I never thought of using the timestamps...

 

[TheWaterboy]

Arghh. Integer registers make timestamps difficult to handle.

 

[Cheeseface]

I see, I didn't understand you wanted all setpoints to apply at the time they are generated.

Just write the setpoints into a FIFO

 

[TheWaterboy]

I don't see how a FIFO fixes the contention. Can you elaborate?

 

[arpus4KM]

Use owner/3way switch setup.

Each side can grab control back from the other by toggling something.

the owner gets to use their setpoint and can just grab ownership back or give it back when needed. its more difficult/annoying to just let the last entered value be the set value especially if it wants to reset every time.

 

[drbitboy]

Arghh. Integer registers make timestamps difficult to handle.

How so? 32-bit timestamps and 16-bit registers?

What are the protocols involved?

Do you have control of the device, and its code, that control the process per each setpoint?

What is the actual sequence of events (e.g. type in new setpoint, press enter, click send, setpoint is written once when send is clicked OR setpoint is written continuously from Main Plant telem every 5s and continuously from OI every 3s, etc.)?


Is the current setpoint displayed at the OI?

Is the current setpoint displayed in the Main Plant interface?

 

[TheWaterboy]

The Plant uses a L81 so lots of potential for decision making there, but the destination is often an old PLC5, ML1400 even a Click PLC is in there, so I gotta build for the lowest common denominator. A 16 bit register wont even let me use seconds in the day as a timestamp. And forget about Date Math.

Registers on the remote side are arranged that N7:0 - N7:50 are Commands to the remote site and N7:51-N7:100 are Status of the remote site.

Polling PLC reads N7:0 x50 then writes N7:51 x50 every cycle. There are a LOT of remote sites in sequence so adding code to the polling Logic to check for changes to any recently read registers before writing to the station is not my first choice. I could do a timestamp compare in the L81, just don't want to mess with the polling logic. It's got a lot of sequencing and diagnostics in it and I want to leave it alone and do this some other way.

• Comm protocol is Slow radio over DF1.
• I have no restrictions.
• Setpoint is typed in OI (PV600) at remote. Protocol between them is DH+ and value is stored in PLC-5 at (for example) N7:0.

The desire is to type setpoint at Plant , MSG that to the remote at same register (N7:0). That part is easy to do.

Where this falls down is that the plant setpoint is stored on the polling PLC and will be re-sent every polling cycle overwriting anything the local OI has set.

Re-reading that specific setpoint (N7:0) would require another read cycle, or I can copy it to the status registers at the remote site PLC and read that on the next poll cycle, but how to ensure last value entered from EITHER location is the one that wins is not as easy as it sounds.

 

[Cheeseface]

Never mind the FIFO, when I tried it out it simplified to this:

XIC(S:FS)MOV(xlocalsp,xlocalsp_prev)MOV(xremotesp,xremotesp_prev);
NEQ(xlocalsp,xlocalsp_prev)MOV(xlocalsp,xlocalsp_prev)MOV(xlocalsp,xsetpoint);
NEQ(xremotesp,xremotesp_prev)MOV(xremotesp,xremotesp_prev)MOV(xremotesp,xsetpoint);

also, this doesn't really solve your read-back problem. sorry.

 

[TheWaterboy]

also, this doesn't really solve your read-back problem. sorry.

Yea, Thats the same wall I keep hitting.

 

[ndzied1]

Here's what I would do.

For each parameter have a tag for active_value for instance for pressure 1 (P1):
P1_Active_Value

You run the application from the active values and display the active values locally and remotely.

The at each position, local and remote you have a proposed value
P1_Local
P1_Remote

Also at each position local and remote you have an HMI button to Write to Active Value
PB_P1_Local_Write
PB_P1_Remote_Write

Do a move from the appropriate proposed value to the active value when each button is pressed. You can one shot the move to be safe.

Both sides see the active value, both sides have a way to update the active value. A little more coding and HMI work but seems doable.

I hadn't read post 11. So It's more complicated than this... but hopefully at least some idea...

 

[drbitboy]

Never mind the FIFO, when I tried it out it simplified to this:

XIC(S:FS)MOV(xlocalsp,xlocalsp_prev)MOV(xremotesp, xremotesp_prev);
NEQ(xlocalsp,xlocalsp_prev)MOV(xlocalsp,xlocalsp_p rev)MOV(xlocalsp,xsetpoint);
NEQ(xremotesp,xremotesp_prev)MOV(xremotesp,xremote sp_prev)MOV(xremotesp,xsetpoint);

also, this doesn't really solve your read-back problem. sorry.

This is what I was thinking. It uses five tags per setpoint, but otherwise does t'job.

How does that not solve the problem? It ensures that either HMI (Main Plant telem or local OI) cannot overwrite a newer value from the other HMI.

Is it because the local OI does not "know" about and/or cannot display the newer value from the Main Plant, and vice versa?