RSLogix / Logix Designer - Writing same value in an array

[dalporto]

I just restarted the whole AOI with the FAL from scratch and it's working now.


There was a hiccup at some place I guess.






I'm just not sure how you handled the First Scan with Unlatch on the FAL Control.


Wouldn't it the the opposite? On First Scan you'd want to pass the value from the input? Or the NEQ would take care disabling the FAL anyway? I'm just trying to understand what I'm missing.



Anyway, thank you very much for you help, it's appreciated!

 

[robertmee]

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.

View attachment 66764​

The FAL isn't executing because the first NEQ is never true since he's starting with an array of presets at 0. I suspect he's not cycling the plc mode to get the first FS. I would get rid of both the FS and NEQ and just run the FAL when needed.

 

[JeremyM]

FAL and several other instructions use that Control structure.

Understanding how FAL uses it and what the first scan unlatch did to it in your image will help you.

 

[robertmee]

I just restarted the whole AOI with the FAL from scratch and it's working now.


There was a hiccup at some place I guess.






I'm just not sure how you handled the First Scan with Unlatch on the FAL Control.


Wouldn't it the the opposite? On First Scan you'd want to pass the value from the input? Or the NEQ would take care disabling the FLL anyway? I'm just trying to understand what I'm missing.



Anyway, thank you very much for you help, it's appreciated!

As noted above, because the first scan wasn't executing.

 

[JeremyM]

As noted above, because the first scan wasn't executing.

This brings up a subtle issue a lot of people miss easily: what if the AOI using the S:FS condition isn’t executed on the first scan? Especially true of nested AOIs. The reliable solution is adding that logic to a prescan routine.

 

[dalporto]

Ok, let say I do that:


MIN_TIME is an input on the AOI which is set to 5 seconds but that can be changed online.


If I change it manually, the NEQ should detect it.


My question here is what if I just remove the NEQ instruction?


The FAL instruction should just change if the MIN_TIME change and that's it?


What would be the harm in removing it?


I was using the FS at first because I was trying to push the .PRE with a FLL instruction which was also writing the same value everywhere (like in the .ACC).

 

[5618]

For additional robustness, I suggest adding some logic to make sure a negative value doesn’t reach the .PRE. That’s a quick way to fault a processor.

Even if HMI entry doesn’t allow a negative, I normally do something like LES MIN_TIME 0 MOV 0 MIN_TIME on a branch above before sending MIN_TIME to .PRE just in case someone fat-fingers the value while working online.

 

[robertmee]

The NEQ just prevents the FAL from executing every Scan when the value to copy hasn't changed. It won't hurt anything to remove it, other than slightly increase overall Scan time.

 

[drbitboy]

The NEQ just prevents the FAL from executing every Scan when the value to copy hasn't changed. It won't hurt anything to remove it, other than slightly increase overall Scan time.

Not exactly

The NEQ is there to trigger a rising edge of the FAL's input rung, because the FAL will only run on the single scan when that rising edge is detected, so even if the rung stays True on subsequent scans, the FAL will not write anything to the destination until the input rung transitions first to False and then back to True.

As it turns out, the output of the NEQ will be a one shot, and another one shot cannot occur until MIN_TIME_1000 changes to a new, different value.

 

[dalporto]

For additional robustness, I suggest adding some logic to make sure a negative value doesn’t reach the .PRE. That’s a quick way to fault a processor.

I didn't believe it, but I just did it, I faulted the PLC. It's a little sensitive.



There is no path to the HMI for that timer, it can only be changed from within the PLC and it's usually a fixed 5 seconds value to make sure a Modbus HMI screen will get it and it's only for annunciation, no impact on any control, but it's good to know.




Thank you, it's fixed now.

 

[dalporto]

Not exactly

The NEQ is there to trigger a rising edge of the FAL's input rung, because the FAL will only run on the single scan when that rising edge is detected, so even if the rung stays True on subsequent scans, the FAL will not write anything to the destination until the input rung transitions first to False and then back to True.

As it turns out, the output of the NEQ will be a one shot, and another one shot cannot occur until MIN_TIME_1000 changes to a new, different value.

Yeah, that is right, I just tried it.


FAL will not execute if MIN_TIME value change.

 

[drbitboy]

Put in -32.768 for MIN_TIME and get another fault

The right thing to do is to put a LIM instruction on MIN_TIME to ensure it is on the range [0.0:32.767] in front of the MUL instruction, and put it back on one rung

 

[I_Automation]

Just throwing this in to annoy any Rockwell programmer and cause a fuss:

Why can't a timer (or counter) have an indirect address of a DINT instead of a specific value?



This is in RSLogix500 as I don't have the right laptop with me for Studio5K, but you get the idea

 

[JeremyM]

Just throwing this in to annoy any Rockwell programmer and cause a fuss:

Why can't a timer (or counter) have an indirect address of a DINT instead of a specific value?



This is in RSLogix500 as I don't have the right laptop with me for Studio5K, but you get the idea

Because the TIMER/COUNTER are structs containing the variables the instruction operates on.

 

[dalporto]

Put in -32.768 for MIN_TIME and get another fault

The right thing to do is to put a LIM instruction on MIN_TIME to ensure it is on the range [0.0:32.767] in front of the MUL instruction, and put it back on one rung

It was higher than that but it did, indeed.


But there is something I'm doing wrong because if I put in a value that does not make any sense with that, it just keeps the last one that made sense instead of using the high 60 seconds limit.


I don't think this LIM will pass the value, it will only be OFF if outside the range.


Unless you just don't want it to pass a value outside the range, then this is correct.


Edit #3: Yeah, I guess that was your point, I'm seeing it now. I'm struggling getting my mind off that I'm not in FBD anymore.