SLC505 communication servicing

[dpcrouch]

Hello,

With an SLC I've always thought that the comms servicing was done at the end of each scan. Assuming of course that there are no SVC instructions in the code.

However it looks like the comms servicing is actually done at the end of each Program file. So every time a JSR instruction to a subroutine is executed the comms is serviced. Is this correct?

I've inherited some code that unlatches all SCADA commands in a different program file to where the commands are actually used. I'm finding that about 1 in 2 command requests from the SCADA are getting lost. However, if I move the unlatch commands to the end of the Program File in which they are used the problem is cured.

 

[Ken Roach]

Welcome to the Forum !

Your initial understanding is correct. Communications are serviced at the end of the program scan or when an SVC instruction is encountered.

The reasons for your SCADA commands "getting lost" must be related to something else in the program execution other than the communications servicing.

Are these "momentary" functions where the SCADA sends both a "On" and an "Off" signal, or one-time data table writes, or something else ?

 

[dpcrouch]

Just to clarify, as the RSLogix500 terminology is a bit confusing here, when you say "at the end of the program scan" do you mean at the end of each "LAD" File as RSLogix500 also calls these Program Files?

Also, when looking at the in-built help regarding 'Comms Servicing Selection S:2/15' I noticed it says:

When set, only one communication request/command can be serviced per END, TND, REF, or SVC. When clear, all serviceable incoming or outgoing communication requests/commands can be serviced per END, TND, REF, or SVC. When clear, your communication throughput will increase. However, your scan time will increase if several communication requests/commands are received on the same scan.

The bit that caught my attention is the mention of the END command as this appears at the end of every Ladder/Program File. This reinforces my suspicion that maybe the comms are actually serviced at the end of each ladder file not the entire program.

 

[Ken Roach]

I guess I've never looked at the END instructions that way.

I was thinking of a "Program Scan" as being the execution of LAD2 by the operating system, and any subroutines called by LAD2. Once the program gets to the (END) instruction at the end of LAD2, it goes back through another cycle of housekeeping and I/O data exchange.

I do not know if the execution of the (END) instruction at the end of a subroutine also causes the handling of Message traffic.

I still don't know quite what your SCADA system is doing with its latches, or how that might be affected by putting those latches at the end of each subroutine instead of at the end of the program scan.

Can you describe this logic in more detail ?

 

[dpcrouch]

The SCADA is simply setting the command bits "On". The PLC is supposed to unlatch the command once it has been read.

When I get the chance I will do a bit more experimenting to try and isolate the problem. I'm wondering if there is a difference between putting the unlatch at the end of the subroutine and putting the unlatch straight after returning from the subroutine.

 

[Bit_Bucket_07]

It may (or may not) be true that comms are handled during the housekeeping phase of the program scan, but that doesn't guarantee that register status is updated. I know that both the PLC-5 and the SLC will sometimes update bit status from an HMI in the middle of a ladder file's execution. We discovered this long ago while using the US Data FactoryLink HMI for DOS. Since FactoryLink had no momentary pushbutton function, we were using a set bit function for pushbutton bits and then clearing the entire bit table unconditionally at the end of LAD2. Sometimes the bit would be reset before it was seen as high within the ladder logic. I've seen this happen in the other direction as well. In a program in which several data moves set the value of an N7 word, with the intention being that the last data move in the scan sequence was the desired value for the HMI display, I've seen numbers blink as the HMI would read the N7 word in mid scan.

Our work around for this issue is to use one set of registers internally to the PLC program and use a different set of registers for the HMI. We then move these values at the end of the LAD2 file. That assures that the data stays the same during the entire program scan.

 

[Ken Roach]

I'm not an SLC-500 firmware engineer, but what Bit_Bucket_07 is describing is exactly the opposite from the way I've always understood the SLC-500 communications service cycle.

This would be a great question for some of the old-line SLC-500 support guys in Cleveland.

 

[Bit_Bucket_07]

I'm not an SLC-500 firmware engineer, but what Bit_Bucket_07 is describing is exactly the opposite from the way I've always understood the SLC-500 communications service cycle.

This would be a great question for some of the old-line SLC-500 support guys in Cleveland.

Truth be told, I only remember testing this issue on the PLC-5. It's entirely possible that I have merely assumed that the SLC behaves in the same manner. That said, the OP's issue seems very similar to what we encountered with communications reflecting mid-scan values.