Reset Multiple Control Blocks

Is there a way to reset 1 CONTROL Tag with 120 Arrays. DecMoveHeight[0]-[119] with one instruction? If so how is it structured. This is with RSLogix 5000. 1769-L32E Thanks for the help.

Probably not, but hard to tell for sure without knowing the make and model of hardware and software you are using.

OkiePC said:

Probably not, but hard to tell for sure without knowing the make and model of hardware and software you are using.

Click to expand...

Sorry I updated everything in the first post

Copy a blank array of the same size to it.

nik124 said:

Is there a way to reset 1 CONTROL Tag with 120 Arrays. DecMoveHeight[0]-[119] with one instruction? If so how is it structured. This is with RSLogix 5000. 1769-L32E Thanks for the help.

Click to expand...

If by "reset" you mean write a value of "0" to each element of the tag array using one instruction, then you may use the File Arithmetic and Logic (FAL) instruction...

673562 - Using Numeric Mode with a FAL instruction
Access Level: Everyone

Using the FAL instruction you can write a value of "0" to each element of the tag array in a couple of different ways which I'll explain for the "Mode" selection below.

FAL Instruction Operands:

The "Control" operand is a user-defined tag of data type "CONTROL" - example: "nik124_FAL"

Let's not mix this up with your terminology for your tag array being a "CONTROL" tag. The above of course refers to the tag's data type being the predefined "CONTROL" data type and not an application usage term, such as you have used. The predefined CONTROL data type structure contains the .EN, .DN and .ER BOOL members, along with the .LEN and .POS DINT members. These are used to control the FAL instruction instance's operation.

The "Length" (.LEN) operand is the number of elements to operate upon = "120" for your tag array.

The "Position" (.POS) operand is the element to begin operating from = "0" to start at the beginning of the tag array.

The "Mode" operand is optional:

Incremental (one element per scan) Mode = "INC"
All at once (all elements in one scan) Mode = "ALL"
User-defined (x elements per scan) Mode = "x"

"INC" Mode would take 120 consecutive scans to complete the 120 element operations. This may be used where the tag array will not be referenced again for at least the period of time taken to scan the instruction 120 times or where the array is being sequentially referenced and reset to "0". This helps save on the per scan duration the instruction is operating upon the array, resulting in less impact upon the program scan. For INC Mode you must transition the rung-condition-in to re-enable the FAL instruction in order for the operation to increment.

"ALL" Mode would take one scan to complete the 120 element operations. It can be used where all operations must take place before proceeding with the program scan, but it may slow the program scan considerably. The size of the array, with respect to the current scan time, and the priorities and complexities of other aspects of a project, will normally decide whether ALL Mode may be used without having a detrimental effect. ALL mode just requires the rung-condition-in to transition true once and the FAL instruction will continue operating until done, irrespective of the rung-condition-in going false during its execution.

User-defined "Mode" breaks up the number of operations into blocks, such as 5 or 10 elements per scan. This also helps relieve the burden on the program scan, if required. Set this to a numerical value of your choosing if you prefer this Mode. User-defined also continues operating for each scan until done and ignores a rung-condition-in going false.

You can decide which Mode you would prefer to use here but please note - the reasons to use each Mode are not solely based on the impact upon the program scan. I'm more focusing on it here because you simply want reset an entire tag array using one instruction and I'm sure as quickly as is possible with having any detrimental effect on the rest of your program execution. Each Mode may of course be used for various application driven reasons aside from operating upon an entire array. But it is always important to be aware of the program scan impact and give it due consideration where necessary.

Moving on...

The "Dest" Destination operand will contain the tag array name and element to operate on using an indirect referencing syntax. The indirection is achieved by means of the Control tag's Position element (.POS) which will automatically change (0 - 120) according to the Mode selected. For our example Control tag, and using your actual tag array name, you would enter:

DecMoveHeight[nik124_FAL.POS]

The "Expression" operand will contain the value you wish to store in the "Dest" tag address. This could be an actual arithmetic expression, or a tag address that contains the required value, or simply an immediate value, such as "0" in this case.

Using the above settings you should be able to achieve your goal using a single FAL instruction. There are many ways to use this powerful instruction and others might suggest other methods to get you there using it, or indeed entirely different methods.

So fire away with the above or hang tight if you'd prefer wait for other cat-skinning options.

P.s. if considering AutoMax's perfectly plausible suggestion then please note that you would require two instructions, but it's no big deal. You must first copy the value "0" to the first element member of the array and then copy from that element to the rest of the array, setting a Length of "array-1" or "119" in your case. You cannot copy a value directly into a tag array for the length of the array. You must first "prime" it.

Regards,
George

George,
I have tried using DecMoveHeight[DecReset.POS] in the destination and it won’t allow it. This seems to be where I get stuck. I thought this type of indirect addressing would work because I can get it to work on a DINT data type but not a CONTROL data type. I’m confused. Thanks for your replies though!

Update: I was able to do this and it worked!
FAL Insturction
Control: DecReset
Length: 120
Position: 0
Mode: All
Dest: DecMoveHeight[DecReset.POS].POS
Expression: 0

I was forgetting the .POS at the end to identify what part of the array I want the 0 to go to. Thanks for all your help! I was there just needed a litttle boost!

+1 to Daba, op explanation is confused.

nik124 said:

Is there a way to reset 1 CONTROL Tag with 120 Arrays. DecMoveHeight[0]-[119] with one instruction?...

Click to expand...

Amidst the confusion here, I think I see what you are about now?

The reason I tried to make a clear distinction between what you were calling a "CONTROL Tag", and what the predefined CONTROL data type used in the FAL instruction consists of, is so you would be prompted to also clearly define what you had meant when referring to something "CONTROL" related. You sort of didn't directly do that, but did indirectly mention it in your last comments. You also did not mention needing to reset the .POS address within anything in the opening post, which would also have helped clear things up a bit.

Perhaps you didn't read into what I explained too much because you just knew I was explaining exactly what you are attempting to work with here - the predefined CONTROL data type itself, and specifically you are attempting to reset each of the .POS addresses within an array of CONTROL data type elements?

As you have configured your FAL now, using ALL Mode, it will sequentially operate upon the 120 "CONTROL data type" elements within your array, storing the Expression value of "0" in each CONTROL data type element's .POS address.

If that was your goal then no, the original explanation was not quite so clear. But again, that is why I had made that specific distinction, just in case you were actually using the CONTROL data type.

A better way to describe your tag array above, if I'm correct, would be...

1 array consisting of 120 CONTROL data type elements or members - Tag: DecMoveHeight data type: CONTROL[120]

[-]DecMoveHeight data type: CONTROL[120]
_[-]DecMoveHeight[0] data type: CONTROL
___DecMoveHeight[0].EN
___DecMoveHeight[0].DN
___DecMoveHeight[0].ER
___DecMoveHeight[0].LEN
___DecMoveHeight[0].POS
_[-]DecMoveHeight[1] data type: CONTROL
___DecMoveHeight[1].EN
___DecMoveHeight[1].DN
___DecMoveHeight[1].ER
___DecMoveHeight[1].LEN
___DecMoveHeight[1].POS
_[-]DecMoveHeight[2] data type: CONTROL
___DecMoveHeight[2].EN
___DecMoveHeight[2].DN
___DecMoveHeight[2].ER
___DecMoveHeight[2].LEN
___DecMoveHeight[2].POS
...
_[-]DecMoveHeight[119] data type: CONTROL
___DecMoveHeight[119].EN
___DecMoveHeight[119].DN
___DecMoveHeight[119].ER
___DecMoveHeight[119].LEN
___DecMoveHeight[119].POS
...

NOTE: There may be other element members with the CONTROL data type but I'm just displaying the main ones.

nik124 said:

...I was forgetting the .POS at the end to identify what part of the array I want the 0 to go to.

Click to expand...

By adding DecMoveHeight[DecReset.POS].POS you are now correctly pointing at the .POS address for each CONTROL data type element within the array.

All that confusion aside, I'm glad it works for you.

Regards,
George

Just moving 0 into the .POS of a CONTROL data-type does not perform a full RESET function, since the CONTROL's status bits will be unaffected.


Since the CONTROL structure is a "universal" structure, and we don't know what you are using them for, we would not be able to advise.....

I had considered that aspect of the CONTROL data type while writing my last post but had felt that the OP seemed to be happy enough that they have reached the goal "they" set out to achieve, more so than some other goal "we" might assume they also need to achieve.

I was also thinking that "if" they subsequently find that achieving the above goal did not prove to achieve some higher goal, then they would be back here quick enough asking further questions.

Still, it does no harm to preempt these things, just in case.

G.

Geospark said:

I had considered that aspect of the CONTROL data type while writing my last post but had felt that the OP seemed to be happy enough that they have reached the goal "they" set out to achieve, more so than some other goal "we" might assume they also need to achieve.

I was also thinking that "if" they subsequently find that achieving the above goal did not prove to achieve some higher goal, then they would be back here quick enough asking further questions.

Still, it does no harm to preempt these things, just in case.

G.

Click to expand...

Just putting the i's and t's ready for dotting and crossing....