RSLogix 5000 Help

is there any help docs for creating code using the structured text in RSlogix 5000??
Im very strong in programing in strutured text in the true IEC form but Im Strugling with the AB stuff
Thanx

The help files. Just open the help, type in the command you want to use, and they have a little explanation and even a little part you can copy & just change variables if you want.

Cool Thanx that kinda helped. im just not sure how to declare an object
Im ne to this software so kinda just fumbling through it.

IECmAn said:

Cool Thanx that kinda helped. im just not sure how to declare an object
Im ne to this software so kinda just fumbling through it.

Click to expand...

Easy. Type out what you've got for a variable or object, now put the cursor on the end of the word, then right click it, select create new tag, select which type of tag you want, and click OK.

Under help in RSLogix5000 there are links to the manuals (pdf format) - hopefully you installed the documentation with the software.

Just my two cents, depending on what you are trying to accomplish, I may shy away from structured text. It is extremely difficult to troubleshoot a problem, compared to something programmed in ladder or function block. I would think that if you have programmed structured text, function block would be very easy for you. That's my 2 cents.

Just my 2 cents, but ST is not difficult to troubleshoot. If you take an obejct oriented approach to programming you don't even need to look at the program code to troubleshoot, you can just look at the UDT tag.

IME, unfamiliarity with ST is the primary cause of diffultities with it.

ST executes faster than ladder, especially for code with a lot of math and comparisons.

I guess what Alaric said has some truth to it, and would be the case for everyone, however, it's been my experience that the guy writing the program does less troubleshooting than the the maintenance type personnel who actually maintain the machine. When it comes to real world problems that aren't "logical", they've all appreciated the ladder and FB, and basically complained the most about the structured text.

Just my 4 cents

Alaric said:

Just my 2 cents, but ST is not difficult to troubleshoot. If you take an obejct oriented approach to programming you don't even need to look at the program code to troubleshoot, you can just look at the UDT tag.

Alaric:

I respectfully disagree, STL can (not always) be a pain in the a$$. Just as in ladder if the author of the program did not take the time to document properly and does not have a clue on how to structure a program (my self included), or speaks Dutch. Then no matter what the approach, ladder is easier to trouble shoot, I have many S5 examples if you would like to see them.

Now that being said, just from your comments on here you are twice the programmer then I ever expect to be, so I may (not now) find someday that not only programming is easier but trouble shooting as well.

Click to expand...

Click to expand...

sometimes an example helps ...

Greetings IECmAn,



if you used the default settings for the installation of RSLogix5000 then you probably have some "structured text" programming examples already on your computer ... explore and look for the “SAMPLES” folder ...








I think that the ones that I’ve circled might come in handy ...



survival tip: just some friendly advice ... if you’re writing this “structured text” program for a customer, I’d suggest that you run a short sample of it by him for approval before you go too far with things ... I know of at least one instance where a project had to be done over because “Old Joe” the plant’s “PLC guy” didn’t know anything about structured text ... so I’m not debating whether “structured text” is easy - or hard - to troubleshoot ... my opinion doesn’t matter ... but there just might be an “Old Joe” in your situation and his opinion might be VERY important ...

What I am advocating is having a toolbox full of tools, not necessarily using ST over LL in a particular situation. Learn all of the PLC languages and then pick the language that best fits the application. Most of my CLX programs use a mix of LL, ST, and FB.

I mentioned taking an object oriented approach. One of the most powerful tools IMO of the CLX is the UDT (user defined data types). UDTS enable the PLC programmer to develop an object oriented program. I'm a big fan of object oriented programming, which if carefully structured can eliminate the need to view the program code in some cases. The maintenance tech can open the tag, inspect the values of the components in the UDT, and determine what the problem is.

As someone else here wisely pointed out once, the PLC program "knows" why it isn't working.

Here is a sample UDT that defines an object for a solenoid valve output. In this paticular program there are about a dozen instances of the solenoid output object. A single HMI pop-up screen can be used to view all of the information embedded in the UDT for each of the valves, as well as safely (with interlocks) force the valve on/off - which should be enough in about 99% of the cases for a maintenace tech to determine what is wrong without having to look at the actual software.




Ron's advice is very timely. If you are writing for a customer you need to meet you customers specs. But just as customer A may spec ladder only, customer B will spec ST or FB for certain tasks, so develop your tool box - that means not shying away from ST because it is difficult at first. Trust me, it will get easier.

Alaric, I am not familiar with troublshooting with UDT's. In your example, what member actually controls the output of the valve. Also, where would you turn when the state of this is a zero, or meaning that the valve is not activated? Basically, how can one cross reference this. Maintenance people I know might be interested in this, but not unless it's actually usefule to them. Lets say in your example the valve in question will not fire. They look this up, and see that the PLC is not telling it to fire. Where do they go then to see why the PLC is saying not to fire, and how do they know how to get there?

Let's put this to the test; by inspecting the UDT I'd expect "Output" to actually control the valve. If I'm right then both Alaric and I look good!

In this particular application there is a short subroutine named _solenoid_ouput that is used for all outputs. Several tags are defined, all are type solenoid_output. Each of the 12 solenoid_output tags are passed to the subroutine which processes each of the valves identically. One would be called SV_4010 for example. When the logic needs valve SV_4010 to be on, the user program sets SV_4010.AutoOut. If the valve is to be forced on/off then SV_4010.ManOn or SV_4010.ManOff is set by the HMI. Since ther are portions of the process where it is unsafe to allow forcing on/off of the valve, the logic set the SV_4010.interlocked bit at these times. When _solenoid_output(SV_4010) is called then if the program has requested the valve, or if the operator has manually turned on the valve, and it is safe to do so, then the _solenoid_output routine sets the SV_4010.Out bit. Since RSLogix 5000 does not support UDT element aliasing, immediately after the suroutine returns the program executes XIC SV_4010.OUT OTE SV_4010_Output. I understand that UDT element aliasing is coming soon though and when it does then you just alias SV_4010.Out directly to the hardware output. The subroutine also handles all of the error checking and sets the appropriate status bits in the UDT.

Over on the RSView HMI there is a screen named SolOutFacepate. This screen uses a tag name substitution file. Thus the operator can select the valve and view it the UDT contents on a face plate.

Of course this all assumes that the program is debugged and the troubleshooter is really trying to find out what external device has failed.

I would post the subroutine except that I am not the one who wrote it but it was written by an associate of mine who has graciously shared it with me - and without his permission I am heistant to divulge the actual code.

Russ,

If I understand Alaric, then the screen he displayed is for about a dozen different solenoid valves, and without the HMI, or a detailed knowledge of ControlLogix, the average maintenance person won't be able to troubleshoot it. Programmer job security, anyone?