90-30 change analog signal to actual values

[FuLcRuM 0]

Hey guy's got another question for you. This is on the same system as my last question (331 CPU). We have 5 PH meters that we are sending a 4-20 milli amp signal to an analog card in the PLC, it's reading an INT number between 0 and 33,000 for a PH reading between 0.00 and 14.00. Using the Panelview I'm able to convert that signal to the actual value that the meter is displaying (divide by 2300). The problem I ran into is that for logging on the PV It won't let me modify or convert the data so I just get the raw numbers (0-33,000), which is not very helpful. I tried adding some logic in the PLC to do the conversion but ran into some problems, I took the analog input, did a MOV_INT to get into a %R then did a DIV_INT (2300) to another %R that I then read with the PV, problem is it won't display anything after the decimal, so instead of getting a PH of 6.44 I just get 6. Closest I could get is to divide by 23 to get 644 and log that, but id really like to get the correct output. I suspect this is another issue with using an old CPU (331) vs a newer one. I see some other options in Proficy (DIV_REAL) that generate errors that my CPU doesn't support them that are probably the fix for this. Any suggestions or other work arounds to get a good PH signal?

[RussB 22]

Your suspicions are correct, the 644 number is the best you will get in the CPU331, the CPU350 and above have Floating point capability. An alternative would be to parse the data into two INTs, putting the 6 in one and the 44 in another, but I don't know how that would help in your log. In the PV, can you use a script to put the "6.44" value into an internal variable, then log it instead of the PLC value? You could always upgrade the PV to a nice new QuickPanel View. :)

[Steve Bailey 118]

Your basic problem is that the CPU331 is limited to integer arithmetic. You would need a CPU model 350 or higher for floating point arithmetic. An upgrade of that CPU's firmware won't help either. Your approach leaves you with two implied decimal places in that the value 644 actually represents 6.44. That's about the best you can hope for with that CPU. When you divide by 23, you also lose about two thirds of the analog module's resolution. That's because the %AI value will actually change in steps of 8 counts so you get the same result for three consecutive increments in the %AI signal. If your HMI can do it, let it convert the integer %AI value to a floating point value and do the arithmetic there.

[FuLcRuM 0]

Didn't think about converting it to internal on the PV, that may work. The PV is new, only reason it was chosen is because we want a spare for another piece of equipment that has a similar setup. This new system is designed to run without the screen if needed, the other machine requires it to run so we wanted a backup.

[Mike Lamond 1]

In the CPU331, integer math includes double integer functions but not integer<->double integer conversions. Using that instead of floating point math gives you an integer result with a fixed decimal place with a bit of work. The raw and scaled ranges are limited to positive integers without some additional programming. This is because the sign bit is in the upper word of double integers and not seen by regular integer functions. Subtract the raw zero (typically 0 for 4-20mA input or 6400 for a 0-20mA input range) from the raw input. If the result is negative, set the result to zero. Move the previous result to the low DINT register (%R1) and zero to the high DINT register (%R2). Use MUL_DINT to multiply the previous result (%R1) by the scaled range (ex. 1400 for 0.00 to 14.00) and store the result (%R3). Use DIV_DINT to divide the multiply result by the raw range (typically 32000 for 4-20mA or 25600 for 0-20mA analog inputs) and store the result (%R5). Use ADD_INT to add the zero range scaled value to the low register of the divide result and store this result in the scaled value register. You'll be working with implied decimal places in the PLC and the HMI will have to scale these, but that's far superior to using raw ranges. Certainly the next person who works on the system will not be cursing about the amateur hack job delivered by the programmer, the machine builder and everyone else involved in the delivery of an expensive, critical piece of biotech equipment. Since then the client has replaced all of these machines. By the way, are you sure the analog input range is 0-33000 and not 0-32000? 32000 is the usual upper range count for GE analog I/O. Mike