RSLogix 5000 Arrays and FBD

Hey all, some quick questions on rslogix 5000. Ive been tinkering around with logix 5000 for a small system, and ive noticed a few things..

1) Is it really not possible to define your own FBD? These seem like a better way of running checks on many devices that are essentially the same than ladder.

2) it seems like that to do a "function call" You need to do something like...

Create a "function" ladder, create a data structure for the function. Create the data structures for the devices (it matches the data strucutre of the function). Copy the device data to the function data, JSR to the function ladder, then copy the function data back to the device data. Repeat.

This doesnt seem very elegant, are there better ways?

Oh, and, if you have a single element boolean array, is there an easier way to reset the entire array to false without going through each element indivigually?

I can help you out with the array. You should be able to use the CLR command on the tag or at the very least use the FLL (fill file) with a zero for all the elements.

CLR FLL dont seem to work using a boolean array, just Int, DInt, etc. Guess that would have been too simple...

Maybe im not calling the array as a whole right? ex...

Alarm[18] - a boolean array of 18 elements called alarm

To latch a single element in the array

OTL Alarm[2] This would latch element 2 of the array

now to call the CLR or FLL you would do

CLR Alarm - Yes? Or do you need to do something like alarm[*]???

JSR with parameters

For the other half of your question, you are right - there currently is no User-Defined Function Block (like there is in, say, Concept).

Your technique can be made a bit more elegant, however.

Yes, create a ladder (or function block) routine (within the same program - sorry), which uses Program-scoped tags which are only used in that routine.

The first instruction of that routine should be a SBR, which will reference all the inputs to that subroutine (in a specific order). The last instruction will be a RET (to pass outputs).

When you do the JSR, you'll specify which tags are passed as inputs (in the same order as the SBR) and returned to from the subroutine's RET parameters.

It's pretty much as you describe, without the extra effort of copying the data back and forth. It treats the JSRs like VB functions instead of just as a way of organizing code.

The biggest limitation is that you can't create a global function (in, say, "Unscheduled Programs"), and call it from anywhere (using something like, oh, a "JXR - Jump to External Subroutine" instruction). The function must reside within the same Program.

That's why you shouldn't use Boolean Arrays

Matthias:

You are running headlong into the limitations of using tags instead of registers.

There are not many (any?) instructions that will manipulate a bit array, as an ARRAY.

If instead of creating a Boolean Array, you shouold have used a DINT array. You can manipulate things on a DINT and ARRAY level (which would get you the FLL instruction, among others), but the downside is that you can't reference a bit across the DINT boundary (e.g., you can't OTL ALARM[0].40. It has to be ALARM[1].8).

That's not so bad for direct addressing (since you are going to know the address anyway), but hurts for indirect.

You can't just use Alarm[0].[Index], which is easy to understand.

Instead, you have to use Alarm[(Index AND NOT 31) / 32] . [Index AND 31]
(Assuming Index is a DINT - Courtesy of the RSLogix Help file)

It can be done. It's just not easy.

---

If you only need 18 alarms, then simply use a DINT ("ALARM") (yeilding 32 alarm bits). The reference to each alarm will be ALARM.0, ALARM.1, etc. And then you CAN just do a CLR ALARM to reset all the bits. Everything above is for more complex systems with more than a 32-bit array.

It's also more efficient in memory. A boolean array Alarm[18] uses 19 DINTs of memory (even though only 19 bits are accessible). A DInt of Alarm only takes 1 dint of memory, and allows access to 32 bits.

Thanks Allen. I guess I was right then, and I should avoid bit arrays. Ive already noticed that there are limitations of unscheduled tasks. I was hoping the Logix 5000 would finally give me a more robust C like way to code PLCs, with real function calls and such. Its definetly a start.

Yea, this system only has 18 alarms, its just a small stand alone generator that were using as a test for our first control logix system. We didnt want to dive into the larger systems with out a test drive.

Have you used the ALARM FBD thats included? Does it work well?

Supposedly, version 15 will allow you to actually write your own function blocks. What you're doing right now is very similar to the way we've handled the problem.

AK

Re: JSR with parameters

Allen Nelson said:

The biggest limitation is that you can't create a global function (in, say, "Unscheduled Programs"), and call it from anywhere (using something like, oh, a "JXR - Jump to External Subroutine" instruction). The function must reside within the same Program.

Click to expand...

Allen, you really should move on to version 13. It introduced "Event" tasks. These can be triggered by events such as axis registration, or programmatically by an 'EVENT' instruction in any other task - making it useable as a 'global' subroutine.

OTL and One Shots

How are oneshots, otl, and otu instuctions handled by the the subroutines? For example, if I copy the data to the subroutine, and use one shots on some logic, move the data back out, and then move new data in, will this confuse the one shot?

ie...

xic bit_1 ons OnsBit_1 ote bit_2

If I send bit_1 = 0 in the first run of the routine, the ote doesnt work.
Then, if on the second pass, I pass it bit_1 = 1 (and lets say, this bit has been at 1 for several scans now, and thus shouldnt trip the ons) will it see bit_1 as going from a false (first pass) to true (second pass) and activate the ote?

One-shots will work like you are used to. Just remember that the way you're used to is that the input conditions need to be reset and the logic scanned before a one-shot is reset.

If this is a problem, you can always create a binary array for the oneshot address, and have esentially a separate oneshot bit for each device. The advantage of this is that if the subroutine is run for the same device, that device's one-shot will be in it's last state, and will or won't fire depending on the data for THIS scan and not be affected by times that other devices used the subroutine.

       +------- SBR ---+            dummy

-------| Input:  Index |-------------( )

       +---------------+

 

   BIT_1    ONS_BIT.[INDEX]    BIT_2

----| |----------[ONS]----------( )

So, it will be affected by the previous devices use of the subroutine, and moving the ONS data in and out of the routine is necessary too.

Does this apply to an OTL and OTU as well?