RSLogix / Logix Designer - Writing same value in an array

[dalporto]

Hi.


Not the fist time I'm saying this but just to give a background.



95% of my PLC programming has used Schneider over the last 10 years on the same kind of process, so I'm struggling with Logix Designer right now trying to implement the same kind of logix so the customers and other technicians / engineers aren't too lost in the code.



On an Add-On block in LD, I have 16 different inputs and 16 related outputs. There is a TOF for each of them on their respective rungs that I put in an array to save time, but they're all using the same value coming from an input on the block, first one would be TOF[0].


I just want to move my input value to all 16 of the TOF.PRE and I just cannot find a way to do it. I could have 16 lines to write the value in the 16 TOF.PRE but I'm still hoping that Rockwell planned for that at some point.



With Schneider I would just have used the same tag on all rows with a different input, but RSLogix made sure that we needed to use a "different" timer each time.



Thanks.

 

[JeremyM]

You can make an array of TIMER and loop over it.

 

[dalporto]

I'm gonna need you to be a little more precise.


I'm really rusty with my Rockwell.


I'm also ****y so right now I'm trying to write all my TOF[XX].PRE using a FAL instruction even if I don't have a clue how it's working.


Not going well.

 

[dalporto]

I think I got it with a FLL instruction.






PS: Yes, TOF[1] has 15 seconds too.

 

[dalporto]

Really, is that the way to use that? That kind of make sense, but still I'm unsure. I saw that to reset an array all to "0", but never to fix a *.PRE or else.



For those who could be wondering what is the purpose of that thing, this represents "processed" wired inputs, I have another remap before with my simulator.


We have a couple of those inputs that comes straight from protection relays, and some of them will clear as soon as they are in (like 10-20 ms), which can lead to clear before they're scanned by HMI. Won't help between 2 PLC scans but it's better than nothing. Only used with the inputs with the mask "true", which are commonly mostly all alarms.


One of the screen is Modbus, so this is my way to make sure that the screen will pick the alarm before it clears. I'll also have an Ethernet IP InTouch scanning directly the L8X too, I don't have a clue how it will work yet. I worked mostly with Modbus and DNP3. Does Rockwell Ethernet IP behave like Modbus?


I'm using 5 seconds, 15 was only to test the Add-On because I'm slow with a mouse.

 

[drbitboy]

I am pretty sure the FLL will not work that way, because the data words (32-bit DINTs) are laid out in memory something like this:

TOF[0].CTL (bits i.e. .EN, .TT, .DN)

TOF[0].PRE

TOF[0].ACC

TOF[1].CTL

TOF[1].PRE

TOF[1].ACC

TOF[2].CTL

TOF[2].PRE

TOF[2].ACC

TOF[3].CTL

TOF[3].PRE

TOF[3].ACC

TOF[4].CTL

TOF[4].PRE

TOF[4].ACC

TOF[5].CTL

TOF[5].PRE

TOF[5].ACC

TOF[6].CTL

TOF[6].PRE

TOF[6].ACC

...

TOF[15].CTL

TOF[15].PRE

TOF[15].ACC

​

I.e. 48 contiguous DINTs in memory.

The FLL writes to memory blocks, so I am pretty sure that the FLL instruction is writing a value of 15000 to the 16 contiguous words highlighted in blue above, and not to the individual .PRE attributes in each timer structure, which are every third word.

The FAL is most likely what you want (or an AOI with a loop written in ST), but FAL instructions need to be triggered by rising edges of their input rung, so something like this might work:

​

 

[dalporto]

I think you're right, that would explain why the TOF wouldn't even want to start once I populated the 16 inputs, it's probably self-resetting from that value I'm writing everywhere.


I kind of "fixed" it using a rising trig on first scan on that rung, but I'm indeed looking for something more solid.


I'll look for that FLL on Monday.


Thanks!

 

[drbitboy]

I think you're right, that would explain why the TOF wouldn't even want to start once I populated the 16 inputs, it's probably self-resetting from that value I'm writing everywhere.


I kind of "fixed" it using a rising trig on first scan on that rung, but I'm indeed looking for something more solid.


I'll look for that FLL on Monday.


Thanks!

Yes, this:

​

 

[JeremyM]

I'm gonna need you to be a little more precise.


I'm really rusty with my Rockwell.


I'm also ****y so right now I'm trying to write all my TOF[XX].PRE using a FAL instruction even if I don't have a clue how it's working.


Not going well.

If you can pull it off in structured text, it’s just a for- or while-loop:

SIZE(TimerArray, 0, ArraySize);

i := 0;

while (i < ArraySize) do
   TimerArray[i].PRE := someValue;
   i := i + 1;
end_while;

The same concept can be done in ladder using a combination of MOV, ADD, JMP/LBL, and comparison instructions.

 

[Corsair]

I'm gonna need you to be a little more precise.


I'm really rusty with my Rockwell.


I'm also ****y so right now I'm trying to write all my TOF[XX].PRE using a FAL instruction even if I don't have a clue how it's working.


Not going well.

It's interesting to investigate how the brand-specific instructions like FAL work - but my unpopular answer is to not use them. Generally anything that loops should be done in ST. That way other occasional-AB types like me that see your code will have a clue as to how it's working. Use code that doesn't require a forum thread for an explanation.

The potential side effects of the FAL approach require investigating what it does with all the structure elements - .PRE, .ACC, and the bits. I'd rather write the ST and go on with life.

 

[dalporto]

Use code that doesn't require a forum thread for an explanation.

Yeah, I get you, but there are other considerations.


First I need to wrap my head around how AB PLCs specifics are working and get a grip on those instructions I am not familiar with yet.


Next I need to think who will work with that code when I leave. These are Protection & control technologists which cannot "read" a ST section, which is why i try to avoid it.


Fact is we almost exclusively go with FBD with all customers, and they like that very much. That way they can debug themselves 95% of the time and I don't have to take a plane and leave other projects on hold. We want it to be easy for customers to understand and not to make sure that they need to call us for every little problem, we don't have time for that. Same for our own technicians who can browse within it by themselves. On the other hand, we have another product which is programmed in MatLab and transferred in a PLC, that one you need us.



Problem here is Rockwell PLC. First the scan time is atrocious compared to other brands, and a FBD section affects it very much. So I'm at least trying to program the Add-Ons in ladder to spare a little scan time, the purpose of it being to not be forced to upgrade from a L82 to let say a L83. Rockwell PLC are about 3 times the price over a Schneider PLC. Furthermore, there is no real RIO drops on Rockwell PLC, these are in fact asynchronous DIO drops which can be a pain with what we're doing because we're relying a lot on the scan time and order of execution. We sometimes need to pull cables to relocate IOs with Rockwell setups.



Last time we were forced to used a Rockwell PLC they were two-redundant (Rockwell redundancy is the worst) L72 with 2 DIO backplanes, and the comm was DNP3 over ProSoft modules (another stupid customer request). The horror. 200 ms PLC scan time for a program that runs under 15 ms in a M580 2040. And I'm not even talking about all the comm issues we add with that.


And this is why I try to not use ST, because programmers are not the ones using it.

 

[dalporto]

This is how I do it in my Derived FB with Schneider.


It cannot be clearer.


I'd really like that TP in Rockwell.

 

[dalporto]

Yes, this:

View attachment 66762​

I was still talking about the FLL, but yes, I get it.


I just tried your FAL, it's kind of looking like it's doing the same thing as the FLL behaviour. Value don't reach even the first .PRE causing NEQ to stay On. Also the length even if programmed with 16 shows at "0" on runtime, but I can manually change it back to 16 while running and then some of the preset are changing.


So right now I just added 16 rungs to move the preset until I can come up with a better / leaner way.



It's just weird that I have 65 now rungs for such a simple task.

 

[drbitboy]

I just tried your FAL, it's kind of looking like it's doing the same thing as the FLL behaviour. Value don't reach even the first .PRE causing NEQ to stay On. Also the length even if programmed with 16 shows at "0" on runtime, but I can manually change it back to 16 while running and then some of the preset are changing.

Huh.

Example 2 here is almost exactly the same case.

Maybe the FAL destination has to be an atomic (INT, REAL, etc.) array expression, not particular structure attributes (.PRE) of an array of structures.

And I have no idea what is going on with the control structure's .LEN attribute.

Some people may object, but the following code is simpler than 16 rungs (RSLogix MSL/500), but possibly harder for techs to understand.

​

 

[dalporto]

I have a 2500 value that's coming out from nowhere when I run it (the first one).


But yes, it's writing to all the .PRE.


Still that .LEN going back to 0 in runtime.



I tried using INT, DINT and REAL but it's all the same.


In the example 2 from the manual, there is a 0 in there: TOF[0,FAL_CTRL.POS].PRE


I tried that it won't compile.


Also not a single example with an extension afterward.


Maybe it cannot be done this way.


I'm gonna have a look at your last screenshot now.