How to change setpoints from 2 locations over telemetry

TheWaterboy

Lifetime Supporting Member + Moderator
Join Date
May 2006
Location
-27.9679796,153.419016
Posts
1,906
I'm sure this has been done but I keep tripping over myself.

You have a home location and a field location that are connected via polling radio telemetry.

How can I set up PLC code so that I can change a setpoint from either location? And how do you determine which one wins if both are changed at the same time?

I have bounced off this "2 Generals" problem and have not been happy with any work I have done on it.

Can someone share a flowchart or pseudo code or even just describe how to do this?
 
This is pretty simplistic but it gets the point across. If the values are noisy, you'll need to set some change threshold before letting the new value take over.

If the output can't jump instantaneously, you'll have to add some ramping.

Enjoy:
https://youtu.be/5ReYA7-DmeA
 
I will have all the data that goes over the radio link in one big block. Some of the data is setpoints, other is just information going from point A to B.

The part of that block of data that is setpoints has an incoming and outgoing copy. The remote stations always work with (and write to) the outgoing data.

The incoming data is scanned for changes, and if an element of the incoming data is changed, I make a copy of it in a "handshake" file, and also copy it to the outgoing (working) data. I do this in a subroutine with a loop with indirect addressing so that it reduces the chance of a typo and I only call this subroutine when I know I have received data from the master PLC.

To know when I have received data from the master, I typically use the first setpoint as a "heartbeat" register and have logic that runs every scan comparing it to its handshake register. If it changes, I latch a bit, and reset the comms timeout alarm delay timer.

The bit that I latch will call the subroutine where the rest of the setpoints are checked for changes, the outgoing file gets updated and after the loop completes its cycle through the range I need covered, I unlatch that bit so I don't keep calling this routine unnecessarily.

In the master PLC, the same principle is applied. The outgoing data is considered to be the "live", active data used on its HMI and for control purposes, and changes are made to that outgoing data. The incoming data is checked against handshake registers (one for each setpoint) and if differences occur, the new value is written to both the handshake element and the outgoing register. Like in the remotes, I only run these checks when I know that the message has completed successfully, except here, I will ensure that both write and read messages are completed by looking at the MSG DN bits (not just the heartbeat transition).

The reason for this (as I am sure you are aware) is that radio telemetry is never 100%, so if for example, the master changes setpoint A from 0 to 1, and then the data gets sent. The remote receives it, updates its outgoing data, but the master fails trying to read it. Nothing is wrong yet, until it is changed again and the message succeeds, or if the write message fails on the next cycle after a subsequent change. Like you, I have shot holes in a handful of schemes and evolved my method to this point.

It is still not perfect. It is possible to get into a race situation when operators change the same setpoint at both master and remote and the polling happens to be in between the reading and writing, and the right combination of messages don't succeed. But this method has resolved the race condition more than 98% of the time for me. The big drawback is having to have basically three copies of each setpoint. I recently did a system with 15 remote sites, 9 of which needed remote setpoint controls, with about 20 setpoints at each of those sites. That ended up using a large percentage of the available space in a Micrologix 1400 acting as the master.

Having written all this out, I am not sure if I conveyed it well enough...
 
Last edited:
How funny - the first one was an actual 2 generals problem... Nice. It does have the problem of not updating both sides so each sees the others changes.

Okie
You are on the same path I am... a big block with part of it being monitored for changes. what a mess eh? But you have some additional checking that I'll look into. A race condition is pretty unlikely in my case, just have to do the best we can. Thanks to you both, I'll chew on this for a bit. I'll post my solution and see if you can poke holes in it. :)
 
I had a customer once that wanted line speed control via single-turn pots.... the trick was, any of 8 pots could be used to control the speed.


My solution was to just monitor each pot, and if any one made a 10% change, latch that one as the speed source.


Worked great, and it was a suprisingly friendly, intuitive control system for the operators.
 
Yea, but still not ideal from a user perspective. Sliders in different physical positions... But still very interesting.

Whats the ??? doing in this?
8 generals.jpg
 
That is the down side of using FOR loops. At the end of the FOR loop, the value of i is actually 8. But the array only has values from [0..7] so the value with a callout of 8 is undefined.

And damn you, you had to keep harping on the sliders.... ;-)

https://youtu.be/_yTkMvyEWPY
 
The Tags in the project are:

Code:
PROGRAM PLC_PRG
VAR
	rCMD:		ARRAY[0..7] OF REAL;
	rWAS:		ARRAY[0..7] OF REAL;
	bLight:		ARRAY[0..7] OF BOOL;
	i:		INT;
	iGeneral:	INT;
	iGenDisp:	INT;
	rTemp:		REAL;
	rSET:		REAL;
	Smooth:		RAMP_REAL;
END_VAR
 
BTY, in my code, the "general" with the highest number station wins any races.

So if 4 and 6 go over the 10% threshold which I set up during the same PLC scan, 6 will "win" and take control. At least that seems like what will happen. Testing is left as an exercise for the student.
 
I'm sure this has been done but I keep tripping over myself.

You have a home location and a field location that are connected via polling radio telemetry.

How can I set up PLC code so that I can change a setpoint from either location? And how do you determine which one wins if both are changed at the same time?

I have bounced off this "2 Generals" problem and have not been happy with any work I have done on it.

Can someone share a flowchart or pseudo code or even just describe how to do this?


As Okie Writed.



On master side you need to latch bit, if setpoints are changed from last remote writing.


Then on communication, you need first to read from remote side to buffer, if setpoint latch bit isn't setted on master side. (Remote and master equals, or remote side have newr data, but you can't know before you read remote)


Compare readed data to master, and copy from remote to master, if remote side have different data.


If latch bit is on, then you need to write to remote side, since master have "newest" setpoints.


After all, you have 3 variables for every setpoint.
Master SP, remote SP and buffer, which is used to comparing. Then you only need to move commands between them.
 
I had a customer once that wanted line speed control via single-turn pots.... the trick was, any of 8 pots could be used to control the speed.


My solution was to just monitor each pot, and if any one made a 10% change, latch that one as the speed source.


Worked great, and it was a suprisingly friendly, intuitive control system for the operators.

Monitoring the amount of change at each pot and adding or subtracting the change from the setpoint would have worked and not had the limitation of the 10% threshold. ie: Don't use the actual position of pot as the speed source, use only the change in position to alter the setpoint. Obviously without knowing the entire criteria this may or may not be an appropriate solution and it's dependent on the hardware as well. The point where the signal "wraps" would need to be clean and accounted for.

Cheers

Ken
 
Last edited:
The point where the signal "wraps" would need to be clean and accounted for.

Cheers

Ken

This would be easy if instead of resistive pots you had full 360 degree low resolution encoders (like on the volume control of most car radios) instead of pots. It's darn hard to find something like this that is not very expensive. it would burn 2 digital inputs for the A&B channels but would make stuff like this very easy.
 

Similar Topics

Hi, We have modbus tcp implemented in s7-1200. For now it has been only control and status. Now we want to change settings. I have never done it...
Replies
14
Views
4,300
We had one go down. we have a new one. Their emergency Number don't work. The Model is TLSA046AAH-330N01-007 A catalog says we need software TET...
Replies
2
Views
136
“The HMI files we cannot open—they were saved in V13—we do not have that—I cannot restore file –please have them save in V11 and send them back to...
Replies
4
Views
135
Hi guys! I'm working in Studio 5000 and have a bunch of armorstarts there (+- 40). I need to set up parameters for each of them, mostly just same...
Replies
0
Views
75
Hello brothers We are contacting you because an error like [display change is currently controlled remotely] occurred while using the equipment we...
Replies
2
Views
174
Back
Top Bottom