Hard Meter Number

clowens · Mar 22, 2021

drbitboy said:
I wonder if storing the operator entry as a string would work, padded out to the left with zeros.

That way no digits are lost, and the value can be recovered at any point downstream.

Does the plc ever make any calculations with the value?

Storing them as strings and transferring that string to the PLC was one of the thoughts I had. I do some simple arithmetic in the PLC with the numbers to calculate the indicated volume for each meter, then return the value to WW

Steve Bailey is correct that the operators are transcribing a number, so I don't think incrementing counters would be helpful here.

I have RSLogix5000 v16.04.00(CPR 9).

drbitboy · Mar 22, 2021

clowens said:
...I do some simple arithmetic in the PLC with the numbers to calculate the indicated volume for each meter, then return the value to WW [...] I have RSLogix5000 v16.04.00(CPR 9).

I don't think LREALs are a available in v16. So if that arithmetic in the PLC is not using DINTs*, then I assume it is using REALs, and the lost precision in the transfer from WW is irrelevant: REALs** will always round to the nearest 6th/7th significant digit.

* 32 binary digits; 9+ decimal digit** 24 binary digits; 6-7 decimal digits

baref00t25 · Mar 23, 2021

I'd recommend using two DINT (upper and lower) if it doesn't support LINT's. I don't like using REAL's for accumulation due to the rounding errors. Plus DINT's automatically handle roll overs which can make some logic easier.

OkiePC · Mar 23, 2021

baref00t25 said:
I'd recommend using two DINT (upper and lower) if it doesn't support LINT's. I don't like using REAL's for accumulation due to the rounding errors. Plus DINT's automatically handle roll overs which can make some logic easier.

I agree with this. If the system needs to manipulate the value based on pulses or something, then it is usually not too much trouble to deal with the cascading DINTs in PLC code. Getting the SCADA entry into those two DINTs might be pretty easy with some sort of scripting to take a text entry field, split it into two character strings, covert them to memory DINTs, then write them to the two PLC DINTs. I have done things like that with Ignition and with Crimson, but not wonderware.

I have done something similar with mechanical water flowmeters which provide a pulse to the PLC, so the user can make a correction with an HMI entry if, for example, they lose power and manually open valves causing the PLC to miss pulses. But in my case, the register rolls over at 1 million making it all fit nicely into a single DINT in the PLC.

clowens · Mar 23, 2021

I don"t use pulses, it's just a number the operators are transcribing from a field reading. I'm not sure how I'd go about splitting the number for use with 2 DINTs, let alone having it do the subtraction for the totals. Any ideas?

OkiePC · Mar 23, 2021

Someone good with Wonderware scripting can probably interpret this pseudo-code correctly, but something like this:

Code:

//On Entry Complete:
//int R;
R := Len(Entry);	//Entry is a string memory tag edited by the operator.  R is the length (number of characters)
L := R - 6;		//L is the number of characters for the left half      
MSW := "0";		//For now, we'll clear the MSW string in case the value doesn't require it.
if (R <=6) LSW := Entry;	//If the string fits, stuff it all in.
else LSW := Right(Entry,6);	//otherwise trim it to 6 characters
if (L >= 1) MSW := Left (Entry, R);	//If the MSW is needed, assign it to the leftmost characters required

MSWDint := TextToInt(MSW, 10);	//convert those strings to integers base 10
LSWDint := TextToInt(LSW, 10);

That snippet works in Crimson...I tested it in the emulator to ensure I had some of the details right. It splits the text into two strings with the LSW string being limited to 6 characters. The last two lines convert those strings into Integers with a radix of 10 (normal base 10 decimal numbers). I didn't tie them to PLC addresses since I don't have one fired up and ready on my test rack at the moment.

I didn't try to simplify/optimize this, just wanted to make it work first...easier to debug in a lengthy form.

Once you have those values in the PLC, doing math with them should be relatively straightforward except for having to deal with the sign bit. I would need to see an example of what you need to do in the PLC to advise further.

drbitboy · Mar 23, 2021

OkiePC said:
Someone good with Wonderware scripting can probably interpret this pseudo-code correctly, but something like this:

Code:

...

Sweet.

If @clowens is comfortable with WW scripting, do this. If not, pass a string to the PLC and do this in the PLC, because the PLC is working with two DINTs either way, so it could just as easily do all the work.

Unless the PLC is sending either an LREAL or an LINT back to WW, I still say it macht nichts, but I don't know much about the process.

clowens · May 25, 2021

clowens said:
I've been beating my head against this problem intermittently for a while now.

We have 3 meter with hard mechanical counters on the top that go up to 99,999,999.99 and then roll over to 0. We only use them as a verification/check against our flow computer for the indicated volume.

I'm using Wonderware v10.6 and RSLogix5000.

Currently they're typing the numbers into an analog entry on Wonderware and stored and processed as real (float) in the PLC. The problem is the nature of how the floats are stored means they're not accurate when you get up to the very large numbers. RSLogix is also rounding the decimals, sometimes to funky numbers.

I've tried using integers, but I can't get the resolution to come in, even through formatting.

I'm sure there has to be a solution to this, and reducing the resolution might be it, but I'd rather keep the resolution if possible.

I've gotten it figured out. I transfer a string into the plc from Wonderware and used "Find" to look for the decimal place and return the place in the string. Then used "Delete" to delete the decimal point at the Found string position. and convert from String to DINT.

No more rounding errors from processing real number.

Feed back to Wonderware using scaled real numbers to give the tenths decimal resolution, can't have the hundredths due to the limitation of a DINT, but there's no rounding errors going back to the Wonderware from the PLC.

Corsair · May 26, 2021

Reals

This may be off-topic - and I know very little about Wonderware - but storing counts in reals is always a challenge. The biggest problem that I know of was the Patriot missile miss that resulted in 28 casualties. I think it was counting time ticks into a real instead of into some sort of larger integer variable.

It seems that people tend to be too quick into thinking that all numeric problems are solved by throwing it into a real with enough bits. That's not a substitute for understanding how data is stored and thoughtful consideration of the proper data type for what you are doing. The French rocket explosion was another unfortunate spectacular example of not thinking through issues with data types. Blew up 37 seconds after launch because a real value over 32767 was trying to fit into a 16-bit signed integer register.

It seems that this forum generally has good advice on data type issues.

drbitboy · May 26, 2021

clowens said:
I've gotten it figured out. ...

so the string approach worked, cool beans. thanks for the followup.

AustralIan · May 26, 2021

Throw a Cognex at it and update in real time. Operators that can accurately type a 10 digit number every day are few and far between, you need to get them doing some real work.

clowens · May 26, 2021

I'd have a hard time justifying the cost for 3 10 digit numbers every 4-5 days.

The sentiment is shared though.

Hard Meter Number

clowens

Member

drbitboy

Lifetime Supporting Member

baref00t25

Member

OkiePC

Lifetime Supporting Member

clowens

Member

OkiePC

Lifetime Supporting Member

drbitboy

Lifetime Supporting Member

clowens

Member

Corsair

Lifetime Supporting Member

drbitboy

Lifetime Supporting Member

AustralIan

Member

clowens

Member

Similar Topics