Sign in to follow this  
Followers 0
BIGEYE

Rotational counter help

39 posts in this topic

Also attached is a screenshot of the status during the plc error.

Share this post


Link to post
Share on other sites
I'm confused by the use of 1.0 second timebase timers (e.g T4:16) for timing between actuations of the Filter Rotation Monitor inputs. The subsequent math ( 600 / time) to get RPM implies that you should be using .1 second timebase (for 600 increments in a minute). That probably has noting to do with your fault though. [Edit: Maybe your division using 600 and the 1 second time base give you one implied decimal point for the RPM. In that case ok.] The most frequent item I had seen was an overflow or a divide by zero - though I see that you wisely test for the divisor being greater than zero. Look for registers with a high value (32767 possibly) If this continues and it is hard to locate place a test for S:5/0 frequently leading to a OTL of a unique bit and OTU S:5/0. Use bits from a single word for an easy test at the end of the scan. The fault shouldn't happen but watch the bits to narrow down where the fault occurs. Edited by b_carlton

Share this post


Link to post
Share on other sites
I won't get back to this site until next week, I'll have a tinker then. ATM I have disabled all the rungs for the rev counters just in case something else is causing the problem.

Share this post


Link to post
Share on other sites
Your error is a simple and common math overflow. You could leave your new logic working and unlatch the minor error bit before the end of scan to preempt a major error and keep the SLC (and your new logic) running. I normally set an internal bit for each section of logic that I suspect is causing an error before clearing the overflow trap bit. This way, I know there is still something wrong and have a means of narrowing it down. In your case, you're pretty sure it's the new logic causing the offense, so it should be pretty easy to locate. I haven't looked at your code yet, but check your math instructions for things that could result in a value that cannot "fit" in the destination. Example: a values less than -32768 or greater than 32767 can't fit in an INT location (or any other 16 bit register). Accumulating (adding a value to a register) repeatedly without taking steps to prevent (or detect) overflow is probably the most common cause. Dividing by zero is another common one.

Share this post


Link to post
Share on other sites
I would look at the CPT instruction in Rung 51 of the PDF file you attached earlier. Since the destination register is an integer, all intermediate steps in the CPT are limited to values ranging from -32768 to 32767. So, if the sum of N7:90 + N7:91 ... + N7:104 is ever greater than 32767, you will get a math overflow error.
1 person likes this

Share this post


Link to post
Share on other sites
Thanks Scott for the reply. Rung 51 does not form part of my code. The code is from Rung 53 to the End instruction.

Share this post


Link to post
Share on other sites
This is what I think it is. if you change the divisor at the end of the CPT block from "15" to "15.0" this should type cast the interim calculations as a floating point value. Or your could change the destination to a float. IF that part of the logic works without causing an overflow I am not sure what else it could be. I don't see anything obvious in rungs 53 on. The way you're restting the counters is a bit weird. If you RESet them based on the DN bit on the rung or branch immediately preceding the CTU instructions, then the DN bit can be used for one whole scan. By clearing (MOV source 0) the ACC right after the CTU instruction, you're not resetting the DN bit until the scan comes back around and executes the CTU instruction again and finds that the ACC is less than the PRE. I still say you should simply measure time between two pulses and calculate rate then and there, throw out the first sample after each time the rotation is known to have stopped (or reversed if it reverses), and then you're done with more accuracy, less logic and less waiting.

Share this post


Link to post
Share on other sites
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.
1 person likes this

Share this post


Link to post
Share on other sites
I see. I guess I looked over all that stuff searching for potential overflow errors and didn't pay close enough attention to exactly what he was doing...just looked kinda long winded to me so thanks for the explanation. Edited by OkiePC

Share this post


Link to post
Share on other sites
If any of the sensor inputs are getting 2 quick pulses resetting the timer at 1 second this could cause a math overflow? 600*60=36000 How big is the detection area for the inputs? Even though there is a [ONS] this would not help if the sensor is seeing more that 1 pulse.
1 person likes this

Share this post


Link to post
Share on other sites
There is a possibility that this may be happening. I am getting plates made so that the proximity switch has a bigger target. These will be fitted next week hopefully.

Share this post


Link to post
Share on other sites
You can also cure this in software, by 1st de-bouncing the sensor and then keeping it on for the minimum time required to ensure that is has physically traveled off the target and can't cause the oveflow. Good find Chelton, if this indeed solves it.

Share this post


Link to post
Share on other sites
As Okie says, de-bouncing the input would be a simple software solution. In your program since all your input is doing is resetting the timer, simply branch around the input before the -[OSR]- with a less than comparitor comparing the timer accumulated value with fixed value. T4.XX.Acc < {3..4..5 } to prevent the timer resetting on false signals.

Share this post


Link to post
Share on other sites
Fitted plates to the filter arms so that the proximity switches have a larger target and provide a longer pulse, also to reduce the likelihood of two or more quick pulses. Also modified the code as chelton suggested. The changes have been working now for about ten days, so I think we can say that our problem has been resolved. Thanks to all that have helped, especially to cbuysse, OkiePC and chelton. Edited by BIGEYE
1 person likes this

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