This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc. 

Try our online
PLC Simulator FREE.
Click here now to try it.

New Here? Please read this important info!!!
May 20th, 2005, 03:32 PM  #16 
Member
Join Date: Feb 2005
Location: Ottawa
Posts: 1,003

you know what the scary thing is??...This is the easy way!!! can you imagine a full blown explanation..!!!
Thanks Ron.. D 
May 20th, 2005, 09:34 PM  #17 
Lifetime Supporting Member

ron
thank you so very much .you did a lot of work here .i am sure this post is going to be hot for quite some time . i have taken a lot of plc classes and this was never covered in any of them . i now have my application working thanks to you. and i also have some 5/01 and 5/02 processors running programs that are using standard math functions to scale analog data and now i understand what is going on there also again thanks so much phil buchanan
__________________
Phil Buchanan 
May 21st, 2005, 07:54 AM  #18 
Member
Join Date: Oct 2004
Location: Southeast Missouri
Posts: 6

Fantistic Ron...
John 
May 21st, 2005, 03:31 PM  #19 
Member
Join Date: Jan 2004
Posts: 374

How here to use
There is many tools that do not be applied, do not know the domain becomes incomplete and insufficient solutions
Application: 1)Determine resolution and system gear Obs: Get the real resolution (errors and variations included) 2)Determine to calibration or range of element analogic 3)Interpolation new variable in function others (Sample: Outflow grease; depends temperature and level tank) 4)Alarm for instable signal (not linearidadeget degradation) 5)Conversion of not lineal in segments. Practical procedure (How to use), would be able to describe in english native. Ok!? Other massive use is include equation in code, main "online or anticipate value" For make: 1)Intercpetation of two variables or more. 2)Change parameters in function part change. Last edited by dandrade; May 21st, 2005 at 03:41 PM. 
May 21st, 2005, 11:16 PM  #20 
Member

Ron... This is truly amazing stuff. I linked to your home site and checked out your pdfs on PIDs. I was just wondering if you were going to include this as a pdf on the same site. Also have you ever or do you plan on publishing a book or some type of home study course? This is so easy to read and understand. Thanks a lot for taking the time to post this as well as your other posts.
Later...Todd 
May 21st, 2005, 11:32 PM  #21 
Member
Join Date: Dec 2004
Location: Detroit, SE Michigan
Posts: 3,242

Nice post and review of trig/precalc from high school.
I prefer using the form (yb)/m = x. In this case, Y is the input variable and X is the output. Its easy to zero (make the b value equal to Y) and is cleaner when Y is an integer out of a analog input card. Algebraically its equivalent. 
May 23rd, 2005, 07:56 AM  #22  
Lifetime Supporting Member

going a little bit further ...
Greetings to all,
first things first ... thanks to everyone for the kind compliments ... I’ll try to answer your questions and comments as this thread continues ... next to tie up a few loose ends ... rta53 asked the following excellent question: Quote:
yes, the basic techniques would be exactly the same, but we might need different ladder logic programming in the PLC to execute the math ... and in just a second I’ll give you an example ... but first I want to clear up something that I said back in post #1 ... I made the statement that “... in simplest terms, with the hardware that he has available (SLC5/02), our friend MUST use an SCL to get this scaling job done” ... well, that’s not exactly true ... actually the SLC5/02 processor (and even the smaller SLC5/01) can do the scaling operation that I used for my example with “standard math” as the book calls it ... note that the book considers the DDV (Double Divide) instruction to be a “standard math” function ... I hadn’t really considered the possibility of this type of solution while writing my original post since I was focused more on explaining the use of “y=mx+b” ... but with the possibility of a “standard math” solution in mind, I’d like to change my statement to: “... with the hardware that he has available, our friend will probably find an SCL the easiest way to get this scaling job done” ... so thanks to rta53 for jogging my memory as to the possibility of using something other than an SCL ... it’s been a long time since I’ve worked with the smaller SLC500 processors and so I think that I’ll use that as my excuse for leaving the “standard math solution” stone unturned ... now let’s see how even an SLC5/01 processor can do scaling without an SCL ... and remember, this type processor does not have a floating math capability ... a good way to start this discussion would be to take another look at Figure 7 in this thread ... in the solution to that example, I calculated the value for “m/Slope/Rate” as 0.091555528 by dividing the “Rise” (3000) by the “Run” (32767) ... and that was fine for the method that we were using in that particular discussion ... but now let’s go a little bit deeper ... Figure 13 gives an example of another way of skinning the cat – one which will work with the SLC5/01 processor that rta53 brought up for discussion ... here we have the exact same problem as we had back in Figure 7 ... specifically, a 0 to 10 VDC input signal from the field gives us raw data readings which range from 0 to 32767 ... we want to convert the raw data into scaled values which range from 0 to 3000 (psi) ... the biggest hurdle to getting that done is that the processor that we’re working with doesn’t support floating point math ... nailing that issue down: we don’t have anywhere to store the “m/Slope/Rate” value (0.091555528) in the PLC’s memory ... so let’s take the specific example given in the figure and see how we might proceed with a solution ... specifically, let’s come up with a scaled value to go with a raw input data signal of 20753 ... note that following operation is outlined step by step at the bottom of Figure 13 – and the program rungs will be shown later in Figure 14 ... first we’ll multiply the raw input data reading (20753) by the span of the scaled values (3000) and specify N7:0 as the destination of the MUL instruction ... mathematically the result “SHOULD BE” 62259000 ... but we have an “issue” with that great big old number ... the problem is that a number that large will not fit into the 16bit integer location N7:0 ... and so the processor (bless its little heart) does the best that it can ... it stuffs N7:0 with the largest number that it will hold (32767) and it sets the “Math Overflow” bit (S:5/0) to let us know that it ran into a math problem along the way ... and then the processor also does something else which is quite useful for our purposes ... it moves the full result of the multiplication into the 32bit “Math Register” ... specifically, after the multiplication, words S:14 and S:13 (taken together) will contain the number 62259000 ... now if we only had a way to divide that 32bit number by 32767, we’d have made significant progress toward our final solution ... and luckily the DDV (Double Divide) instruction lets us perform exactly the division operation that we need ... so we’ll use a DDV to divide the value stored in the 32bit math register (62259000) by the span of the raw input data (32767) ... and we’ll specify N7:0 as the destination of the division ... bingo! ... now N7:0 contains the result of our scaling operation (1900) ... a quick recap: usually we would handle this example scaling operation by first finding the “m/Slope/Rate” value  by dividing the “span” of the scaled values (3000 in this example) by the “span” of the raw input data values (32767 in this example) ... but that approach would result in a floating point value (0.091555528) that our limited processor could not store ... so generally we would “work around” this “nofloatingpoint” limitation by using an SCL instruction ... the SCL would allow us to first multiply the original “m/Slope/Rate” number by 10000 before typing it into the SCL’s “Rate” entry ... BUT ... the SLC5/01 processor mentioned by rta53 doesn’t have this SCL instruction available ... and so we need another type of “work around” to help us with our scaling ... so instead of DIVIDING first and then MULTIPLYING second, we structured our program to MULTIPLY first and then DIVIDE second ... doing the math in that reversed “order of operations” gives the same final result but it allows us to make use of the 32bit “Math Register” during our DDV (Double Divide) operation ... and so rta53, I hope that answers your question and I thank you for bringing it up ... in a nutshell, yes the same techniques for the “Slope of the line” equals the “Rise” over the “Run” that we covered earlier in this thread still apply even when you don’t have an SCL available ... and the sketch of the graph that we’ve been using doesn’t have to change  EXCEPT for one minor thing ... notice that the top of the graph in Figure 7 shows the value of “m/Slope/Rate” as a decimal number (0.091555528) ... but the top of the graph in Figure 13 shows the value of “m/Slope/Rate” as a FRACTIONAL number (3000/32767) ... that pretty much demonstrates the only difference in the approach ...
__________________


May 23rd, 2005, 07:58 AM  #23 
Lifetime Supporting Member

here in Figure 14 we have a program rung which would handle the scaling operation that we just discussed ... compare this with the SCL approach used in Figure 1 ... note that occasionally a program may require some type of “range limiting” operation located just above this “scaling rung” ... this approach would keep any weird “out of range” numbers from exceeding the capabilities of the math operations ... and definitely notice the unlatch instruction which turns off the “Math Overflow” bit S:5/0 immediately after the scaling is complete ... this is required because of the “overflow” condition (integer greater than 32767) which results after the MUL step ... if this bit is not turned off before the end of the scan, a processor fault will occur ... incidentally, the Destination (N7:0) is used as a “dummy” place holder in the MUL step ... specifically, we don’t care what value the MUL places in its Destination ... all we care about is the value which the MUL will simultaneously place in the 32bit “Math Register” ... and for those who aren’t familiar with the DDV, this tip might help get you started ... many people are confused when they see only one source (32767 in our example) being specified in the DDV ... the fact is that the DDV’s single “Source” entry specifies “thenumberwe’redividingBY” (in other words, the “divisor”) ... we don’t have to specify “thenumberthat’sbeingdivided” (in other words the “dividend”) because the DDV only (and always) divides just ONE thing – and that one thing is always the value stored in the 32bit “Math Register” (words S:14 and S:13) ... hint: that’s why the value stored in N7:0 by the MUL step is a “dummy” value ... we weren’t planning to use that value later anyway ... what we really wanted was just the value simultaneously stored by the MUL in the 32bit “Math Register” ... but since every MUL must have a valid “Destination” entry, we just used N7:0 as a temporary “dummy” placeholder ... then in the very next step, we overwrote the “dummy” value in N7:0 with the results of the DDV operation ... at this point N7:0 can no longer be considered a “dummy” ... now (at least until the next processor scan comes along) N7:0 holds the scaled value that we’ve been working for ...
__________________

May 23rd, 2005, 08:00 AM  #24 
Lifetime Supporting Member

now we’ll go a little bit deeper into this “Standard Math” approach to scaling ... and this example will have a little more meat on its bones ... specifically, we’ll have an “offset” for our raw input data range – and another “offset” for our scaled values range ... this is exactly the same example that we worked through “longhand” for Figure 8 ... remember all of the hoops that our crusty oldtimer had to jump through to avoid using “y=mx+b”? ... well, the hoops are back ... and remember (or go back and check) that one of those hoopjumping steps resulted in a decimal number (0.370031281) ... that’s an “issue” ... because if we’re working with an SLC5/01 system, we simply don’t have anywhere in the processor’s memory to store such a floating point value ... and so our “work around” will be the same “reversetheorderofoperations” trick that we used for the math in our last example ... specifically, we’ll multiply first and then we’ll divide  rather than the other way around ... the two things that we really have to watch are those pesky offsets ...
first of all, notice that “m/Slope/Rate” in this figure is shown as a fraction (180/13107) and NOT as the equivalent decimal number (0.01373312) as we did in Figure 8 ... that’s because in this example, we’re working with an SLC5/01 which doesn’t have the SCL instruction available ... so not only do we not have floating point capability – but now we don’t even have access to our SCL “work around” either ... but we can still convert raw input data values into their corresponding scaled values ... we just have to use the right order of operations for our math steps ... and those steps are outlined for us at the bottom of Figure 15 ... and the program will be shown later in Figure 16 ... first we’ll take our input from the field (8127) and subtract the offset of the raw input data values (3277) ... this gives us a temporary value (4850) which we’ll store at N7:1 ... next we’ll multiply by the span of the scaled values (180) ... that will give us an intermediate value (873000) which we’ll TRY to store at a “dummy” location N7:1 ... but an integer location like N7:1 can only hold a maximum value of 32767 ... so the processor stuffs the maximum value (32767) into N7:1 ... and sets the “Math Overflow” bit (S:5/0) to let us know that “something went wrong” with a math step ... and (most important) the processor simultaneously stores the full results of the multiplication step (873000) in the 32bit “Math Register” at S:14 and S:13 ... next we’ll do a DDV (Double Divide) operation ... this will take the value stored in the 32bit “Math Register” and divide it by the span of our raw input data values (13107) ... the result (67) is stored at N7:1 ... finally, we add the offset of our scaled values (32) to the results stored at N7:1 (67) ... and that gives us our final answer (99) as degrees F stored at N7:1 ... and that’s as close to 98.6 degrees as we can get with this particular system ... quick summary: scaling for the SLC5/01 processor with no floating point ... and no SCL workaround ... just “Standard Math” ...
__________________

May 23rd, 2005, 08:02 AM  #25 
Lifetime Supporting Member

Figure 16 shows a ladder logic program which will perform the scaling conversion that we just discussed ...
and as I mentioned earlier, programs like this one often need some type of “limiting” arrangement to keep the input values from getting out of hand ... one good programming habit to get into is to check the operation of your math functions by feeding in the extreme limits of what the input values might possibly be ... and don’t forget to check with extreme values of negative numbers too ...
__________________

May 23rd, 2005, 08:04 AM  #26 
Lifetime Supporting Member

next we’ll take a look at a technique that often comes in handy when working with the SCL instruction ... in some cases, the ranges of values involved in a scaling operation exceed the capabilities of the SCL ... for a preview example: consider a situation where the value of “m\Slope\Rate” is 2.4997 ... now suppose that the input to the SCL is greater than 13108 ... in that case, the SCL would generate an internal value of something greater than 32767 ... oops! ... greater than 32767 is not allowed and so a “Math Overflow” bit S:5/0 will be set ... and if it’s not turned off again by the end of the scan, then the processor will fault ... and even if it IS turned off to prevent a fault condition, the math might not be “quite right” because the actual value could not be accurately stored ... in some applications, math which is not “quite right” can be a very bad thing ... you need to keep your eye on things like this ...
the top of Figure 17 shows a situation where a 4 to 20 mA analog input signal is being used to control a 0 to 10 VDC analog output module ... if you solve this by using a calculator, you should find that the example raw input data reading (8127) will be converted to a scaled value of 12124 ... well, not quite ... actually the SCL will give you a scaled value of 12123 for this example ... why? ... keep in mind that the values shown in Figure 17 are correct for working with the calculator ... but ... remember that the PLC handles this type of math using only integer numbers ... specifically, there is a certain amount of inconsistency to be expected due to “round off” issues ... in other words, we can accurately calculate “m/Slope/Rate” to be 2.499732967 as shown in the figure ... but when you use that value for the SCL instruction’s Rate entry, the closest that you can come to the calculator’s number is 2.4997 ... so the PLC loses a little bit of accuracy ... likewise ... we can accurately calculate “b/Offset/Intercept” to be ‑8191.624933 as shown in the figure ... but when you type that value into the SCL instruction’s Offset entry, the closest that you can come to the calculator’s number is ‑8192 ... so the PLC loses a little bit more accuracy ... so don’t be surprised to see minor inconsistencies between what your TI36X calculator says and what the PLC actually produces ... again, there are differences between the ways that the two devices handle “round off” issues ... but those types of issues are usually minor “nickeldime” stuff that won’t significantly affect the operation of your system ... but this next one is a major issue ... suppose that you’re the programmer who’s setting up the scaling shown at the top of Figure 17 ... you’ve decided to use an SCL for this program ... you’ve calculated the value for “m/Slope/Rate” (2.499732967) and cranked it into the SCL as a Rate entry of 24997 ... and that’s fine because it’s as close as we can get with the system we’re working with ... you’ve also calculated the value for “b/Offset/Intercept” (‑8191.624933) and cranked it into the SCL as an Offset entry of ‑8192 ... and that’s ok too because it’s as close as we can get with the system we’re working with ... so now you’re ready to check things out ... you dial in an input signal of about 9.92 mA ... the raw input data reading at I:7.1 goes up to 8127 ... the TI36X calculator says that we should expect our SCP to convert this to a scaled value of 12124 ... we see 12123 at O:8.1 ... we’re just one point off ... not too bad ... we knew we’d have a little bit of inconsistency due to “round off” ... so no problem ... you keep cranking the input current up littlebylittle and keep checking the scaled values – and the resulting output voltage ... everything is working fine ... you’re finally up to 13108 for your raw input data reading ... the calculator tells you to expect a scaled value of 24575 ... the SCP gives you an actual scaled value of 24575 ... that ain’t bad at all ... and the output module’s voltage is tracking right along ... let’s go one more tiny ittybitty step up ... you finally reach 13109 for your raw input data reading ... the calculator has told you to expect a scaled value of 24577 ... BUT ... the SCP goes nuts and gives you an actual scaled value of 32767 ... WIDE OPEN! ... all of a sudden you notice that the analog output module is cranking out a wide open value of 10 VDC ... glad we didn’t have this thing wired up as the speed control signal of a motor drive just yet ... and if you didn’t have that “unlatch” rung for S:5/0 at the end of ladder File #2, then the processor would have faulted ... but come to think of it, maybe a “shutdowneverythingfault” would have been a better thing that suddenly driving an output signal wide open ... we’ll have to think about that later on ... but back to our nutty signal problem ... this is NOT a simple “round off” issue ... and there’s nothing wrong with your math solution either ... the problem lies in the PLC’s method of handling its internal calculations as integer values ... let’s nail the problem down so that we’ll know what to look for from now on ... and then we’ll finish up for today with a practical way to fix it ... here’s the playbyplay ... consider what the SCP was doing when you had the raw input data simmering along at a reading of 13108 ... each time the SCP was executed, it took the “Rate” entry (24997) and divided it by 10000 and got an internal result of 2.4997 ... so far so good ... next it multiplied that internal number (2.4997) times the “Source” value from I:7.1 (13108) and got a result of 32766 ... still chugging along just fine ... next the faithful SCP added the “Offset” value (‑8192) to the previous result (32766) and came up with a result of 24574 ... close enough to the 24575 that the calculator told you to expect ... now consider what the SCP was doing when you finally cranked the raw input data signal up just one point higher to a new reading of 13109 ... the very next time that the SCP was executed, it took the “Rate” entry (24997) and divided it by 10000 and got an internal result of 2.4997 ... still ok ... next it multiplied that number (2.4997) times the “Source” value from I:7.1 (13109) and got a result of 32769 ... oops! you just broke the bank ... the integertype math of the SCP can’t store a number bigger than 32767 ... so it does the best it can (bless its little heart) and stores the maximum (32767) and turns on the “Math Overflow” bit (S:5/0) to tell you that something went wrong with the math somewhere along the way ... and that’s about it ... once that internal overflow had been generated, the SCP didn’t even try to add in the “Offset” value (8192) which would have brought us back within range with a final scaled result of 24575 ... so the sad story is, that even though it’s been set up “right”, this particular SCP will “hit the wall” when its raw input data reading comes in at 13109 or anything above ... from there on up, the scaled value just runs wide open at 32767 ... rats! ... ok ... so now how do we fix this type of scaling problem? ... take a look at the chart at the bottom of Figure 17 ... here we’ve “shifted” the entire raw input data range to the left on the chart ... basically we’ve subtracted the input range’s minimum value (3277) from the minimum end (32773277=0) ... and from the maximum end (163843277=13107) ... and from the sample raw input data signal (81273277=4850) ... now notice that all of this “shifting” didn’t affect the value of “m/Slope/Rate” at all ... but the “b/Offset/Intercept” value is now a nice round even (and easy to deal with) 0 ... and even after we’ve “shifted” things around, our 9.92 mA sample input reading still converts to the same 12124 (or 12123 “rounded off”) corresponding scaled value ... so now what about that “breaks the bank” raw input signal of 13109? ... well look at the chart ... as long as the field signal doesn’t exceed its 20 mA maximum, then our sensitive SCP won’t ever see another raw input signal above 13107 ... and if you want some good advice, some systems should have this type of input signal “clamped” between a suitable maximum and a suitable minimum ... and you should consider programming suitable alarms to let someone know if the signals ever try to get out of range ...
__________________

May 23rd, 2005, 08:07 AM  #27 
Lifetime Supporting Member

Figure 18 shows one common approach to programming the “shifted” xaxis which we just discussed ...
and again, remember that this demonstrates a barebones minimum ... many systems require that the input signals be “clamped” and also possibly “alarmed” to insure safe, reliable operation ... in closing, both the SLC500 Instruction Set Reference Manual and the SLC500 Analog I/O Modules User Manual have several examples about this subject that you might find helpful ... just be aware that there are MANY typographical errors in the “scaling” sections of both of these official books ... and there are also a few places where unconventional “rounding off” can cause some confusion ... if you try working through these samples and have any trouble getting the numbers to “workoutright” then post your specific questions and I’m sure someone with a TI36X calculator will be able to help you out ...
__________________

May 23rd, 2005, 08:12 AM  #28  
Lifetime Supporting Member

Greetings Phil Buchanan,
Quote:
you’re quite welcome ... actually I’ve been meaning to tackle this particular subject for about a year or two ... thanks for providing the incentive to get it done ... and enough detail about your process to make the examples easier to set up ... Quote:
it’s been included in all of mine for several years now ... once in awhile I think about dropping it – but the companies that we work for always say that this is one of the subjects where their employees need the most help ... as I said in the beginning, you’re certainly not alone in needing this material ... Quote:
I’m glad I was able to help ... and since you didn’t mention SLC5/01 systems and “standard math” functions in your original requests, I put all of my focus on the SCL instruction ... but now in the last few posts above, I’ve added some more detail that I think you might find helpful ... Greetings ToddM, Quote:
if there is enough interest, I’ll be glad to turn this into a downloadable PDF ... I’ll keep my eye on this thread and see how many people would like a copy ... just in case I don’t get it done by Wednesday, it will be sometime next week before I’ll be able to get around to it ... I’ve got some vacation time coming up later this week ... even if no one else asks for a copy, I’ll still put together a PDF in the next week or two, but I probably won’t go to the trouble of posting it ... but I’ll send you a copy somehow or other ... Quote:
that MIGHT happen someday ... but probably no time soon ... the biggest issue is time ... the material in this particular thread usually only takes me about 15 minutes to cover in class ... but it took me many many hours to draw the figures and to write the text ... I don’t want to even think about how much time it would take to publish a full 40hour weeklong course ... but if someday (God forbid) I can’t teach on my feet anymore, then maybe I’ll start writing a book ... you gotta do what you gotta do ... Quote:
thank you for the kind compliment ... basically it’s the same approach that I’ve been using for years in the classroom  so at least I didn’t have to reinvent this particular wheel ... and you’re quite welcome ...
__________________


May 23rd, 2005, 09:23 AM  #29 
Member

On a cheap calculator Subtract the Max & Min of each range (Input=32767  0 Output=30000). Divide the Otuput difference By The Input difference(3000/32767) and get the slope (0.091555528428).
But thanks for the detailed explaination, it is very useful. 
May 23rd, 2005, 09:35 AM  #30 
Lifetime Supporting Member

Ron,
Thanks again for for this wealth of information. I have often been frustrated with the "examples" given in AllenBradleys' manuals. They are not very helpful, especially if you are trying to understand the basics of scaling an input. I think it would be good if everyone could understand what is happening "under the hood" of an SCP instruction even if they don't ever use a 5/01 or 5/02 processor. And, by the way, I have experienced firsthand the faulting of a processor using math instructions. I was trying to practice online on a 5/05 processor we have at our facility. Fortunately it was not running anything critical. Oh, and I would definitely be interested in a PDF file of this info. 
Bookmarks 
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)  
Thread Tools  
Display Modes  

