Spinning ladder question

So, i found the answer ultimately here:

http://www.plctalk.net/qanda/showthread.php?t=10000&highlight=ladder+stops+spinning

However what i experienced was that s:2/15 = 1, and that my RS500 would allow me to do work, make edits, so on but the ladder would stop spinning altogether. Trends wouldn't work, simply watching things go on and off would wouldn't work...This was on an SLC 5/04 via DH+. It threw me for a complete loop as to why i could make edits, but not see anything displaying in 'real time'!? changed it to a 0 and immediately got things working correctly.

I do recall now messing with the comms service selection a while back, but it took a long time for the symptom of the ladder spinning to catch up.

What happened...? obviously the processor was able to execute logic or this would have been a bigger issue sooner, but why did changing s:15/2 to a 1 eventually lead to a complete lack of "GUI" updating?

...why did changing s:15/2 to a 1 eventually lead to a complete lack of "GUI" updating?

Click to expand...

Because of what S:2/15 does: when clear (0), it allows servicing more comm requests at any one time.

Comms Servicing Selection S:2/15
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.

To prevent inadvertent changes to this setting, program an unconditional OTL instruction at address S:2/15 to ensure one request/command operation, or program an unconditional OTU instruction at address S:2/15 to ensure multiple request/command operations.
RSLogix 500 - Copyright Rockwell Software

Click to expand...

i guess what i was really wondering was why did it take so long for the effects to occur. Comm's servicing was change months ago. it wasn't until weeks ago that things stopped working for going online. I would have expected that the loss of functions would have occurred rather quickly.

My guess would be that it needed a very busy time when the comm link was heavily loaded - or you have some other comm problem and the comm setting was only coincidental.

The RSLinx Ladder Spinner is intended to be a data rate gage for the amount of data moving through the RSLinx path.

So, if it stalls or slows or stops, then online data has stopped flowing. This can be caused by an overloaded SLC. They are not the multiprocessor workhorses like the PLC5 and Logix5k controllers, so manipulating the comms service control bits can definitely affect the rate of communication as shown by the spinner. More importantly, changing them can affect the scan time of the program, so it is usually something I only change after monitoring scan time and studying the code, so that if there is an adverse affect, I have a baseline to compare with.

BTW, you can change that spinner to your own images if you want.

Also, the mere presence of lots of nodes on a DH+ network will cause delays, I typically noticed HMI slowdowns and RSLinx sluggishness at about 10 to 12 nodes especially if most of them were HMI (nagging polling traffic). We tried to keep each DH+ network used by HMI traffic under 7 nodes.