cbuysse

The only gotcha I've ever run into with PointIO over EthernetIP is making sure to verify the processor has enough available CIP connections. It doesn't sound like you are going to have a problem with the IO you've listed, but it wouldn't hurt to check. Rockwell makes a pretty nice little program on their webite to help you determine how many CIP connections you'll need for your network. Figuring it out can be a little tricky sometimes. For instance, each PointIO head module requires a CIP connection as well as each analog module. Panelviews can eat up as many as 5 connections depending on what services you use withing the HMI program. Depending on which controller you're using those connections can disappear fairly quickly and figuring out why something is not talking can definitely cause you to lose a few brain cells and possibly require repairs to the nearest wall. Otherwise, my experience with PointIO over EthernetIP has been extremenly positive. Very easy to set up and works very reliably. Good luck to you.

That is exactly what he's doing in rungs 53-55 - except for the part about throwing out the first sample. The rest of the logic is to satisfy the requirement to count the total number of revolutions per day.

Check the OSR instruction bit address. Make sure that the same address is not being used somewhere else in the program. The fault you are describing indicates that a register value became larger than it could store - in this case it's most likely the .acc value for counter2. The only way that could happen in your code is if the MOV command didn't function. My first thought is that the OSR instruction isn't functioning correctly because that address is being used elsewhere.

I'm using Rockwell's Logix 500 Emulator. I'm not sure of any other programs to Emulate an A-B PLC, though I would be interested to know if others exist.

Yep - I screwed up. Each "XIO" I mentioned above should have been "XIC". My apologies. I also forgot to take care of the situation where the counter will automatically count up one when you reset it and the counter input is still on, so get rid of the RES instructions and instead MOV 0 to the .acc value. Here's a screen shot showing what I should have described. I just ran it on my emulator and it works fine. Sorry for the confusion - chalk it up to holiday stress.

Then you should be all set. The integer file will show the total number of revolutions from yesterday. If you want to display the running total of today's you can use the counter2.acc value. Good luck to you.

SLC's have a status word that represents the hour of the day, I believe it's S:40. It's always a number between 0 and 23. You can use that to determine when to make your calculations. First rung - XIO of the prox input and then CTU counter1 - set counter1.PRE to the number pulses per rev (is it 2 or 4 - you've stated different numbers) Second rung - XIO counter1.dn then CTU counter2 and RES counter1 - set counter2.PRE to 32767 Third rung - when S:40 is EQU to 8 (or whatever hour you want to use) OSR then MOV counter2.acc to a separate integer and RES counter2 - you need the OSR here so it won't try to do this for an entire hour between 0800 and 0859. This only works if you expect to have less than 32767 revolutions per day. That corresponds to about 22.75 rpm if this thing runs 24 hours a day. Anything less than that and you're fine. I just had another thought which may change everything. Is your prox picking up a flag on the shaft of the actual rotating part you're concerned about, or on a separate drive shaft? What I'm getting at is whether or not there is actually a whole number of prox pulses in one revolution. If it's not exactly 2 or exactly 4 this method won't work at all and you'll have to change some numbers on the rpm calculations.

If you continue as you are, your accuracy will be +/- 0.25 rpm (or rph) with 4 pulses per revolution or +/- 0.5 rpm (or rph) with 2 pulses per revolution. If that level of accuracy is sufficient and you are satisfied waiting a whole minute (or hour) to update the value then your current method will work fine. Another option to consider would be to measure the time between each pulse. Assuming each pulse is equally spaced through the revolution you can time between the start of each pulse and calculate the rpm (or rph). Not including some error checking, this can be accomplished in three rungs: First rung - TON with no input conditions - let it run continuously. Set the preset to 32000. Use your best judgement to figure out which time base to use. It all depends on how quickly this thing spins and how accurate you'll need the final answer to be. Second rung - XIO of the prox input followed by an OSR instruction - MOV the timer.acc value to an Integer and RES the timer Third rung - make sure the Integer is NEQ to 0, then DIV 3000 by the Integer to get rpm (assuming you used 0.01 as time base and you have two pulses per rev) If you have 4 pulses per rev you'll have to change the 3000 to 1500. You can make it 30000 (15000) to get an implied decimal if you're looking for some better accuracy. This will update the speed readout every time a pulse is recorded and provide much better accuracy than the method you've described.

There is no functional difference between an OSR and an ONS/OTE combination as you're attempting to use it. Both versions will change the value of the tag in the OTE or output of the ONS to 1 when the EQU instruction transitions from false to true. That tag value will remain 1 until that rung is evaluated again. On the next time around the tag value will be changed to 0. That means that tag value will be 1 for everything else the PLC does until it gets back to reevaluating that rung. Just out of curiosity, your documentation states that the reset should occur a minute before midnight, but if I'm interpreting things correctly in the code it appears that it will actually reset a minute before noon. Is that what you had intended or am I reading it incorrectly? My only other thought would be to make sure that the tag you were assigning for the ONS instruction was not used anywhere else in the program. Referencing that tag elsewhere can cause some real headaches.