Controllogix

Monitoring Tags

NorthControl, There's a standalone custom data monitor tool supplied with Logix5000; you should find it in the \enu\tools directory together with some other useful stuff. It's not the same as the built-in Custom Data Monitors in Logix5/500 but it can perform a similar function.

FWIW

There's a standalone custom data monitor tool supplied with Logix5000;
<snip>
It's not the same as the built-in Custom Data Monitors in Logix5/500 but it can perform a similar function.

Click to expand...

From the text file that comes with that CDM tool:

The Data Monitor tool is unable to operate with RSLinx Lite!

The Data Monitor Tool utilizes the OPC tag access capabilities of RSLinx which is only available in a purchased version of RSLinx (OEM, Professional, Gateway).

Click to expand...

And it's HUGE, so you can't see the ladder and the data at the same time, despite a "always on top" option.

And you can't drag/drop tags into it.

But otherwise, it works pretty much the same way.

NorthControl said:

any ideas about how to monitor the tags you need, and NOT all the ones you don't need (tag list)?

Click to expand...

With the right version of RSLinx, you can use DDE topics in Excel.
Then, you can save your tag list, too.

I've been using a spreadsheet that I created to read, write, and simulate data.

I'm sure there are other tools out there.

AK

Re: so what did I step into anyway? ...

Ron Beaufort said:

... but I’m certainly not alone in wishing that the guys developing the RSLogix5000 software had spent a lot more time researching what was “good” about RSLogix5 and RSLogix500 before they started reinventing the whole darn interface wheel ... (the rumor that I’ve heard is that it’s not even Rockwell software but some third party contractor doing the software development) ...

Click to expand...

The origins become obfuscated with time...

This is my understanding:
RSLogix 5 & 500 were/are developed entirely by the West Allis contingent of Rockwell Software - the group formerly known as ICOM.
RSLogix 5000 was developed by the Cleveland contingent of Rockwell Software - formerly part of Allen-Bradley. It wasn't called RSLogix 5000 when started, of course, not least because at the time there was no RSLogix 5 or 500 either. Back in the early/mid '90's when they were developing what eventually became known as ControlLogix (I think they called it "tempest") in Cleveland, they of course needed programming software...
I don't know if Rockwell Software still maintain "east & west campuses" (campi?), but, most likely the further enhancement of RSL5000 is now under the same roof as the RSL5&500 teams.

The PLC-5 and SLC/MicroLogix processors have such nearly identical architecture that it's no surprise that their programming packages have the same "look and feel". I believe they're close enough that only one programming package should be required. But the CLX is so fundamentally different that I doubt you will ever see some of the features you feel are "missing".

Hi all

How do you search/reference for "tags" if their is no find all in RSLogix5000?

Does that mean you have to search for every instance of a tag manually?

How do you search/reference for "tags" if their is no find all in RSLogix5000?

Click to expand...

Just select the tag, right click and at the top of the context menu is "cross reference". Or the shortcut key is "Cntrl_E".

Works better than the PLC/SLC software because it also shows which are the instances of the tag where it is being written to, ie "destructive".

While we are on the Controllogix topic...

There is a "find all" in Version 13, just not implemented.

Also, can someone tell me why I can't assign an alias to a tag inside an UDT, is this AB's way of forcing us to use buffer?

harryting said:

Also, can someone tell me why I can't assign an alias to a tag inside an UDT, is this AB's way of forcing us to use buffer?

Click to expand...

Think about it...

An alias is just that. It is an alternate name for something. There is only one something that may be called by several different names. Most people on this forum use an alias to log in. They are known to friends, relatives, workmates by other names. But they are one person - analagous to the 'base tag' in CLX - and unique.

...this metaphor is getting too invovlved

When you create a tag of your UDT type, it is a base tag - it occupies real memory space. You can create aliases to it or any part of it, but the alias tags do not have separate memory locations, they just point to the base. You cannot alias parts of the UDT to anything else. I can imagine what you would like to do - have bits of your UDT pointing to various scattered I/O points. That would be equivalent to trying to alias bit 1 of DINT_VAR_1 to bit 6 of INT_VAR_3. They are two real memory locations - unique - and one can't impersonate the other.
beerchug

Non-trivial to implement. I understand that it MAY be on the "to do" list.

Also it comes with an inherent problem. At what point in the program is the alias updated? Whenever an alias tag is referenced the logic points through the alias to the base tag to extract the current value.

But if the alias is lurking within the bowels of structure (UDT) it is not at all obvious when the base tag value is extracted. If for example the UDT tag then gets passed into a subroutine when did the sub-element that is also an alias get updated with the current value of it's base tag? There may well have been been no direct reference of the sub-element tag in the program at the point the subroutine was called, so there has been no extraction of the base value.

I'm not sure this is a show stopper but it is an aspect to think about. Personally I don't like aliasing tags at all and never do it.

PS Gerry and I were busy typing away at the same time . I think his explanation is more fundamental than mine. I was also thinking along the lines of a conversation with Ron Bliss last year when this subject was brought up. He didn't categorically rule it out, but he was dubious about the value of adding such a feature for all the complications it might introduce. It seems a simple thing to ask for on the surface, but it is not so under the hood. Mainly for the reason Gerry outlines.

well, I don't want to start a fight ... but ...

Greetings Gerry,

back in post #5 I made the following statement:

... with a PLC-5 all of the inputs (“I:___” addresses) are read from the field ONCE at the very start of the scan ... the values in those bits won’t change (unless you program something really weird) all the way through the processor’s execution of the ladder program ... and then finally the outputs (“O:___” addresses) are written to the field ONCE at the very end of the scan ...

Click to expand...

and then you came along in post #15 and contradicted me when you said:

Only if it's Local I/O. Remote I/O is asynchronous.

Click to expand...

now no offense intended, but honestly I’m still convinced that I’m right ... and that you’re wrong ... and here are some of the reasons why I feel that way ... first of all, in the official book:

PLC-5 Enhanced and Ethernet Controllers - User Manual

on page 6-3 [Adobe Reader page 70 of 325] we find the following note:

... channel 1B continually scans the ... racks in its scan list and places the data in the remote I/O buffer in the processor. The processor updates its own buffer and the I/O image table. During housekeeping, the two buffers are updated by exchanging the input and output data with each other.

Click to expand...

and then on page 6-11 [Adobe Reader page 78 of 325] we find this chart ...

[attachment]

please consider this note which I’ve highlighted:

The remote I/O scan is independent of and asynchronous to the program scan.

Click to expand...

and this is the part, Gerry, that I think is confusing you ... the point is that yes, the remote I/O IS being scanned asynchronously to the processor’s scan of the ladder logic program ... BUT ... (and here’s the tricky part) during that period while the processor is scanning the ladder logic program, the remote I/O is only moved into and out of the “remote I/O BUFFER” ... it is NOT moved into and out of the “input IMAGE TABLE” and the “output IMAGE TABLE” as you apparently believe ... specifically, this “remote I/O buffer” is completely separate from the processor’s “image tables” which are constantly being accessed while the ladder logic program is being executed ...

continuing on ...

we also see this note which I’ve highlighted:

During housekeeping: Data exchange between the I/O image table, the processor-resident rack, and the remote I/O buffer occurs.

Click to expand...

notice specifically the statement “during housekeeping” ... that “housekeeping” piece of the puzzle is a brief ONCE PER SCAN window ...

and then the book seems to confuse the issue with this note – circled in red:

Remember that the I/O scanner is constantly updating the remote I/O buffer asynchronously to the program scan.

Click to expand...

at first glance this statement certainly seems to bear out what you were saying, Gerry ... and quite possibly this is also confusing you ... but take another look at the phrase that I’ve underlined in red ... it’s only the “remote I/O BUFFER” that’s being updated constantly ... NOT the processor’s “input image table” and the “output image table” ... and that’s where my statement and your statement are completely at odds ...

to nail this all down, I think that you’re confusing the processor’s “image tables” (input and output) with the completely separate “remote I/O buffer” ... the “image tables” contain the data which we see when we monitor the PLC’s “inputs” and “outputs” ... and the data on these two tables is the data that the processor “looks at” and “writes to” as it executes the ladder logic program ...

so here in a nutshell is what goes on in a PLC-5 system which uses both local and remote I/O ... that loop on the left side of the figure shows that the remote I/O is indeed being continuously updated asynchronously to the processor’s scan of the ladder logic ... that much I certainly don’t dispute ... BUT ... during the processor’s trip through the ladder logic program, the data in the “remote I/O buffer” remains completely isolated from the processor’s ladder logic ... finally, during that brief ONCE PER SCAN window labeled “housekeeping” on the separate loop at the right of the figure, the two loops “communicate” and exchange their remote I/O data with each other ...

and that’s why I’m still firmly convinced that my earlier statement is completely correct ... specifically, with a PLC-5 system, the values in the bits with “I:___” addresses will not change all the way through the processor’s execution of the ladder program ... and my statement holds true whether the “I:___” addresses are associated with LOCAL inputs – or with REMOTE inputs ...

and by the same token, the outputs are also handled only once per scan ... regardless of whether they are LOCAL outputs or REMOTE outputs ...

now for completeness, let me mention this: it IS possible to change the rule I posted by programming in something like an IIN (Immediate Input) instruction ... or by “hijacking” the status of an input bit by writing to it with something like an OTE ... and there are other ways ... but that’s getting into the “really weird” programming that I mentioned in my original statement ... and it certainly does not pertain to any difference between (as you suggested) “local I/O” and “remote I/O” ...

now ... if you’re anything like I am and don’t trust everything that you read in the books, here is a little experiment to prove that what I’m saying is correct ... suppose that I program the spare PLC-5/30 on my desk with the “double-coil program from hell” ... specifically, I put in sixteen rungs ... and each rung controls “O:032/0” with an OTE ... then I condition the first rung with an XIC for “B3/0” ... but I condition the second rung with an XIO for “B3/0” ... and then I continue that alternating XIC/XIO pattern all the way down through all sixteen rungs ... of course, address “O:032/0” is located on a remote I/O unit ... and so now the stage is set ...

next I place the processor in the run mode and watch the LED on the remote I/O unit ... whenever the “last rung” in the program is TRUE, then the LED for “O:032/0” lights solid on ... and whenever the “last rung” in the program is FALSE, then the LED for “O:032/0” goes completely off ...

now the point, Gerry, is this ... IF (I repeat IF) you happened to be correct, then the LED would be expected to “flicker” every once in awhile ... because ... since the status of “O:032/0” on the “output image table” is continuously being flip/flopped by the alternating “on/off” rungs, then it would be only a matter of time before the asynchronous “remote I/O” update (that you’re suggesting) would affect the field output ... and the LED would occasionally flicker briefly between on and off ...

but that doesn’t happen ... specifically, the LED is either always completely on ... or always completely off ... (depending on the status of “B3/0”) ... but specifically, the LED never flickers ...

in short, this “REMOTE” I/O bit functions in PRECISELY the same way that a “LOCAL” I/O bit functions ... the “update” difference between “local I/O” and “remote I/O” that you suggested simply does NOT exist ...

and that means that I was right ... and you were wrong ... the experiment that I’ve just detailed should prove this point to your satisfaction if you want to try it yourself ...

and incidentally ... if you’ve got your heart set on seeing the LED flicker, just program an IOT (Immediate Output) rung about halfway through the program ... you can use this instruction to force an “immediate” update DURING the ladder logic scan ... but to make the LED flicker, you’ll have to insert the IOT right after a rung which drives “O:032/0” to the opposite status produced by the “last rung” of the program ...

now ... as for the other processor platforms which you brought into the discussion ...

The 1774 (PLC-1) was asynch (all remote I/O)
PLC-2 introduced synchronous I/O, but only for local. remote I/O is asynch.
PLC-3 is asynch (all remote I/O)
PLC-5/250 is asynch ( all remote)
ControlLogix is asynch (even for local I/O).

Click to expand...

I’m perfectly willing to defer to your opinion on these ... personally I’ve led a very sheltered life and I’ve never worked on the 1774 (PLC-1) ... or the PLC-2 ... or the PLC-3 ... or the PLC-5/250 ... so if you say that these platforms use asynchronous I/O, then I have no reason to disbelieve you ...

but then again, since I didn’t include any of these other platforms in my original statement about the PLC-5 scan cycle, I feel no need to discuss them further ...

for the benefit of our less-experienced readers I will say this: despite its “PLC-5” model number, the PLC-5/250 that Gerry mentioned is NOT one of the “regular” PLC-5 processors that I included in my original statement ... this is a “special” type of system called a “pyramid integrator” ... if you’ll refer to this link you’ll see that the PLC-5/250 doesn’t even support “I:___” or “O:___” addresses at all ... (note the “N/A” entries on the chart) ... and since my original statement specifically mentioned the PLC-5’s “I:___” and “O:___” addresses, then I clearly had no intention of dragging the special PLC-5/250 into this particular conversation ...

Click to expand...

so in closing, Gerry, please take another look at the evidence ... and run the experiment I mentioned if you need to ... and then let me know if I’ve changed your mind about this ... or perhaps I’m missing something? ... if so, please point it out ... personally, I’m always ready to learn something new ... and I don’t mind admitting an error whenever I’ve been proved wrong ...

anyway ... in my humble opinion, my original statement was completely correct ... and your contradiction was wrong ...

the defense rests, your honor ...

Hello, everybody,

In a nutshell, the more you use it, the more time you'll save, the more things you'll find you can do easier, and the more you'll like it.

I've done 3 major projects, so far. I've liked it each day more than the day before.

For instance, a string data type contains 82 characters and takes loads of memory, if you do 100 recipes along with a 200 batch history, with 20 ingredient names each. Well, I just had the recipes in, and the customer asked for the History. I was close on memory and the history would have put me over. But alas, AB gave me the opportunity to create a user defined string tag with as little as one character (I used 10). I changed the ingredient to this 10 char data type, added the 200 batch history, and ended up with a lot more memory than before I added the History.

Every time you come across a new problem, you'll find a handy feature to help you out.

Salutations Ron,

and then you came along in post #15 and contradicted me

Click to expand...

but the main point of my post was this:

So...asynchronous I/O scan is nothing new.

Click to expand...

As usual, your rebuttal is thorough, but somewhat patronising. I must defer to your exhaustive research.

on page 6-11 [Adobe Reader page 78 of 325] we find this chart ...

Click to expand...

They must have slipped that in while I wasn't looking I wonder if you can find similar information for the "classic" PLC-5's (5/15, 5/25)?

now ... as for the other processor platforms which you brought into the discussion ...
(Quote
The 1774 (PLC-1) was asynch (all remote I/O)
PLC-2 introduced synchronous I/O, but only for local. remote I/O is asynch.
PLC-3 is asynch (all remote I/O)
PLC-5/250 is asynch ( all remote)
ControlLogix is asynch (even for local I/O).

I’m perfectly willing to defer to your opinion on these ... personally I’ve led a very sheltered life and I’ve never worked on the 1774 (PLC-1) ... or the PLC-2 ... or the PLC-3 ... or the PLC-5/250 ... so if you say that these platforms use asynchronous I/O, then I have no reason to disbelieve you ...

Click to expand...

Trust me, you can easily turn contactors into buzzers with these if you're careless.

since I didn’t include any of these other platforms in my original statement about the PLC-5 scan cycle, I feel no need to discuss them further ...

Click to expand...

I included them to illustrate my point, which I will repeat:

There's nothing new about an asynchronous I/O scan

As for this:

(Quote
for the benefit of our less-experienced readers I will say this: despite its “PLC-5” model number, the PLC-5/250 that Gerry mentioned is NOT one of the “regular” PLC-5 processors that I included in my original statement ... this is a “special” type of system called a “pyramid integrator” ... if you’ll refer to this link you’ll see that the PLC-5/250 doesn’t even support “I:___” or “O:___” addresses at all ... (note the “N/A” entries on the chart) ... and since my original statement specifically mentioned the PLC-5’s “I:___” and “O:___” addresses, then I clearly had no intention of dragging the special PLC-5/250 into this particular conversation ...

Click to expand...

The link you provide could hardly be considered an authoritative reference on the 5/250. Yes, it does have I and O addresses. The designers wanted to call it PLC-6 but marketing over-ruled.

Greetings Gerry,

thanks for taking this in the right spirit ... I just hate when little mistakes creep into the forum - and then lurk there for years and years ... especially when I put them in there ... a lot of people will probably be using the stuff that we write here for many years to come - so I work very hard to make my posts as accurate and non-ambiguous as I can ... some times I win ... sometimes I lose ... but I still like for the final product to be as correct as possible for people searching for information here in the future ...

and thanks for all of your contributions ...

sorry if it sounded like I was coming down too hard on you ... but I just wanted to give you enough information to see what I was talking about ...

see you around ...

Oh! CLX I/O Update is asynchronous!!!Thanks all,learnt several points which i have misunderstood abt CLX.