Michael Lloyd

Easy way to test Produced / Consumed function

29 posts in this topic

The title is simpler than the question :) I have two PLC's, on different subnets, located 70 - 100 miles apart. Both are in stations that have an hourly flow rate of 6,000 Barrels and Hour. I do NOT want to risk doing something to fault the processor and knock the station down. I tried using an MSG instruction but the destination doesn't show up in the connection tree. Why would it? :) Produced / Consumed is the logical choice but adding the offsite ethernet card that is on a different subnet when I don't know if our network will allow the connection to makes me nervous. I have to pass 1 and only 1 bit to about 7 upstream stations which means I need to add 7 destination enet cards to do Produced / Consumed, correct? Any way to test connectivity without creating a connection? I can ping and tracert to one of the downstream PLCs on a T1 connection. I think I have the best chance of this working at the sites with a T1. Some are Compact Logix behind cell modems. Some are CLX behind DSL. The last two are pretty iffy for making a connection Edited by Michael Lloyd

Share this post


Link to post
Share on other sites
Michael, pretty sure you are way over my head on the networking aspects, so I won't go there. My only suggestion on the Produced and Consumed would be to add some "Heartbeat" or "I'm Alive" bits to determine if the other bits should be used. Another Idea might be an separate OPC server (RSLinx) that passes the data between the systems. This might also serve as a means of testing the connectivity. Seems to me at some point you would have to have the connection made wither way. But pretty sure P & C is the way to go.

Share this post


Link to post
Share on other sites
Michael, you really need IT specialist advice on this.... The stations are miles apart, so presumably the connection will involve the Internet ??? But even if they are connected to the same LAN (unlikely), the rules are simple... devices can only talk to devices on the same subnet.... That said, I'm sure there are ways to hop into other subnets, but it definitely would involve high-level IT procedures. You simply cannot talk to just anyone with an IP address without physical and logical authority.

Share this post


Link to post
Share on other sites
Its a matter of port forwarding and routing. It's not on the Internet, it's on our WAN. I can log on to any Plc from any location on our network. Even in Ohio, Alaska, Louisiana, and of course TX where I am. Of course that's no guarantee that the route tables will let me connect port 44818 on one subnet to 44818 on another. I'm looking for a way to test without trying. Our IT people understand networking but not PLC's. The simple port forwarding that we use in cell modems was not something that they grasped initially... I usually get deer in the headlights when I ask about anything more complicated than an ip range to use. I try not to deal with them unless I need a new laptop and even that is pAinfull

Share this post


Link to post
Share on other sites
If it were me, I would use MSG instructions instead of Produced/Consumed Tags. The Produced/Consumed system is unlikely to work well across VPNs or a WAN, especially if there are cellular links involved.
1 person likes this

Share this post


Link to post
Share on other sites
I'm not sure how the routing through the cellular modems works, but with a MSG you can jump from subnet to subnet by just defining the route the MSG will travel.

Share this post


Link to post
Share on other sites
Thanks guys. I think you're right. I know you're right when it comes to cell modems. Cookie - Lets say you have a Class C Network and your PLC is on (no I'm not dumb enough to use a real example. Besides that we have a private network with our providers) IP 192.168.113.41 Subnet 255.255.255.240 Gateway (router) 192.168.113.33 and the cell modem is address 8.8.250.50 In RSLinx, under Configure Drivers, create an Ethernet device with the IP address 8.8.250.50 in the modem go into the appropriate area and create a port forward (we usually have at least 4 because of other Modbus TCP devices) Public Start Port Public End Port Protocol Host IP Private Start Port 44818 44818 TCP/UDP 192.168.113.41 44818 So what happens if you have 2 PLC's behind the cell modem. Two things, you can only connect remotely to one of them at a time with Linx (unless someone knows how to point linx to a different port) and you have to add a second port forward. We usually use something like Public Start Port Public End Port Protocol Host IP Private Start Port 8080 8080 TCP/UDP 192.168.113.42 44818 and point Kepware at port 8080 (Kepware has to be configured for 8080 and 44818. 44818 is the default for the CLX / Compact/Micrologix AB stuff so technically that's done for you) Sorry about the tables. I gave up on trying to figure out the secret spacing code to get everything to line up... PS- If I need to connect to the other PLC I just go into the port forwarding and swap the Public Start and Public End ports and do the same in Kepware so our SCADA center doesn't lose their link Edited by Michael Lloyd

Share this post


Link to post
Share on other sites
I'm almost there with one station. I selected SLC Typed Write since that's what I've used for CLX<-->Micrologix message instructions. I can't recall ever doing a CLX<-->CLX message. The destination is not an SLC so I didn't expect it to work and my expectations were met :) I have an INT tag on each end. When I click apply I get an error- Invalid Remote Element for SLC Remote Message Type. I think this is telling me that the connection is there but my configuration is bad. Thoughts? What message type should I use cor CLX to CLX messaging?

Share this post


Link to post
Share on other sites
Onward thru the fog I changed the setup to something that makes more sense. I have INT tags on both ends Tab 1 config CIP Data Table Write INT TAG Source 1 INT Tag Destination Tab 2 config Communication: SCADA_Comm, 2, Destination IP address of Enet card in Slot 1 Connected: Checked Cache Connections: Checked Error Code: 16#0004 IOI Syntax Error Getting closer...

Share this post


Link to post
Share on other sites
For ControlLogix <-> ControlLogix messaging, use the "CIP Data Table Read" or "CIP Data Table Write". That message type requires you to use the exact Tag Name as the Source or Destination element. Be sure the Tag Name is spelled exactly the same and that the Tag datatypes are exactly the same. MSG instructions do not require you to have the remote device in the I/O tree. You just put together a CIP Path manually. The Help file includes some good examples, but the overriding principle is just to think of all the CIP hops as pairs of numbers: "Port, Address". Once you know that the backplane is Port 1 and the network port is Port 2, you're most of the way there.

Share this post


Link to post
Share on other sites
Almost there ! Short answer: Add one more CIP hop: "1, 0" to your CIP Path. If it's a CompactLogix, the CPU is always in virtual Slot 0. If it's a ControlLogix, the CPU can be in any slot number, so change the second number to match your actual chassis configuration, remembering that the left-most slot is Slot 0.

Share this post


Link to post
Share on other sites
I have both programs open and connected. I cut and pasted the destination into the cell. I can't get much more exactly the same than that. Connected is NOT checked. Typo on a pretty important point. Sorry about that

Share this post


Link to post
Share on other sites
And for the perfectionists: The modern CompactLogix 5370 controllers consider the CPU and Ethernet port to be integrated, so they will accept a MSG that is directed to the Ethernet module itself, or one that is directed to Slot 0.
1 person likes this

Share this post


Link to post
Share on other sites
You lost me a little Ken SCADA_Comm, 2, xxx.xxx.xxx.xx Turns into SCADA_Comm, 2, 1, 0, xxx.xxx.xxx.xx?

Share this post


Link to post
Share on other sites
I tried the above and still get IOI Syntax error... Both variables are INT's and not Arrays. Should they be arrays and can I use a BOOL?I made them INT's back when I was playing with SLC Typed Write

Share this post


Link to post
Share on other sites
I'm sorry for the confusion, let's take it back a bit. The CIP Path should be: SCADA_Comm, 2, xxx.xxx.xxx.xxx, 1, 0 That gives you three "hops", each consisting of a Port Number and an Address. "SCADA_Comm" is really "1, x" where x is the Slot number of this controller's Ethernet module. RSLogix 5000 will automatically substitute the module's name if it's in the I/O tree. "2, xxx.xxx.xxx.xxx" is "Ethernet network, IP Address", which gets the message as far as the remote 1756-ENBT or equivalent Ethernet module. "1, 0" is "Backplane, Slot 0", which gets the message to the CPU itself. Edited by Ken Roach

Share this post


Link to post
Share on other sites
That was all it needed! :o) That was the easy one. Next I'll see if I can write to a PLC behind a cell modem... after that a DSL connection. Now for an explanation for what I am doing. If this works it's going to augment a remote shutdown method that has been used here. "They" (they is me but I was forced to implement it and I don't claim the methodology that was prescribed to be safe. Neither does my boss). The layout is a pipeline system feeding a central hub with breakout tanks. The station that I worked on first is the largest and has a T1 connection, as does the hub. so Station--------------------> Station (Hub) At the hub we feed through an ESD valve, flow control valve and then diverge into (3) 80,000 barrel tanks. There are MOV's (only one per tank, ANOTHER screwup) at the inlet of each tank. The pipeline also has side laterals of much smaller capacity feeding into the line between Station and Hub. The MAOP of the line is 1,440. The Hub station piping is not. It's ANSI 150. Steam pours out of my ears every time I think of this... It should have been designed for ANSI 600. The first iteration of drawings had it designed ANSI 600. One day we will fix the header. For now the so called solution was to read a status bit in the Hub PLC and store it in the HMI database on the SCADA server, then pass the bit on to the stations in the field. When the bit goes high, which signifies that flow must stop from the outlying stations because the flow path is blocked by MOV's that have closed, the bit is transferred from the SCADA server to the field PLC's. The scenario that triggered the "solution" above was a catastrophic voltage "interruption" on the 4160v station power feed. I don't know what the power company service guy did exactly but I happened to be in the field that day and in the Hub MCC and lot's of things happened really quickly. It wasn't just a power drop out, it was numerous very fast cycles that our UPS did not like. The PLC processor faulted. All of the MOV's went closed. All of the field stations, one of which is about 4000 bbls an hour and all of which are designed for the MAOP of the line (shutdown set points are lower though) kept running. Needless to say a sudden stoppage of fluid is generally a bad idea. Not stopping inbound pumps is a worse idea. The inlet header, properly designed, went to very high pressure. The operator, in his zeal to bring the station pressure down, opened the wrong valve, since interlocked off, and over pressured the lower pressure system. Hence the "solution" that was concocted. The real solution is to fix the piping design problem and not put a stupid software patch in place. Can you tell this still pisses me off? :o) I despise when engineers try to patch their piping screwups with software. We have a comm fail watchdog that shuts a station down but the delay for reliability is set at 10 minutes. The other day the same station had an indirect lightning strike and we had a similar scenario. The "solution" almost worked. The lag time between PLC to SCADA box to PLC's was just a little too long, like 30s from trip to tripped. Not bad but what if comm was out. What if the lightning strike nailed the T1 circuit. No software solution would work then... not even what I'm doing today While this thing that I'm doing today is not the solution, as long is comm is up I can reduce 30s (or forever if the server is down) to 5s or less and we will leave the PLC-->SCADAbox--> PLC logic in place as an almost useless backup So now you know the rest of the story Allegedly a header rebuild is in the que for 2014 so I am hopeful that this becomes a useful operations tool and not an ill conceived safety solution... Edited by Michael Lloyd

Share this post


Link to post
Share on other sites
Ok back on subject- The message and cell modem seems to like: 1,1,2,xx.xx.xxx.xx,1,0 but does not respond as Primary (which is what the card is named). It sees it as SCADA_Comm. The connection times out with Error Code 1, extended error code 0000_0204 I can switch to the second card with 1,2,2,xx.xx.xxx.xx,1,0 and it returns RIO instead of Secondary. It also times out. SCADA_Comm and RIO is pretty typical for what I name the cards in a larger station PLC with a Remote IO rack. I always install one EN2T for SCADA and one for Remote IO. The scary part about that is I'm pretty sure that Card #2 doesn't even have port forwarding for it in the cell modem. That's my next thing to check. I've triple checked the IP address of the modem and it's the right one so I'm not sure what's up. ======================== Edit- The modem is right. I added port forwarding for the second card. The message is now looking at the second card. I'm back to the IOI syntax error (4) which is almost an improvement I have no idea why the cards respond SCADA_Comm and RIO. Maybe they were used in another PLC and the original names are still in the "cache" or whatever? Edited by Michael Lloyd

Share this post


Link to post
Share on other sites
I'm getting a little confused, but I suppose that's to be expected. In my experience, RSLogix 5000 will take the Module Names from the I/O tree on the project that you're adding the MSG instruction into. These are the Names that show up in the I/O tree itself, not any sort of Descriptions or Hostnames you might assign in RSLinx. I have never seen or heard about RSLogix 5000 using names from a cache or from another project. I suppose it's possible but I've never heard of it. An IOI syntax error typically means there is something wrong with the tag name in the message. Often it appears if you're trying to access a Program Scope tag; MSG instructions can only get to Controller-scope tags.

Share this post


Link to post
Share on other sites
I wasn't clear enough. It's not pulling from the module tree. The module tree shows Primary and Secondary. I drilled down to the card and checked the exact spelling of the Module Name, which is what shows up in the tree, and it clearly says Primary. Card 2 clearly says Secondary. Which is what I expected. I have the luxury, or curse depending on what time it is, of being the guy that wrote the programs. I also did about 35% - 40% of the ClearSCADA work. I can't remember my name on most days but I remember just about every detail of a program :o) At first I though that someone had changed my program. I went online and the names had not been changed Our modems are on our private network and I'm pretty sure that we don't have another one on the same IP. If we do then AT&T made a boo boo... a big one. I don't use program scope tags. Ever. But I appreciate the pointer. I wouldn't say that I'll never use them. I just make it a habit not to use them... Like the last time, I cut and pasted the tagname. The last time I had this problem adding ,1,0 to the path solved it...

Share this post


Link to post
Share on other sites
Ok, I'm starting to get suspicious that there's some kind of network weirdness going on. The first peer to peer setup was T1 to T1 The second was T1 to DSL Both of these worked perfectly (after the bug killer was sprayed) #3 is a cell modem. I expected issues but not the weirdness of pulling the wrong name from the tree. #4 is a wireless ethernet "solution" that they recently went to in lieu if cell modems. It's pulling the wrong name from the tree and it's pulling SCADA_COMM. This station is a COMPACT LOGIX. I can't put a name in a Compact Logix card. So where is SCADA_COMM coming from? #3 and #4 are giving me error 04 and I'm pasting the tag in from the program...

Share this post


Link to post
Share on other sites
It's pulling the name of the LOCAL card. It looks like all of them are pulling the local card name, including those that work. Now that I think about what you wrote Ken, that would be correct wouldn't it? Edited by Michael Lloyd

Share this post


Link to post
Share on other sites
Ha! Instead of doing a write from the PLC at the end if the line I tried a read from the field. Success! Now to try the cell modem ===================== The cell modem doesn't want to talk or listen. Oh well... it was worth a try Edited by Michael Lloyd

Share this post


Link to post
Share on other sites
I always take IOI syntax error to mean that the remote tag doesn't exist. However, I'm 99% certain that "MSG instructions can only get to Controller-scope tags" is only a limitation imposed by RSLogix5000 software. I've seen application code that manipulates the .RemoteElement of the MSG control tag, which allows read and write access to Program-Scoped tags. All the drivers out there can access Program-Scoped tags, so why can't native CIP messages, controller to controller....... If I'm right, I can't understand why RSLogix5000 hasn't been updated to allow the remote location to be input directly. This would go along with the "modularity" and "re-usable code" features touted by the sales blurb.

Share this post


Link to post
Share on other sites
I realize that you are pointing this at Ken but since this was an all day, multi comm mode, adventure I wanted to add some things. (1) Prior to adding the last hop to the address, per Ken's instruction, I was getting an Error 4 IOI Syntax. I had a couple of other instances of Error 4 that were not related to the tag. I never use Program scoped tags (repeating myself I know) and I cut and pasted the tag from the program to the "other program" with the MSG block in it. Error 4 isn't adequately described imho

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now