Counting multiple outputs

This seems like an incredible amount of extra gymnastics just to count bits. You don't need a timer and a counter or all those one shots to make it work with your counter. Plus it looks like it takes you 120 seconds to get a fresh update on the bin count.

See attached - it gives you a fresh count every scan and uses no timers or counters.
 
Last edited:
???

So you can wait all that time for the total to be accurate? 60 counts times 2 second intervals, two minutes will go by before you have an accurate count...why?
 
Well he shouldn't get frustrated. He could always view each time it comes up as an opportunity to learn a new way of doing it. I know they way this guy wound up doing it is certainly a new one on me. Thats why I'm hoping he comes back and explains it a little bit. While I'm waiting, if any of you have a better understanding of what he was doing, lay it on me. Particularly I dont see how the count doesn't just keep going up ad-infinitum.

-jeff (maybe thats just me)
 
Why re-invent the wheel?

Hakutsuru said:
I know they way this guy wound up doing it is certainly a new one on me. Thats why I'm hoping he comes back and explains it a little bit.
Just because it is new doesn't mean it is right. I have said before there is little in this area that was figured out many years ago. If you follow what Alaric has done you will be on the right track.

Alaric has posted two good generic solutions. One is obvious. There is a third generic good solution that hasn't been covered on the forum. Some PLCs have a bit counting block. 'Original' solutions should be avoided unless you can prove it is better. ( doubtful ).
 
rsdoran said:
This is a learning site, if there is a 3rd option or any option not mentioned then offer it.
Fine, someone offered 'original' solutions and I am amazed the people would ignore the correct solutions provide by KentuckyMark and Alaric. Why would people ignore the orthodox solutions developed by thousands of programmer over the last 50 or so years?

The thread continued to go astray so I made my second post. I effectively said that the algorithm Alaric ( KentuckyMark too ) proposed are the 'orthodox' way of counting bits and 'original' methods are inferior. You would have Hakutsuru and imonline waste their time on developing inferior algorithms while I am am steering Hakutsuru and imonline straight to the orthodox solutions thus saving them time.

To be plain, get off your egotistical fat arse and answer the questions or ignore them, stop with the high and mighty ****.
There was nothing more to add after KentuckyMark and Alaric first posts. The thread should have ended there but it strayed. Would you let it stray?

This is all old stuff. Ron you know that. You may have empathy for the rookies. That will not help them. The forum has history and knowledge. You know that too. Don't you think it is a little arrogant that the rookies come to this site thinking that they are the first to ever have a problem?
 
Thank heavens for the BCNT (bit count) instruction. Specify the start channel, number of channels and output word. Put all alarm latch bits in contigious channels, all acknowledged alarm bits in contigious channels, perform BCNT on both sets of contigious channels, compare the result words, if the latch count is higher than the acknowledged count turn on the alarm sounder. When the acknowledge button is pressed, the 2 result words are equal and the alarm sounder turns off ready for a new alarm.
 
Golly, I'm having trouble following that. Purely academic, i realize, but lets see if i have this straight. Since you have 20 inputs to count, I'm assuming your timer really goes up to 20. So, once a second you are checking each rung and adding 1 to your total if needed. Once you've been through them all, you reset the timer and do it again. After 59 iterations you move the count into another register (to log for posterities sake?) and after the 60th iteration, you reset the counter and start again. The one thing conspiculously absent here is how does N9:49 get reset? You say it works and I beleive you because you're a trustworthy sort. But this looks like it would just keep counting up until the number got so large it faulted the processor.

I've set the timer to 2 seconds. Everytime the timer becomes done, it adds 1 to my counter and then resets it's self.
I've set each rung to represent one bin (58 in all) so that when my counter equals 1 then it checks for the rung that equals 1 to see if my bin is active, if so it add 1 to N9:49. For example if my counter is 26, it checks the rung that equals 26 and if active adds a 1 to N9:49 and so on till the counter reaches 59 where it moves N9:49 to N9:50 (for posteritie) then at 60 it resets the counter and starts over.

I've made ajustments since. I've added a MOV 0 to N9:49 when the counter reaches 60. Also added a one shot to every rung as you can see below:

Scan1.jpg


-Don
 
Thanks everyone for the info, I've learned a few new ways of dealing with my problem.

I apologies to the members if I brought up an old issue.

I'm gratefull for your input and again thank you.

-Don
 
Peter Nachtwey said:
Alaric, are you frustrated yet? At this rate you will cover this topic about 10 times this year.
To supplement what Peter says, I'm really not sure that the "doubter's" of Alaric's solution understand the concept of PLC "scan".

I'm not sure that everyone realizes that if you made twenty unconditionally true rungs that each had a "move" statement moving values from 1 to 20 into the same register, the last one "wins" and a value of twenty would be in the register every time.

In other words, that is why Alaric's multiple adds into the same register can be done once per scan and every scan and work the most elegantly...
 
The wheel needs improvement

Peter Nachtwey said:
Fine, someone offered 'original' solutions and I am amazed the people would ignore the correct solutions provide by KentuckyMark and Alaric. Why would people ignore the orthodox solutions developed by thousands of programmer over the last 50 or so years?

The thread continued to go astray so I made my second post. I effectively said that the algorithm Alaric ( KentuckyMark too ) proposed are the 'orthodox' way of counting bits and 'original' methods are inferior. You would have Hakutsuru and imonline waste their time on developing inferior algorithms while I am am steering Hakutsuru and imonline straight to the orthodox solutions thus saving them time.


There was nothing more to add after KentuckyMark and Alaric first posts. The thread should have ended there but it strayed. Would you let it stray?

This is all old stuff. Ron you know that. You may have empathy for the rookies. That will not help them. The forum has history and knowledge. You know that too. Don't you think it is a little arrogant that the rookies come to this site thinking that they are the first to ever have a problem?

I missed ron's post, he must have deleted it, but I agree 100% with the parts you quoted. First off, look back at the first page, I *know* Kentucky Mark's solution was the best, I was about to post the same thing, but he beat me to it. That, in no way means its the only way it should ever be done. C'mon, this is programming, there are a hundred ways of doing things and we'll do them all 100 ways. Nothing at all wrong with that, and nothing wrong with learning about those other solutions. It doesn't mean we're ignoring the tried and true methods. Look, just because the first solution (the for-next loop) was the best in this case doesn't mean alaric's original solution was worthless, does it?

There will be situations where it is best. BTW, I think the person who posted the solution with the bit shifting was better than alaric's loop, but they're both only useful iff all the outputs you wanna count are consecutive (but talk like that might out this thread back on topic, so I'll stop it there). The same goes for the other solutions posted here (in all liklihood, I mean some may be rubbish). Its a flaw in your own personality that you cannot see how new ideas may be useful tomorrow, IMNSHO. I have no doubt that at some point in my career, a new problem (new to me) will come up, and I'll remember some alternative solution I saw on this board, and it'll be exactly what I needed. I gotta agree with Dan, this is a learning site. If you don't wanna learn, then fine, plug your ears and run away, but what you're doing here is actively attempting to BLOCK the learning process, please don't do that anymore. We understand that you think those 2 solutions are the only viable solutions. We understand you are the smartest man in the world and can therefore make those determinations. Now leave us alone and let us explore a little for ourselves.

And a couple more things, I'm not really a rookie when it comes to PLC programming.
No one on this thread thought this was the first time anyone had tackled this problem.
And from my point of view, the true arrogance is someone thinking they have all the answers. Every last one of them. No possibility whatsoever for any piece of knowledge or idea to exist that they do not already have.
When people do come here thinking they have a new problem (which does happen occasionally, but not nearly as often as the accusation is thrown around), thats not arrogance, thats ignorance. You deal with ignorance through education.

And finally, why re-invent the wheel? If the folks at goodyear had an attitude like that, we'd all still be rolling around on rounded rocks.


-jeff
 
I think imonline now has a solution to his problem.
This post got my thinking. When I get some free time, I am going to attempt to the most complicated Rube Goldberg logic to count 20 pulses. Anyone else care to give it a try? This may be logic for us advanced programmers but I think that students may beat us out on how to turn something simple into a complex maze of logic.
 
imonline said:
I've set the timer to 2 seconds. Everytime the timer becomes done, it adds 1 to my counter and then resets it's self.
I've set each rung to represent one bin (58 in all) so that when my counter equals 1 then it checks for the rung that equals 1 to see if my bin is active, if so it add 1 to N9:49. For example if my counter is 26, it checks the rung that equals 26 and if active adds a 1 to N9:49 and so on till the counter reaches 59 where it moves N9:49 to N9:50 (for posteritie) then at 60 it resets the counter and starts over.

I've made ajustments since. I've added a MOV 0 to N9:49 when the counter reaches 60. Also added a one shot to every rung as you can see below:

-Don

So N9:50 is your real count then. I didn't realize you had 58 bins to count, thought you said 20, and you answered the thing that was perplexing me the most with the addition of zeroing out N9:49 when you reset the counter. But still, you can wait 2 min to get the count updated? For the record, I would take out the counter and timer and just let it do all of the addition blocks every scan. But, unlike others on here, I won't say you *must* do things my way. I'm sure you have your reasons. I wonder if doing it this way saves any scantime? Probably not since you had to add a timer.



-jeff
 
Hakutsuru said:
So N9:50 is your real count then. I didn't realize you had 58 bins to count, thought you said 20, and you answered the thing that was perplexing me the most with the addition of zeroing out N9:49 when you reset the counter. But still, you can wait 2 min to get the count updated? For the record, I would take out the counter and timer and just let it do all of the addition blocks every scan. But, unlike others on here, I won't say you *must* do things my way. I'm sure you have your reasons. I wonder if doing it this way saves any scantime? Probably not since you had to add a timer.



-jeff

I've got an archiving/historical program that picks data off our plc's. I've set this program to gather N9:50's data every 4 minutes. So even if I wait 2 minutes to get the count updated, it doesn't matter.

-Don
 

Similar Topics

Hello I am looking for tips on how to count the duration of a given function and then how to display it on the hmi panel in the hh:mm:ss format...
Replies
4
Views
1,705
Guys, I know it will be silly but can't get my head around it. I have 3 conveyors, every one on a separate servo drive, and 2...
Replies
25
Views
3,513
The 1734-IB8 has no hardware counting function correct? I am trying to find something to substitute in for a 5069-IB16F (since lead times are...
Replies
3
Views
1,418
Been scratching my head at what I thought should be a relatively simple task. I need to count how many rows a .csv file has, so I can later read...
Replies
6
Views
2,560
Hi All, I need to count my Contactor switching times. There are lots of them so I created a template logic with local variables in FC2000. Now I...
Replies
10
Views
2,140
Back
Top Bottom