Trouble energizing my stop output with 5069 CompactLogix Studio 5000

[rotilahp]

Hello All,

I am new to Studio 5000. I am trying to have my limit sensors energize my stop output, and also have a manual bit that I can toggle that will energize the stop output as well. Currently, toggling my manual bit works for energizing the stop output, but my limit sensors turning on does not energize my stop output. Not getting what I want with or without the ONS. What is going on???

Thanks,

Daniel

Edited March 23, 2021 by rotilahp

[Michael Lloyd]

What are you trying to do with the unlatch contacts in the last rung? That's an odd way to use an unlatch. Where is the latch located?

[rotilahp]

How is that odd? How is that related to my problem?

[rotilahp]

I was using this to test a servo. Not a school project lol. I am new to Studio 5000. I am new to ladder logic as well. Its true, I don't fully understand ladder logic at all yet.

B) I see, I can make my outputs not series.

C) So am I not able to use SEED_STOP_O multiple times? I am trying to tell my servo controller to stop. And I want to stop it when it hits my limit sensors. How should I approach this?

D) Yeah why not???? How else am I going to tell my servo controller when it should stop?

I am building a machine. My servo controller uses basic inputs and outputs for operation. You don't seem that smart yourself. I just started learning PLC programming, so enough of your condescending comments. Helpful comments only.

 

Edited March 23, 2021 by rotilahp

[Michael Lloyd]

Ok, fair enough. Like I said, we all start sometime.

The scan is linear, ie Rung 0, 1, 2, 3, 4, 5, 6, 0, 1, 2, 3, 4, 5, 6, etc

As the ladder looks right now

Rung 0 turns SEED_HOME_0 OFF

Rung 1 turns SEED_DISPENSE_0 OFF

Rung 2 turns SEED_CLOSE_0 OFF

Rung 3 turns SEED_STOP_0 OFF.

Rung 4 turns SEED_STOP_0 OFF

Rung 5 turns SEED_ALARM_CLEAR_0

Rung 6 turns SEED_MOVE_DISPENSE OFF THEN SEED_MOVE_CLOSED OFF THEN SEED_STOP_0 OFF.

Repeat.  <--- As in all of the above evaluates at the scan rate. Sub-10 milliseconds is likely

You don't need unlatches because your rungs evaluate every scan and there is no latch. Unlatches are for latches. One exception to that is if you use an Input that is turned off and an by an HMI. The bit could feasibly be turned on by the HMI and an instant later you could lose comm with the panel and the bit will stay on. I'm sure there are other scenarios. That's just one example that I've had happen. When I use an HMI button in a routine I'll use an XIO to an Unlatch coil (both tags are the same) on the last rung.

Scan rate is likely to be in under 10ms You might be able to get a little flicker out of the logic as its written but I doubt it. 

B) I see, I can make my outputs not series. It's more common to have parallel outputs. 

C) So am I not able to use SEED_STOP_O multiple times? I am trying to tell my servo controller to stop. And I want to stop it when it hits my limit sensors. How should I approach this?

You build parallel rungs that all tell SEED_STOP_0 to turn on. X OR Y OR Z turn the output on

--] [--] [  <--- this evaluates as X AND Y

--] [--

|     |  ------------------ This ugly mess is supposed to be X with a Y branch that evaluates as X OR Y

--] [ --

 

You can get as complicated as you want to with AND and OR logic in one rung. 

Edited March 23, 2021 by Michael Lloyd

[ElectronGuru]

A quick note about placing outputs in series. Some programmers don't like putting outputs in series but if you have a large project, you can reduce scan time by avoiding branch rungs whenever possible. The best way I've found to demonstrate this is by viewing the code in ASCII, by double clicking on a rung number. When ladder logic is shown in ASCII it uses the format:

    instruction tag instruction tag

So if a rung of code consists of an examine-if-on instruction with the tag IN1, followed by an output-energized instruction with the tag PUMP2, shown in ASCII it would look like this:

    XIC IN1 OTE PUMP2

Where you have branch (parallel) rungs, in ASCII they are shown as:

    BST = branch start, NXB = next branch, and BND = branch end.

Now check out the attached pdf. The same code is shown twice, once using outputs on branch rungs, once putting all outputs in series. In both images I've opened the ASCII editor to get a better idea of the steps the controller takes when scanning the code. At a glance, it's easy to see that if the same three outputs in the first example are placed in series instead of on branches, the controller gets to take four fewer steps when scanning the code, but the outcome is the same. You can place instructions on a rung in an input-output-input-output format, which is called "interlacing", so long as the last instruction on the rung is an output. 

PLCs were invented in the late 1960s, and ladder logic was specifically developed to have a computer programming language that resembled relay logic schematics. And for the next several decades, we kept following the hardwired rule that outputs must be placed in parallel. In fact, in older software like RS500 for SLC500 controllers, placing outputs in series is not possible. But somewhere along the way it occurred to someone that these are not physical outputs, they're 0s and 1s in a processor. And with the Logix generation of controllers, they finally gave us the option of putting outputs in series and interlacing. When you're working with code that has hundreds of tags and thousands of rungs of logic, scan time is everything. And placing outputs in series is just one of the many tricks to help reduce scan time. 

Hope this hasn't been overwhelming and welcome to world of Studio5000 programming!

ascii.pdf

ascii.pdf

[alan_505]

Also unlatches can be used to turn off bits turned on by a HMI.

 

 

[Michael Lloyd]

6 hours ago, alan_505 said:

Also unlatches can be used to turn off bits turned on by a HMI.

 

 

Quote

The bit could feasibly be turned on by the HMI and an instant later you could lose comm with the panel and the bit will stay on. I'm sure there are other scenarios. That's just one example that I've had happen. When I use an HMI button in a routine I'll use an XIO to an Unlatch coil (both tags are the same) on the last rung.

I mentioned that. 

[Michael Lloyd]

8 hours ago, ElectronGuru said:

A quick note about placing outputs in series. Some programmers don't like putting outputs in series but if you have a large project, you can reduce scan time by avoiding branch rungs whenever possible. The best way I've found to demonstrate this is by viewing the code in ASCII, by double clicking on a rung number. When ladder logic is shown in ASCII it uses the format:

One of the things I like about this site is the diversity of programmers that participate here. In my line of work scan time isn't an issue but it's good to know that branches take longer than series. I'm old school. It hurts my brain to see it. I hear the routine as I type it in and I don't like the way it sounds :) 

Bonus for the day is the "viewing the code in ASCII" tip. I had never tried that.

[Joe E.]

41 minutes ago, Michael Lloyd said:

Bonus for the day is the "viewing the code in ASCII" tip. I had never tried that.

One of the things I really like about RSLogix and Logix Designer is that you can type rungs in ASCII. For example, if I want a simple seal-in rung, I just type in:

BST XIC NXB XIC BND XIO OTE

...and hit enter. I now have the layout of the rung and only need to enter the addresses. You can enter the addresses after each instruction mnemonic as well, but it's often easier to type them later because of autofill. Transcribing code from one platform to another is easier that way too than trying to drag-and-drop from the toolbars. It's also easier to type it in when you start to get into math and move instructions that are on different tabs of the toolbar.

[BobLfoot]

I'll also inject that when you reach the semi-pro level you'll find you can use VBA or Macros in excel to write your code.

I had a project at one job where we laid the I/O into Sheet 1 , Ran the macro and the finished code ready for import to PLC5 was on sheet 2.

Same can be done for Control/Compact Logix.

[ElectronGuru]

@Michael Lloyd I came up through relays and didn't start learning logic until the mid 90s. I started in ControlLogix with version 16 and the first time I saw OTEs in series, I though my head was going to explode. I programmed for another few years using only parallel until I got to a power plant, where scan time was everything. I find that since leaving that job I'm still putting OTEs in series, and still looking for anything that'll reduce scan time, even when it's not all that necessary.

@Joe E. If you take it a step further (and know your tags that well) you can type the whole thing out in ASCII. To use your example:

    BST XIC Tag1 NXB XIC Tag2 BND XIO Tag3 OTE Tag4 

 

[Joe E.]

3 hours ago, ElectronGuru said:

@Joe E. If you take it a step further (and know your tags that well) you can type the whole thing out in ASCII. To use your example:

    BST XIC Tag1 NXB XIC Tag2 BND XIO Tag3 OTE Tag4 

Indeed! I started with RSLogix 500 using addresses instead of symbols (the machines I learned on just didn't use symbols) so, I got used to not typing in all of the operands. It's also easier to keep it all straight in my head (limited space, after all) without the addresses/tags/symbols. A lot of the stuff I've worked on in the 5k world has had long tag names that are a *pain* to type in "longhand", so it's been easier to use the autofill after the rung is there.

I was in a Logix 5k class one time with a guy who had some Logix 5k experience but none with 500 and I just typed in a rung like that without looking...and he was impressed. :)

[Michael Lloyd]

Some of the best programmers that I've ever followed (converting to Logix) were SLC programmers.

I started with the Siemens S5, then went to TI505 (which is still viable), then moved to the Siemens S7-300 and S7-400, then Logix. I have Logix programs that I would rewrite for free if the customer would let me lol.

Quote

@Michael Lloyd I came up through relays and didn't start learning logic until the mid 90s. I started in ControlLogix with version 16 and the first time I saw OTEs in series, I though my head was going to explode. I programmed for another few years using only parallel until I got to a power plant, where scan time was everything. I find that since leaving that job I'm still putting OTEs in series, and still looking for anything that'll reduce scan time, even when it's not all that necessary.

If think I started on 10 but I don't remember. I stayed with 19 until a few years ago. It was rock solid and did all I needed it to do. You probably had a bunch of multicolored jumpers :) I saw my first PLC in 1979 but didn't have a clue what it was. I was 20-21 in 1979. I'm not 20 now lol
All through the 80's everywhere I worked used big relay panels (gas processing plants). Relays and one-line diagrams seemed to make life simple. 

 

Edited March 23, 2021 by Michael Lloyd

[JustinSmith]

I started with slc. Also slc is older than I am.

Edited March 23, 2021 by JustinSmith

[BobLfoot]

I started with 5TI in school, then Toshiba T1,T2 & T3 then switched to SLC5/04 ; PLC5 and CLGX Gateway which came before Version 1.

 

[Joe E.]

First one I messed with (early 90s) was a GE Fanuc 90-30 using LM90 on a offshore service vessel bouncing around the Gulf of Mexico. Got online (barely, once or twice in 5 years) for troubleshooting and that's it. Then I got a job in a SLC500 plant as maintenance where I barely touched them, even for troubleshooting (I was multi-craft with most of my time being mechanical and basic electrical). I then moved on to another plant with SLC500 and S7-300/400. That's where it got real. I had week-long programming 1 classes in both SLC500 and S7. Dabbled with a Mitsubishi and A-D DL05 too, but only a little. Then the great recession shut that down. I ended up in a plant that had PLC-2, PLC-5, SLC100/150, SLC500, Compact/ControlLogix, and S7-300. Now I'm where we have SLC500, Compact/ControlLogix, and Beckhoff TwinCAT.

I've used Excel and Notepad++ to copy/edit repetitive rungs, but I haven't quite gotten to where I'm using VBA macros to generate code from scratch. I can definitely see the power, though.

[BobLfoot]

IT has definite use in multi-cell implementation where each cell has the same I/O and same function and all that changes is the addressing of the I/O points.  I used it in a warehouse where there where 48 identical cells and all ran the same routine.  Wrote the code in 2 days rather than 2 weeks.

[Michael Lloyd]

2 hours ago, Joe E. said:

First one I messed with (early 90s) was a GE Fanuc 90-30 using LM90 on a offshore service vessel bouncing around the Gulf of Mexico. Got online (barely, once or twice in 5 years) for troubleshooting and that's it. Then I got a job in a SLC500 plant as maintenance where I barely touched them, even for troubleshooting (I was multi-craft with most of my time being mechanical and basic electrical). I then moved on to another plant with SLC500 and S7-300/400. That's where it got real. I had week-long programming 1 classes in both SLC500 and S7. Dabbled with a Mitsubishi and A-D DL05 too, but only a little. Then the great recession shut that down. I ended up in a plant that had PLC-2, PLC-5, SLC100/150, SLC500, Compact/ControlLogix, and S7-300. Now I'm where we have SLC500, Compact/ControlLogix, and Beckhoff TwinCAT.

I've used Excel and Notepad++ to copy/edit repetitive rungs, but I haven't quite gotten to where I'm using VBA macros to generate code from scratch. I can definitely see the power, though.

The last plant I managed had a redundant GE RX3i system (about 3 years ago). It's was newer than the 90-30 by quite a bit but not up to Rx7i standards. I hated that system. After working with S7 and CLX I've turned into a PLC snob lol 

When I contracted to the company I work for now I did a couple of burner management PLC's in that plant. The first BMS was done with a CLX, then next one was GE because the plant manager at the time "didn't like Allen Bradley". He didn't even know how to spell Allen Bradley but that's what the subcontractor he used liked. So, I used an Rx3i on that BMS. Same basic program just in a different platform. I'm a big fan of UDT's. I live by the tag lol The contract guy that did all of their GE work hated my BMS program lol. Today... that same guy loves the CLX stuff and doesn't ever spec GE. We hired him to replace me when I transferred to NM. I have standardized routines with standardized tag structure. Pump control, valve control, etc each have a starting ladder structure that can be modified. If I need to add a pump, I just create a new pump tag, copy the existing routine to a new routine, search and replace the tagname (before the .), fix the shutdown string and add or delete whatever I need. At the peak of building the pipeline system we built in the Eagle Ford I could write a 3 pump, 4 tank station program in one day and build out the HMI (ClearSCADA) the next day. I didn't reuse old programs. I started clean every time. Make the IO sheet complete with tag names, transmitter list, alarm and shutdown list, and cause and effect. Do some cut / paste import / export tag stuff, pull in all of the UDT's needed, create all of the tags, start programming. It seems like oil and gas is a different animal than machine or factory floor automation. We use a lot of analog inputs. The largest station that we built had 241 analog inputs (quite a few of those were calculated variables), 255 analog input "tag slots". It took about 30s to document them via an Excel sheet (with a VB backend) and csv import.

I start with a base program that has text in the description to make it a simple cut / paste operation. 53 station programs spec'd, panel and transmitters ordered, FAT done (btw the FAT's were linked back to the HMI server with a cell modem so validating the panel wiring also validated the HMI), and pre-startup checkout done in a hair over a 3 year time period. At one point I had 6 programs in progress at the same time. I didn't get to the point of being able to write the programs in a day until about 1/2 way through the system build out. While that was going on I was also the guy they called when something wasn't working right. Baptism by fire but I'd do it all over again. 

The analog UDT looks like this:

String1    STRING        Tag    Read/Write    1    0
String2    STRING        Description    Read/Write    2    0
PV    REAL    Float    Scaled Process Variable    Read/Write    3    0
AHHA    REAL    Float    High High Alarm Setpoint    Read/Write    4    0
AHA    REAL    Float    High Alarm Setpoint    Read/Write    5    0
ALA    REAL    Float    Low Alarm Setpoint    Read/Write    6    0
ALLA    REAL    Float    Low Low Alarm Setpoint    Read/Write    7    0
Deadband    REAL    Float    Alarm Deadband    Read/Write    8    0
HH_Limit    BOOL    Decimal    High High Alarm Bit    Read/Write    10    0
H_Limit    BOOL    Decimal    High Alarm Bit    Read/Write    11    0
L_Limit    BOOL    Decimal    Low Alarm Bit    Read/Write    12    0
LL_Limit    BOOL    Decimal    Low Low Alarm Bit    Read/Write    13    0
MinEU    REAL    Float    Transmitter LRV for HMI    Read/Write    14    0
MaxEU    REAL    Float    Transmitter URV for HMI    Read/Write    15    0
EnableAlarmHH    BOOL    Decimal    Enable HH Alarm    Read/Write    17    0
EnableAlarmH    BOOL    Decimal    Enable H Alarm    Read/Write    18    0
EnableAlarmL    BOOL    Decimal    Enable L Alarm    Read/Write    19    0
EnableAlarmLL    BOOL    Decimal    Enable LL Alarm    Read/Write    20    0
Status    DINT    Hex    Alarm Block Status    Read/Write    21    0

The Motor UDT (anything with and electric motor uses this one)

String1    STRING            Read/Write    1    0
String2    STRING            Read/Write    2    0
SW    INT    Decimal        Read/Write    3    0
A    BOOL    Decimal        Read/Write    5    0
A_Stop    BOOL    Decimal        Read/Write    6    0
A_Start    BOOL    Decimal        Read/Write    7    0
Stop_I    BOOL    Decimal        Read/Write    8    0
Start_I    BOOL    Decimal        Read/Write    9    0
HMIStop    BOOL    Decimal        Read/Write    10    0
HMIStart    BOOL    Decimal        Read/Write    11    0
RunStat    BOOL    Decimal        Read/Write    12    0
Stop    BOOL    Decimal        Read/Write    14    0
Run    BOOL    Decimal        Read/Write    15    0
AStop_OS    BOOL    Decimal        Read/Write    16    0
AStart_OS    BOOL    Decimal        Read/Write    17    0
FStart_OS    BOOL    Decimal        Read/Write    18    0
HStart_OS    BOOL    Decimal        Read/Write    19    0
SOS    BOOL    Decimal        Read/Write    20    0
RH    DINT    Decimal        Read/Write    21    0
S    DINT    Decimal        Read/Write    22    0
FailTMR    TIMER            Read/Write    23    0
T1    TIMER            Read/Write    24    0
T2    TIMER            Read/Write    25    0
T3    TIMER            Read/Write    26    0
T4    TIMER            Read/Write    27    0
T5    TIMER            Read/Write    28    0
T6    TIMER            Read/Write    29    0
T7    TIMER            Read/Write    30    0
T8    TIMER            Read/Write    31    0
T9    TIMER            Read/Write    32    0
T10    TIMER            Read/Write    33    0
RMT    TIMER            Read/Write    34    0
RMC    COUNTER            Read/Write    35    0
 

Basically anything that we needed for an analog tag is in the Analog udt and anything that could come up for a pump or other motor driven device is in the motor tag. The larger REDA pumps used every timer. Things like low suction shutdown delay, vibration shutdown delay (1s), start sequencing... all kinds of stuff. If I needed to see what was going on with P-9001 I just expand the tag called P9001.

The two strings are used by the HMI in the faceplate that pops when you click on the value box. The guy that wrote the ClearSCADA back end made templates that matched the UDT's that I used. To "make" a point on the screen you create the tag in the HMI, run a script that replaces Analog[10] with the correct Analog[x] value, drag the mimic to the screen. Poof... What was really handy was copying a whole station to a new group and running a global script that replaced the station number. Like this - Lets say I have Station 9000 built. They decide to build Station 7000. Btw... I picked the numbering system so that made it easy. The pumps in station 9000 were P901, P902, and P903 for the boosters and P9001, P9002, and P9003 for the mainline pumps. Station 7000 only had 2 of each. Copy past the station folder to a new folder named 7000, search and replace the 9 with a 7, delete the two extra pumps, done. The same applied for MOV's (motor operated valves), tanks, tank mixers, etc. The main caveat is that the numbering and naming had to be tightly controlled and there was a little bit of crystal ball stuff going on. Station 9000 was easy, It was at the end of the mainline. Picking what all of the stations upstream would be numbered was a SWAG because there was no way to know how many booster stations were going to be on the pipeline. Back then oil was over $100.00 a barrel and the Eagle Ford was going to last for at least 10 years. We were moving 150,000 BPD at the peak. You can increase capacity on a pipeline three ways, increase the diameter, loop the line with a second pipeline, or add a booster station and breakout tanks. 1 and 2 were not an option, so 5000 was around the middle, 1000 was at the beginning, and I just hoped the numbering I picked for everything in between worked otherwise I was going to have to do a lot of work renumbering. We could have got out of order, Nobody but me would have cared and it would have driven me nuts lol. It worked out. No renumbering required.

Gas plants are little more tedious due to tags needing to match P&ID and other PSM docs. But with the right pre-planning and tag structure it's not that hard.

 

[Michael Lloyd]

PS - I hated the Rx3i system because it failed one weekend. The primary controller AND the redundant controller lost their program. Like gone. Nobody home. Sorry, I can't hear you... The IO was programmed to hold last position. The operator looked around and said he only had one PID controller on that system and he wasn't using it so there was no need to shut down. That's correct... the plant was still running with a brainless PLC. I called our engineer, explained what I was told, and we left it alone. The plant ran all weekend like that. Well guess what, when we finally loaded a program in the PLC we found out that a good 65% of the PID loops were on a remote rack that everyone had forgotten about AND the GE (pos) doesn't store the PID loop parameters in the saved file. When the guy we called out to dump the program in (I refused to touch that thing) and switched to run, all hell broke loose. :) Nothing that the ESD button wouldn't fix... It took all day to pull the PID config out of the HMI historian and reconfigure all of the PID loops.

We sent the controller to GE to analyze why the primary and secondary lost their minds... They charged for the service. The answer? Couldn't find anything. :/ 

[BobLfoot]

@Michael Lloyd you may want to look into Excel VBA.  Placing your P&ID Tag Information on One Sheet and a Macro to craft your standard logic you could churn out a system in a couple hours.  Plus another couple to sanity check the macro.

[Michael Lloyd]

2 hours ago, BobLfoot said:

@Michael Lloyd you may want to look into Excel VBA.  Placing your P&ID Tag Information on One Sheet and a Macro to craft your standard logic you could churn out a system in a couple hours.  Plus another couple to sanity check the macro.

I need to. I wrote an orifice plate sizing calc that I used VBA in the background. It's been a long time since I looked at it though.

I wonder where the OP went?

Edited March 24, 2021 by Michael Lloyd

[Joe E.]

18 minutes ago, Michael Lloyd said:

I wonder where the OP went?

We did kind of hijack the thread, didn't we...