Simplest way to change tag scope with Controllogix?

kamenges said:

True. However, now the CPU needs to perform a masking operation to get at the bit you want referenced. So boolean operations become a two-step process. With the BOOL data type and take the memory hit the comparison can be performed immediately.

There is very little in the world that comes for free.

Keith

Click to expand...

Keith,

I'm not sure I am following this line of reasoning, so please correct me if I'm misunderstanding your intent. I think you are saying something like this...

XIC MyBOOL

executes quicker than

XIC MyDINT.0

or

XIC MyUDT.BoolElement

Is that the basic idea?

Because I don't think it matters one bit to the processor how you entered those addresses, they all resolve to a specific bit address at compile time. I think they execute the same.

bosko said:

I'd like to add my 2 cents here. First off, there is no problem for RSView or any other software seeing program scoped tags. And using UDTs is not only a good way to organise tags, but also speeds up development, and communication since RSLinx has "Optimize UDTs" options built in. I saw an improvement of over %20 when switching to UDTs. The other major reason for using UDTs is that each tag in a control logix takes up at least 4 bytes. Yes that's right, a boolean tag chews up 4 bytes of memory for the tag name. If you use UDTs the UDT name is the only memory wasted. So if you have 10 bools, in a UDT you just saved close to 40 bytes, per instance of the UDT.

Click to expand...

Until the most recent versions of RSView32, the address field for tags was often too short to access program-scoped tags.
PanelViews (standard) can't see program-scoped tags.

BOOL's can be aliased to bits in a DINT. This is Rockwell's recommended practice. Creating UDT's just to optimise BOOL's would be an example of what I referred to as "going overboard".

Originally posted by mellis:

XIC MyBOOL

executes quicker than

XIC MyDINT.0

or

XIC MyUDT.BoolElement

Click to expand...

Yes, that is what I am saying. MyBool can be evaluated immediately for false (zero) or true (anything other than zero) by the CPU. Anything defined at the bit level must first be masked to make sure other bits in the word do not affect the result. At the very least this will result in the loading of the mask value, which is an extra step.

As others have pointed out this will not affect total scan time much. The logic solver evaluates a branch or rung as false as soon as the first false condition is detected and acts on the output conditions accordingly without scanning the rest of the input conditions. With intelligent rung structuring I suspect only a very small percentage of the total boolean operations are performed in any given scan. But that still doesn't change the fact that bit level access and logic are not as processor efficient as DWORD level access.

Keith

HLeap said:

The only issue I have with Program Scoped Tags vs. Controller Scoped Tags is that you can create duplicate tags. In the case of duplicate tags the Controller Tag will take presidence over the Program Tag. This may be a useful tool to some of the more experienced programmers and very confusing to the novices.

Click to expand...

HLeap,

If anyone intentionally creates a controller scoped tag and a program scoped tag with the same tag name, I think they deserve to be confused.

It's perfectly OK to create several program scoped tags all with the same name, I do it all the time. But that controller scoped tag needs a unique name. There is just way too much potential for trouble if it's not unique.

However, I just checked in v15 and it seems the program scoped tag has precedence over the controller scoped tag. Actually, I couldn't find a way to enter the controller scoped tag once a program scoped tag with the same name existed. It's not even listed in the combo box with the "controller" button selected and the "program" button unselected.

I still see potential problems if some logic was originally entered referencing a controller scoped tag, and then an identically named program scoped tag is added. Offline, the code switches to the new program scoped tag. Makes me wonder what happens Online. (I'll check it when I get a chance.)

I'm pretty sure this behavior has changed from earlier revisions.

well it looks like i am going to have to change a bunch of tags to program scope. i think i am going to wait though until i can get at least get the machine started up. i don't want to spend time now messing with tags because i may "break" some things in my program.

kamenges said:

Yes, that is what I am saying. MyBool can be evaluated immediately for false (zero) or true (anything other than zero) by the CPU. Anything defined at the bit level must first be masked to make sure other bits in the word do not affect the result. At the very least this will result in the loading of the mask value, which is an extra step.

Click to expand...

OK, I think I see where you are coming from. Since the BOOL takes a whole 32 bit word, you think the XIC instruction operates on the DINT value and doesn't bother to mask for bit 0. I guess that's possible, you'd have to know the details of the processor firmware to be sure. The manual only shows one execution time for an XIC instruction though. I am guessing here, but I think it's plausible that the XIC instruction operates the same way regardless of where the bit is located in the word. That is, it checks the individual bit even if it happens to be bit 0. It's a matter of if the complier treats bit 0 as a special case or not.

Any Rockwell guys want to clear this up? It's not critical, but I'm curious.

mellis said:

Keith,

I'm not sure I am following this line of reasoning, so please correct me if I'm misunderstanding your intent. I think you are saying something like this...

XIC MyBOOL

executes quicker than

XIC MyDINT.0

or

XIC MyUDT.BoolElement

Is that the basic idea?

Because I don't think it matters one bit to the processor how you entered those addresses, they all resolve to a specific bit address at compile time. I think they execute the same.

Click to expand...

If you write a program in C that would be exactly how it would happen.

Depending on the compiler, testing to see if MyBool is true would probably complile to an assembly instruction to load MyBool into the AX register and execute the TNZ instruction and check the CPU flags.

However, testing to see if MyDint.0 (assuming you have delcared MyDint to be a 32 bit bitfield) is true will require loading MyDint into the AX register, AND-ing it with 01H and then executing the TNZ instruction and checking the CPU flags. There is one extra step.

The big question for the CLX is whether XIC differentiates between a stand alone Bool or not. It could do the mask AND regardless.

bosko said:

(...) RSLinx has "Optimize UDTs" options built in. I saw an improvement of over %20 when switching to UDTs.

Click to expand...

Over 20% compared to what, though? Scattered BOOLs, DINTs, and REALs all over the place? You'd get the same improvement, maybe even moreso, just by creating some BOOL/DINT/REAL arrays and using aliases to individual members. You just configure the HMI to look at the array tags instead of the aliased ones. For example:

HMI_Commands - DINT[20]
HMI_Setpoint - REAL[100]
HMI_Actuals - REAL[100]

Temp101_Auto_Mode - alias to HMI_Commands[0].0
Temp101_SP - alias to HMI_Setpoint[0]
Temp101_PV - alias to HMI_Actuals[0]

Continue in this fashion and your HMI can pull up all the data you need in just a handful of packets by requesting the entire array at once. It's even more efficient than UDTs, but it does require you to keep track of what elements of your array are used - cross-referencing helps here.

I've done quite a bit of packet-sniffing to study comm performance with ControlLogix and various HMIs. What I've determined is that bare tags (especially BOOL) = bad, UDTs = better, arrays = best (infer - array of UDTs = top-notch??); continuous task = acceptable, no continuous task = best (cuts down immensely on task-switching overhead; small systems won't see much difference in comm throughput but larger ones will).

optimus2861 said:

Over 20% compared to what, though? Scattered BOOLs, DINTs, and REALs all over the place? You'd get the same improvement, maybe even moreso, just by creating some BOOL/DINT/REAL arrays and using aliases to individual members. You just configure the HMI to look at the array tags instead of the aliased ones. For example:

HMI_Commands - DINT[20]
HMI_Setpoint - REAL[100]
HMI_Actuals - REAL[100]

Temp101_Auto_Mode - alias to HMI_Commands[0].0
Temp101_SP - alias to HMI_Setpoint[0]
Temp101_PV - alias to HMI_Actuals[0]

Continue in this fashion and your HMI can pull up all the data you need in just a handful of packets by requesting the entire array at once. It's even more efficient than UDTs, but it does require you to keep track of what elements of your array are used - cross-referencing helps here.

I've done quite a bit of packet-sniffing to study comm performance with ControlLogix and various HMIs. What I've determined is that bare tags (especially BOOL) = bad, UDTs = better, arrays = best (infer - array of UDTs = top-notch??); continuous task = acceptable, no continuous task = best (cuts down immensely on task-switching overhead; small systems won't see much difference in comm throughput but larger ones will).

Click to expand...

How do you scatter bools in a tag based processor?? Arrays are great, but require more work. It's probably personal preference. But I like when I create a tag called BWPMP1 of the data type "pump", that it took 6 keystrokes to be able to now use BWPMP1.START in my logic. I think it will make even more sense with version 16 when Rockwell finally adds user defined addons.

By "scattered" I mean that there's no guarantee that the individual BOOLs you create are going to be in contiguous areas of the processor's memory - and even if they are, your HMI can't know that, and still has to ask for each of them by name, which is grossly inefficient.

That is, if you create a BOOL tag Pump1_Start, it might live in internal memory address 4001 or something (I have no idea how internal memory is addressed in a ControlLogix, just throwing an example out). Later on you create Pump1_Run and there's no guarantee it's going to live in 4002. Even if it did, your HMI won't know that. It has to ask for Pump1_Start, and Pump1_Run. So right away your HMI is sending out at least 20 bytes
on the wire to read just those two *bits*. Talk about overhead.

UDTs are better in this regard because the HMI can just read the whole structure at once instead of reading each individual element. But each UDT is a fixed size, and the HMI still has to ask for each UDT by name. For pure comm throughput, nothing's going to beat an array - pack all your readings, setpoints, what have you into arrays, point the HMI at the array, and bang! The HMI can grab the whole array in one shot.

For smaller applications, it's not going to make enough difference to worry about. The larger you get -- more processors, more HMIs, larger network -- the more thought you have to give to comm efficiency.