RSLogix

I am new to RSLogix. When I dbl click on the bit data table only one word shows up. How do I view the other bit words? I am using a SLC 500 5/01 processor.

TIA

Hi there,

It must be that there is only 1 word of bits in the data table,if you go to radix and select binary you should see the bit format.

It is in binary. All that is listed is B3:0. This is a new project if that makes any difference

TIA

By default there is only one word in the file at when you start a new program. You can either opposite click on the file and open the properties and set the element count higher ie 10 will give you wors B3:0 to B3:9 or you can use a bit in the program that is not defined, ie B3:11.3 When you verify then RSLogix will add the 11 words to the data table. Regards Alan Case

It doesn't make any difference, new or old.

If the data table says "Binary", then you are looking at the bits.

You project has so far only used bits in word B3:0. If you use bits past B3/15, and verify, the data table will be expanded.

If you want, you can manual expand the data table size. Right click on the data table in the Project Window, and select Properties. Then change the number of elements or the last address, and the table will be as you want it.

Thanks so much verify was the trick.

This is gonna be fun....

I am converting from automation direct programming to AB...

John

Just to let you know the format is the same for all the data tables,i.e as you use and verify them the data table will be created.A good way of doing this and to track things easier is to tie binary to 3 integer to 7,etc.
(B3,B13,B23,B33,B43----N7,N17,N27,N37 ,etc)

Garry, I use something similar but all my binaries are usually B30, B31 etc, integers N70, N71, N72 etc. I usually leave the default files blank as sometimes if I need to add 3rd party code to a routine (which a lot of times uses these files) then they are free to use.
Regards Alan Case

Hi,

For some reason Alan Case could not post so:

Alan Case wrote on July 4th, 2002 04:05 PM:
Hi, For some reason I can't post. Could you post his answer for me please. regards Alan Case

It depends what data table you are clicking on. If it is say an input table and there is only one input module then you will see only one word. If it is an internal file (ie N7) the default is one word unless you tell it via the properties function to be more than 1 word.
You can also assign a word in a not defined ie n7:5 and the data table on verification will expand to 6 words. Tell us if this works.
Regards Alan Case

Click to expand...

Thanks Garry. It started working again. Alan

How I address my AB programs

I just wanted to add something to the addressing schemes mentioned above.

I like to use addresses according to the subroutines that they originate in.

For example: For subroutine 4, I would use data files 40-49, (i.e. B43, T47 etc.)
Subroutine 5, 50-59. and so on.

Advantages: 1) Makes it really easy to add a subroutine since you don't have to go hunting for available addresses. If you have to add subroutine 20, you know that 200-209 data files are available.
2) Makes it easier to troubleshoot code. Once you get used to certain functions being done in certain subroutines, you can recognize the addresses quicker. For ex. if file 13 is your alarm routine, all B131 bits for example could be alarm bits.

3) Easier to remove a subroutine. If a subroutine needs to be removed, it facilitates searching on that range of data files to make sure that the coils weren't used anywhere in other parts of the program.

4) Library Loads with indexing are easier.

Thanks for the info. It makes good sense to me.

I am converting from AutomationDirect.

Is a RSLogix subroutine used like stages are in AutomationDirect software?

TIA

I am not familiar with Automation direct PLCs or stages.

I have seen subroutines in the AB used in different ways.

I personally normally just use them to help organize my code into functions. I could theoretically dump all the code into program file 2 (subroutine 2) but that would make it difficult to find anything later, depending on the size and complexity of the program.

I usually put all of the JSR (jump to subroutine) instructions in program file 2, (don't forget the rung comments describing the function of each subroutine) and allow them to be solved every scan undconditionally. This is the simplest way to use subroutines.

When the program gets to a JSR, the program jumps to the subroutine (program file) number and upon completion, returns to the place it was called from.

WARNING: If you "condition" the JSR rung with a contact etc., you must be aware of the following: Yes, it will speed up your program scan by not solving the subroutine every scan. But, because the subroutine won't be solved every scan, when the subroutine isn't being scanned ,coils within the subroutine will not be solved FALSE nor will they be solved TRUE. Also, oneshots or other False-True type instructions may not work as expected due to the fact that they need to be solved false prior to being solved true in order to pulse.

Conditional JSR features.

ganutenator said:

WARNING: If you "condition" the JSR rung with a contact etc., you must be aware of the following: Yes, it will speed up your program scan by not solving the subroutine every scan. But, because the subroutine won't be solved every scan, when the subroutine isn't being scanned ,coils within the subroutine will not be solved FALSE nor will they be solved TRUE. Also, oneshots or other False-True type instructions may not work as expected due to the fact that they need to be solved false prior to being solved true in order to pulse.

Click to expand...

I see these as being desirable features. If one uses a 'state' or 'state' bit to conditionally call a 'state' or 'stage' subroutine then one does not have to worry about coils being set/reset in non active states. Now, if there is a problem then one can just go to the offending state and know that the offending code is in that state. The conditional jsr combined with the other excellent suggestions above makes debugging 'state' or 'stage' programming much easier and program execution much more efficient.

There is much less need to use one shots when using state/stage programming. When one shots are used it is normally to provide a first scan feature for the state/stage subroutine. Since the state/stage bits are global and get scanned all the time, the one shot on first scan after state/stage activation works well.
Obviously the traditional push button one shot code must be done outside the state/stage routines.

Yes, I agree, (to some extent) and have used subroutines for just such a thing. BUT!, I thought that it was important to point out the warning, especially considering the audience of the directed post.

originally posted by Peter
There is much less need to use one shots when using state/stage programming. When one shots are used it is normally to provide a first scan feature for the state/stage subroutine. Since the state/stage bits are global and get scanned all the time, the one shot on first scan after state/stage activation works well.
Obviously the traditional push button one shot code must be done outside the state/stage routines.

I don't remember the original poster saying that his logic was state/stage logic.

There are more false-true instruction gotchas than just the ons/osr instruction.

Nor did I point out the fact that you can reset the enable bit of some false-true instructions (i.e. FIFO) to circumvent this FEATURE.

I have seen many an experienced engineer/programmer get themselves into trouble with this feature, as I do not believe that conditional subroutines in AB are extremely straight forward.

Just trying to help others from making the same mistakes that I made when learning AB.