AB Code...Has anybody tried this?

On the rockwell website, I found this piece of sample code that is suppossed to give you the Day Of Week (Monday, Tuesday, etc) for a 5000 series controller. Has anyone used it before? I just hate to add something to my program that has problems. Or does anyone have any other ideas or code to figure out what the Day Of Week is?

The "sample code" page is here: http://samplecode.rockwellautomation.com/idc/groups/public/documents/webassets/sc_home_page.hcst

The name of the file that I'm looking at is MMS_044701. Search for it in the "filename/ID" box and it will come up.

I'm trying to make something happen every Sunday. Still not sure why AB didn't put a better clock / calender function in their higher end PLCs when the lower end models have it...?

I have used it in a test environment.
I have not deployed this to our production environment.

I have used the TDOW function, seems to work ok. It does seem like a lot of code to add in, but I guess this is something that is done by/incoporated in firmware in other models...

I might not be answering your question (and might be slightly OT) but you should evaluate whether or not you even need the .L5X (as an add-on instruction) to begin with (or any add-on for that matter). I know it is just example code, but it seems rather too simplistic to use as a add-on instruction.

Someone correct me if I am wrong (Ken?), but there is a bit of overhead associated with having this exist as an add-on, since you treat it like regular instruction and can create multiple instances.

If you are going to be trying to get the date and time (or whatever instruction you have) in several places throughout your code, it may make sense to use the add on instruction.

If you only need to use it in one spot, and are certain that is the only place you will ever need it, you may be better off just copy and pasting the ladder logic contained in the add-on where you want it.

Where I work, we tend to have plenty of memory and for our applications, scan time is rarely an issue except on the larger systems, so we are pretty liberal about the use of add-ons and UDTs.

That said, add-ons, when used correctly, do improve the portability of code, especially when you are trying standardize a certain controller programming architecture across a site.

We use AOI's for lots of code that we've created and deploy one instance within a program. Just to save time and no neex to ever trouble shoot again. Cutting and pasting we have found that code very easily can be changed and missed. We just feel its also less hassle.