Sign in to follow this  
Followers 0
simon Ong SK

MicroLogix Fast Counter

37 posts in this topic

Perhaps it is the version of softwre I am using (6.2) but on a 1500 LRP C I am only able to set inputs 1-4 down to 25us on a 1500. Others will only go down to 500us. However on a project from someone else, inputs 1-8 are set to 25us. So it would appear as if inputs 4-8 can be high speed, I am just not sure if there is a trick I am missing to do it. The reason I asked about examining the status of the other bit is for direction. What I had in mind was something like this: In CHA's interrupt routine, look at CHB. If NOT CHB then add a count. In CHB's interrupt routine, look at CHA. If NOT CHA then subtract a count. At this point in my thought experiment, I begin to question some of the usefullness of high speed inputs, and seem to slam headlong into my biggest frustrations with PLCs, in that no matter how fast the data is aquired, scan time limits the accuracy of what can be used. Perhaps immediate I/O commands could be used, but that would seem to compound the problem with scan times. Another issue that keeps circling my brain is that adding the interrupt routines also hurts scan times, and if incoming signals are faster than scan time, how does the main routine ever get a chance to do anything?

Share this post


Link to post
Share on other sites
I'm using version 7 but I thought version 6 had the same functionality as far as the input filters go. In your Channel A Rising Input logic mark that channel A has risen using internal logic. Then when you Channel B Rising logic you can look at this internal bit. It is actually better even in normal ladder to look at an interal bit 50 times than to look at a Input 50 times. It is documented somewhere. I'll try to find it. But pretty much in your A routine turn on an A bit and turn off a B bit. Then in that same routine if the B bit is on, you are going the same direction (ABA). If the A bit is on, the direction has reversed (BAA). Do the same in your B routine. This way you look at no inputs in your routines. And you should NOT look at any Inputs in your routines. Remember you internal logic is updated immediately. I think this is the part you are not understanding. These interrupts have no more effect on your program than the HSC function file or a tremendous amount of logic trying to do the same thing. Yes they do slow it down, but our scan times are still be around 2.5 -3 ms which I don't think is too bad. Don't get frustrated. These routines are harder to program but what they really require is that you write efficient ladder programs such as not looking at the same input numerous times and not using a lot of repeditive code. Don't use the immediate inputs because they take too long. Plus remember that besides inputs and output data, all logic is updated immediately. That is the key to writing these routines I'm going to try to strip down one of my programs to show the basic of how they work. But it may be a while. An operator crashed one of our machines really good and am going to be busy with it for this week. I should have taken a picture of it before we took it apart. 200 ton press and the guy broke the top off of it. This would have made an awesome crash pic. Do you understand what I am saying about the internal logic updating immediately and not looking at inputs? Let me know how I can help you understand this better And sorry about the earlier confusion on your appication. I got mixed up. Need to remember simon Ong SK - Up/Down Counter hakko808 - Encoder Kind of got 2 topics going on here but they are pretty much about the same thing Edited by TWControls

Share this post


Link to post
Share on other sites
Thanks for the help. Yes I confused internal logic with inputs. To clarify a bit, overall this has been a thought experiment. Since Simon needed directional capability I started thinking about encoders, which I assume is essentially how a directional flow meter would work. Perhaps I am confused about how the interrupt routines work in a PLC. My assumption is that when the interrupt is generated the program counter is pushed on the stack, the interrupt routine is run, and then the program counter is popped back off the stack so that the main routine can continue as normal. Given this assumption, if the interrrupt routines are called faster than the processing time of the main routine then the processor will do nothing but interrupt routines. This should also generate a stack error. Perhaps my mistake is equating scan time with main loop time. Given 3ms scan time this would be roughly 333Hz, much slower than the 13K that has been demonstrated to work in your projects. I am thinking I will need more informaiton on the inner workings of a micrologix but so far I have not found any. I assume this is a trade secret type of issue.

Share this post


Link to post
Share on other sites
Understand that if there is an interrupt it does not end a scan. If the scan of a processor is 3 ms there could be roughly 60 interrupts (20 interrupts per ms or 20 kHz). Your code is simple for each interrupt routine. Just think of it being executed 60 times. This should not really be that unrealistitc. Try thinking of it that way. Maybe that will help. I am going to make a program example for both you and simon. Sorry but it will take till atleast the end of week coming up. But simons example is easy and maybe that is where you should start. If input 0 is the up counter and Input 1 is the down counter. I would make the Input 0 interrupt have only an add statement. Current count = Current count + 1. Input 1 interrupt would have and sub statement. Current count = Current Count - 1. As far as the interrupt. Just think of it as having a JSR wherever the input trigger happens to happen in your program. It does not increment any type of counter, it just executes whatever code is in you EII routine. Lets just say you have a 5 ms cycle time. This would allow for 100 scans of the EII each scan. Is 100 Add statements in one scan within 5 ms that unrealistic. It really isn't when you think of it that way. Does this help any or do I need to go at it from a different angle? Help me out here, I feel like I am completely losing you in explaining this.

Share this post


Link to post
Share on other sites
TW: The Flowmeter that I used were single direction type. The Fast counter is only one portion of the programs. It was interesting for me to know the effect of interrupts. The whole application including Batching which I had to used One of the RS232 port for reading. The whole program has to run concurrently. There is A PC that will send the recipe and the PLC will performed all the task. As the Fast counters are at the tail end of the system where the filling process take place yet the batching can still run concurrently. So the Interrupt effect is really interesting. Can I ask something that outside this topic? I need to know whether I can make this connection: A PC with ethernet link to a HMI (Not AB), HMI act as a server. Connected device to AB PLC: Weighing Scale and HMI. I need to monitor the PLC at anytime I like without removing any connection from the above (Scale or HMI). If I Used SLC5/03 (1 DF1 and 1 DH485). How can I approach this? If I used M1500 LSP (with 2 DF1). How can I approach this? Thanks

Share this post


Link to post
Share on other sites
TW: I tried something here: 1) Connected Output 2 to 4 input from 0 to 3. 2) Using EII (Function File) 3) Enable PTO, injected 17000 pulses into Input 0 to 3. Observation: Input Filter at 75 usec. 4 input maximum Hz set at PTO is about 4000hz before CPU giving watch dog scan time error 2 input, 5900 at PTO 1 input, about 10khz. Am I right to test this way??

Share this post


Link to post
Share on other sites
I would suggest you start a new topic for this communications question. Personally I love ethernet but I have never dealt with weigh scales and there are many others out there that can help you on networks. But this topic is so long now that if someone is not interested in high speed counting they are not reading now. Plus I won't be here except early in the morning and late in the evening this week. Won't have time to respond during the day

Share this post


Link to post
Share on other sites
As far as your Pto results they are interesting, but I don't think it is the right way to test unless you are going to use the Pto. It consumes scan time Plus with your filters at 75us aren't you reducing you max to 13 kHz. How much code is in your EII. Either the Pto is consuming a lot of scantime or there is a lot of code in your EII.

Share this post


Link to post
Share on other sites
Just another thought. Weigh scales and flow meters are available on devicenet (and maybe ethernet). Why not get the Devicenet expansion module and put your weigh scale, flowmeters and whatever else on devicenet. Then use a 1761-Net-Eni on your serial port to go to you ethernet HMI and use Ethernet to also monitor your program. This would probably be a simpler method since you have to integrate this with a larger process

Share this post


Link to post
Share on other sites
First of all I'll be honest I have never used and don't know a thing about a PTO. But I did a little looking and the PTO seems to be very processor intensive. I normally hook the HSC to an analog output. Could you explain a little more about how to set them up and how they operate, Are they like an EII or HSC, or only updated every scan. Just a side question, what can you hook a PTO to? I did find a good chart on page A4 of 1762-um001D-EN-P. It gives the maximum frequencies per your input filter settings. At .075 the maximum counting frequency is 6.7kHz. Also one thing to think about with the 1100. I might should have posted this on the topic that you split but was trying to keep the fast counter stuff together I have been working with the guy that is using the 1100 for counting and the problem is with editing online while the counters are running. We did find this comment in publication 1763-um001A-EN-P page 7-7. I don't know if this is the problem he is having with the 1100 or how exactly you would define "quick interrupt latency" but it is also something else to weigh. Of course the 1200 and 1500 don't have online edits so you really aren't loosing anything and you are gaining a very cheap ethernet port. Edited by TWControls

Share this post


Link to post
Share on other sites
A good piece of information to know about the 1100, although I have run into similiar issues with PLC5 and SLC500 processors as well since being online, even without editing seems to slow the system down enough to affect the accuracy of timers by about 30ms. I would assume interrupt handling would be similarly affected. I am to the point where I won't count on an AB plc to do be more accurate than +50ms. The internal logic may know, but it takes awhile for the information to get to the real world.

Share this post


Link to post
Share on other sites
If I'm not wrong: PTO normally used on Stepper motor where you can output certain nos of pulses as such the stepper motor will move at the amount of pulse entered. The Pulse will generated will be send out throught O no 2 or 3 depending on the CPU. (Must be BXB) here is the excerpt from the manual: "Within the PTO function file, there are PTO element(s). An element can be set to control either output 2 (O0:0/2 on 1762-L24BXB, 1762-L40BXB and 1764-28BXB) or output 3 (O0:0/3 on 1764-28BXB only)." The neccessary setting on the Function files are: OF(Output Frequency):max 20000hz Top(Total Output Pulse to be generated) ADP(ACC/DEC Pulse) I use PTO to measured the accuracy of the Fast Counter. Which I'm not really sure whether this method is OK or otherwise. As I do not have any means or Pulse Generator to verify the Fast Counter capability and accuracy. Thx

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0