klm
  •  klm
  • 70.75848% (Friendly)
  • Advanced Member Topic Starter
2020-04-29T21:51:33Z
Hello,

With any completed program, how do you calculate the
scan time it takes to get thru the whole program once.
(before staring the same cycle over again).

Thank you,
klm
Guest
2020-04-29T22:11:15Z
Scan time with any controller correlates in part to the number and type of instructions used. An XIC will scan much faster than a MOV statement. Calculating the scan time can be rather tedious and I have rarely seen it done. What is usually more efficient is to know your processor and your project. It is always better to pick a processor that is not on the edge of handling your program. For large systems, multiple processors can be used to handle different parts of the system. I can only remember having scan time problems once on a project and it was with a processor that was chosen for a much easier task. That system actually grew to several times the initial intent. In addition, the data manipulation used in the final stages of that project were not really the strong point of that processor and it was very slow in handling the tasks. Some times scan problems in a case such as that can be solved by running time sensitive or input sensitive tasks in interrupt tasks. The newer processors, such as the Logix, also allow you to setup several timed tasks that operate some program files periodically - some fast and some slow.

Ok, now that I've wandered a bit, back to your actual question. You can calculate with some accuracy the scan times of a processor by using the manuals provided by the manufacturer. Even if you dont want to calculate your scan time, it is worth looking through the manal to get an idea how long different instructions take to run. Then if you have problems or if you are planning a big program you can use the instructions that will be most effiecient. Also understand how the processor works. The Logix series for example works on 32 bit words; therefore if you use a bunch of 16 bit INT instead of the DINT instruction types, the processor will have to convert the INT to a DINT - do the operation - and convert back to INT. Lot of extra steps. So where do you get the scan time info? Well it used to be in the Instruction set manuals. It looks like they took it out of the SLC manual. The copy of the Micrologix manual that I have has a section on execution times in appendix A. Here is a link to that manual on the AB site; however I cant guarentee that they have not removed the section from the latest Micro manual also.

http://literature.rockwe.../rm/1763-rm001_-en-p.pdf 
klm
  •  klm
  • 70.75848% (Friendly)
  • Advanced Member Topic Starter
2020-04-29T22:21:48Z
Thanks. There is some good information in your reply.

The reason I asked is because I have a program that has a 'string data file' that displays

the seconds from Status file S:42. When I look at the 'string file' the time jumps from ... lets say

42 seconds to 45. The correct time is there from one second to the next, but

on the screen I see the time update 2 or 3 seconds; at a time; not one second at a time.


-also- While looking at the "spinning Ladder Graphic" (RSLogix 500) while on line, it spins slowly at times and stops and stutters sometimes.


Any way - thanks for your help. P.S could I make a suggestion about the traing videos.

Could you possibly make a video covering the topic of the "E Stop"? Something like the basic's, how it's wired-up, the technique

of the why and how.

Thank you,

klm
Guest
2020-04-29T22:27:20Z
got to write this fast, but you have communication problems. The graphic should not start/stop but be continuous. Also, remember what you see on your computer screen is not always what is going on inside the PLC. The plc is generally scanning in ms and your comm link is much slower. Check your status file for maximum scan rates for your program. That is what you need to look at to really know how fast the PLC is scanninig an active program.
klm
  •  klm
  • 70.75848% (Friendly)
  • Advanced Member Topic Starter
2020-04-29T22:32:31Z
Thanks for the direction. Sounds like a good challenge to figure-out whats going on with the communication.

Now that you mention it, and I'll look into this when I get back, it may be too small amount of RAM (on the PC that I program with) or

maybe not enough processor speed; something along those lines.

Thanks-

klm

Users browsing this topic