Slc 500 Monitor Bits On The Screen

HI EVERYONE
I think this is the nature of beast but why the state of bits are always with DELAY when seen on the computer monitor. thank you

because the processor must "talk" with your monitoring computer through SOME TYPE of communication device ... usually that's a cable and some type of port ...

the faster the baud rate the more closely the data will reflect reality - but it's NEVER quite "real time" ...

you can also speed things up by monitoring ONLY the data table that you really NEED to see ... other tables - even if minimized (hidden but still open) usually slow things down ...

related topic: the Histogram feature for the PLC-5 works pretty good (not perfect) at capturing fast data ... but ... the same feature for the SLC-500 family really stinks ... that's because the PLC-5 processor monitors the data ... with the SLC-500, the only thing monitoring the data is the RSLogix500 software - through the "cable" ... that slows down the information - and often gives unreliable results while troubleshooting ...

PS Edit ... if your model of SLC-500 will support it, you can try scattering a few SVC rungs throughout your program ... I'd only do this temporarily while monitoring - then take them out ... secret handshake: the SLC-500 usually ONLY communicates with the programming terminal at the very end of the ladder logic ... the SVC can tell it to "talk more often" ...

Get faster hardware

PERSPOLIS said:

HI EVERYONE
I think this is the nature of beast but why the state of bits are always with DELAY when seen on the computer monitor. thank you

Click to expand...

There will always be delay but the delays can be so short they aren't noticeable. I bet the delays can be easily reduced to 10 milliseconds or less with the right hardware. I think that is real time enough.

You can minimize the screen update time by reducing the number of data items that are polled by RSLogix500. If you close all data tables, and all ladder views, and put just the items you want to see in a CDM, the update time is noticeably faster.

This is most apparent on slower communication drivers like DF1. RSLogix can get really slow if you open up ten or twleve data tables, even if they are "behind" the window you are viewing, the information they contain gets added to the list of items being polled through RSLinx.

And, like Ron described, communication packets must be organized and passed to RSLinx, then polled over the communication channel, then the responses returned, and only then can the data be displayed.

Depending on which RSLinx driver you're using, there may be settings that can enhance the "freshness" of the display as well.

Look around in RSLinx at your driver configuration for more information.

Paul

When using the histogram in slc 500 I see lines 0 to 15 (bits I'm sure) listed on the histogram screen. Let's say that I am looking for B3:5/14...When I type that address in, for me to view the histogram, I will be looking at the line where number "14" is for my logic,correct?

if this is a "fast acting" bit, be careful with using the histogram to track its operation ... the histogram in RSLogix500 has a dark side to its nature ...

http://www.plctalk.net/qanda/showthread.php?p=67950&postcount=5