First Scan Bit

Hey everyone,
I ran into something interesting out on a job that I have never seen before. I was hooked up to an A-B 1756-L72 PLC on a robotic laser welding cell and I noticed my S:FS (first scan) bit was staying on. I even cycled power to the PLC to see if it would go back off but it still stayed on, causing all kinds of problems in the logic. Has anyone ever had that bit stay on? Or know why it would stay on?
Thank You.

How do you know it always stays true?
Do you have any SFC logic within the application file?
Refer to Page 51 of http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm015_-en-p.pdf
for a possible scenario.

Search for a coil writing to it.

I have an XIO addressed to S:FS as the first instruction on a particular rung and the rung will not go true due to the bit staying on. I know the instruction is used in other places in the program, but I can't do a cross reference on the S:FS bit to find where. I don't think there's a coil turning it on anywhere, and I talked to the guy that wrote the program and he hasn't seen that before either. The cell has never had this happen before.

The "True" or "False" state you see is actually coming from your computer. Your computer sees a "0" or a "1" in the tag and then determines whether the instruction should be displayed as True or False. This is why you can also see the state change when you toggle a bit when offline or in Program mode.

The S:FS is actually not a tag but is instead a status flag within the controller. That means your computer cannot access the "1" or "0" data to determine whether it should be displayed as True or False.

As a result, (all of the) status flags do not appear to change state. XIC instructions will always appear False and XIO instructions will always appear True. This has no effect on their execution, only their appearance.

This was not the case in the older PLC-5 or SLC 500 where this information was stored as an addressable location.

OG

Operaghost said:

The "True" or "False" state you see is actually coming from your computer. Your computer sees a "0" or a "1" in the tag and then determines whether the instruction should be displayed as True or False. This is why you can also see the state change when you toggle a bit when offline or in Program mode.

The S:FS is actually not a tag but is instead a status flag within the controller. That means your computer cannot access the "1" or "0" data to determine whether it should be displayed as True or False.

As a result, (all of the) status flags do not appear to change state. XIC instructions will always appear False and XIO instructions will always appear True. This has no effect on their execution, only their appearance.

This was not the case in the older PLC-5 or SLC 500 where this information was stored as an addressable location.

OG

Click to expand...

So what you're saying is that even though it appears to be on, it's really just displaying the value incorrectly? If that's the case, I still don't think that's the issue. I still have the bit on because I'm not getting the rung to go true only because of that bit. I wouldn't have even noticed that the bit was on if it wasn't messing up my logic.

I think you are chasing the wrong problem. an XIO on S:FS would be true all of the time except for the first scan of the program. So, it is likely only false for a couple milliseconds at most.

Is this logic in a main routine or a subroutine? Is it located in a periodic task or a continuous task?

My guess is that the logic is not being called but that is only a guess without seeing the code.

Is it possible for you to post the code here for us to inspect? If not, you can certainly send me a private message here and I can take a look at it.

OG

Operaghost said:

I think you are chasing the wrong problem. an XIO on S:FS would be true all of the time except for the first scan of the program. So, it is likely only false for a couple milliseconds at most.

Is this logic in a main routine or a subroutine? Is it located in a periodic task or a continuous task?

My guess is that the logic is not being called but that is only a guess without seeing the code.

Is it possible for you to post the code here for us to inspect? If not, you can certainly send me a private message here and I can take a look at it.

OG

Click to expand...

Right, I want it to be on all the time except on the first scan. But since it stays on, it's blocked on the first scan and remains blocked even when it shouldn't be. It's in a called subroutine, that's the customer's "standard" logic. They like a main program routine that calls all the rest of the programs at whatever instance. I will try to get some screen shots posted of what I'm looking at, standby. Keep in mind, I am not at the cell anymore to be online with it, I have already returned to my company's shop. I do plan on returning there to fix this along with a number of other issues whenever we get them worked out (the customer is really picky about their code, they like to get us out there to fix one thing and end up keeping us for 2 or 3 days extra. Very irritating, but that's the way it is). Anyway, I'll try and get those pictures on here.

I'm having trouble getting a picture on here. I do the insert picture button and it asks for a URL. That's usually found on the property panel of the picture I thought, but I don't see one on there. Sorry if this is not exactly on topic with the thread, I am trying to post screen shots of the code.

Use the "Go Advanced" button and you'll be able to upload a screen shot.

I may have mis-stated the appearance of the XIO. I don't have a controller available to me at the moment but offline anyway the XIO also appears to be always false.

This is where I believe you are running into issues. The appearance of the S:FS does not reflect it's actual true/false state. It can't because S:FS is not a tag your computer can see. This leads you to believe the instruction is "blocked" when it may not actually be so.

Here is a little workaround so you can actually see the state of this bit.

OG

Not seeing "Go Advanced" button, but I've attached the images. The first one is where the routine is being called with no extra conditions so pretty much a constant program file. The second image is where the first scan bit in question is messing up my logic. I'm getting all the other signals, but I need the end of cycle (EOC) bit true in order to release the pallet and keep the conveyor moving. We can pass it on manually but it is supposed to do it automatically in Auto Cycle mode.

Edit: After your last post, OG, I get what you are saying about the appearance of it being false, but I believe it really is false as I have every other necessary condition met to turn on that OTE except for the S:FS which leads me to believe it's not functioning properly. Now I could be wrong and there is something elsewhere that is causing the rung to go false, maybe happening too fast for me to see? It IS a very, very intricate program with 4 robots, a clean laser, a welding laser, conveyor and pallet system, 2 ePresses, and so on and so on. I didn't write the code for the cell but I am working with the guy who did. He is in Brasil at the moment so he can't be of much help, although he did say that he's never seen this before either.

That appears to backup what I said. The S:FS is not the reason your rung isn't going True. It just can't show you it's actual state.

OG

Operaghost said:

That appears to backup what I said. The S:FS is not the reason your rung isn't going True. It just can't show you it's actual state.

OG

Click to expand...

Ok, if that bit is not my issue, I will keep trying to find the hay in the needle stack. Thank you for all your help!

Is the ePRESS_Config routine an SFC(Sequential Function Chart) type one?
If it is (and sure it looks like it), then, according to post #2 link, each time the ePRESS_Config is being called up (probably at Main Task execution timing) the S:FS will be true for one scan; if the task containing the ePRESS_Config routine executes every 10ms for example then the S:FS will be TRUE every 10ms hence the results you are experiencing.
If you want to use the S:FS flag within ladder logic programming, place the SFC routine within a periodic task which's period is higher than the maxiimum execution time of the task which the ladder logix examining the S;FS flag is placed within.