Limits on floating point Math

[LeonMötter]

I have been working on putting some pretty complicated math (at least complicated to me, some people may disagree)  in to a PLC (in my case it is a V560). I am running into some problems (i think) with the capacity of MF's. it looks like i am loosing precision (read the number of digits after the point) as the value increases. That is to be expected the only problem is i can not find how this is defined. If i know that i can hopefully adjust the formula's to stay within limits to keep the results as accurately as possible.

For some more  background information the math we are trying to do is calculating a model of the machine process in realtime, and then use the model to adjust machine. it is al lot of iterative math based on sensor input. we are talking about somewhere between 20 to math blocks that need to do about 500 to 1000 cycles to calculate the model. is is basically calculating a simulation and comparing that to the data. We have done some test with a small part and i am actually pretty surprised by the performance of the PLC. The problem is that somewhere we are losing precision in the calculations as described above and we are not sure where. if we know what te limits are we can (hopefully) adjust the program.

[AlexUT]

Probably I will surprize you by answer - 32-bit PLCs are not a right instrument to "to do about 500 to 1000 cycles to calculate the model" when yse 32-bit Float Point representation.

Precision will be lost.

You need a DSP for this.

Now you have to decide how to continue.

PLC can be used to manage machine, but you have to use other device for "to do about 500 to 1000 cycles to calculate the model".

May be other Forum members have some ideas.

 

[LeonMötter]

oh i am well aware that PLC's in general are not meant to be used in this way. In an earlier discussion in the company we discussed sending the data to a server/computer to do the calculations. That would have made the calculation part a lot simpler. Downside is that the machine is going to be depended of that server and the connection to it. A long time ago we have made the decision to not make any of our production machines depended of external computing. so we opted for the hard path.

That being said we already made great progress in programming and can actually achieve a pretty accurate model in a decent amount of time (the latest test we did a few 100 calculations in 20 seconds). The problem is that we don't really understand where the precision is lost. if we know that we can compensate for that. 

 

[Flex727]

Is there any possibility to use integers with implied decimal instead of floating point?

[LeonMötter]

In some cases yes, but most no. Most op the inputs to the math are integers. but after that it is a lot easier to stay in floats. The range we use is around 1X10E7 to 1x10E-8.  This has to do with the iterative process. we start with very large numbers and the more cycles that have been run the smaller the values get.

[Fernando Castro]

4 hours ago, LeonMötter said:

oh i am well aware that PLC's in general are not meant to be used in this way. In an earlier discussion in the company we discussed sending the data to a server/computer to do the calculations. That would have made the calculation part a lot simpler. Downside is that the machine is going to be depended of that server and the connection to it. A long time ago we have made the decision to not make any of our production machines depended of external computing. so we opted for the hard path.

That being said we already made great progress in programming and can actually achieve a pretty accurate model in a decent amount of time (the latest test we did a few 100 calculations in 20 seconds). The problem is that we don't really understand where the precision is lost. if we know that we can compensate for that. 

 

The precision is lost because its a 32-bit floating number... there is a formula on how the numbers are "encoded" you technically could use 2 32-bit operands to work with 64-bit floats but that will require to do all the math to "encode" and decode the numbers.

this site has some useful information about that: IEEE-754 Reference Material (cuny.edu) but you can google the formulas on how to operate on float 32 or float 64.

I don't really know your process but sure it should be a workaround instead of doing all with floating numbers.

I have seen some other approaches like storing all as integers and using a decimal position on a different operand or having an operand per "decimal place". In any case I agree with the collages that maybe the PLC or at least this PLC is not the best tool for the job. I am sure that there are 64bit ones.

[Flex727]

12 minutes ago, LeonMötter said:

The range we use is around 1X10E7 to 1x10E-8.

Seems like this is easily within the range of a 32-bit signed integer. It may be "easier" to work with floating point, but if they don't work then the harder path is necessary.

[Joe Tauser]

The answer to your question is a 32 bit floating point number in Unitronics has 7 digits of precision plus an exponent.   You're probably losing information when you slide up and down the exponent scale.

Joe T.

[Ausman]

10 hours ago, LeonMötter said:

discussed sending the data to a server/computer to do the calculations.

Not even a suitable miniPC placed immediately adjacent, which should be pretty bulletproof?  (If you can find one at present!)

-----------------------

Are  you using SDW4 in any of the calcs? 

-----------------------

Wondering if you could possibly do the "tailoring" in a number of steps, which would possibly reduce the remainder errors that I think you are getting.   Do the process to a given point, store that value, do the process again X times storing the result again, and then average all the values.  Then to do the next "range" to the next given point.  If the machine is super accurate then the results will likely always be the same and this won't help, but if it does variations then this method might "smooth out" some of the remainder errors.   The whole point would be to stop the compounding  of errors. 

----------------------

cheers, Aus

[LeonMötter]

14 hours ago, Flex727 said:

then the harder path is necessary.

I hope i can avoid that, but yes if we can't get it to work with the floats we are going to have to switch. 

14 hours ago, Joe Tauser said:

The answer to your question is a 32 bit floating point number in Unitronics has 7 digits of precision plus an exponent.

Yes that is what i wanted to know. We thought it was something like this when looking at the values through the online mode, but we where not sure if this was possibly a limit off the online mode itself.

 

8 hours ago, Ausman said:

Are  you using SDW4 in any of the calcs? 

No, but that is because all of the result calculations are in floats.

8 hours ago, Ausman said:

Not even a suitable miniPC placed immediately adjacent, which should be pretty bulletproof?  (If you can find one at present!)

Honestly i haven't considered this. i move that to plan C if we get stuck. 

As a positive note, yesterday we basically got the program working for 1 parameter of the model (we still need 3 more). granted this was with a small data set so this made it a little easier. but still a small victory. And me and my colleague were actually surprised how fast the calculations were done. in this test we did around 102 calculations in a program cycle and in around 50 cycles the calculation was finished.  so we still have hope we can pull this off.

[Flex727]

8 hours ago, LeonMötter said:

in this test we did around 102 calculations in a program cycle

What is your scan time (SI 0)?

[Ausman]

15 hours ago, LeonMötter said:

No, but that is because all of the result calculations are in floats.

I realise now it seemed a dumb question, but my thinking was wondering whether you had actually tried things not using floats all the time, which had been already been alluded to by others. 

Perhaps alternating back and forth b/n types during progress of the process might help.

I don't mind making my plcs do lots of "tweaking" maths, I call it fuzzy logic!  But in your case it seems that it's getting a bit too fuzzy at the end.

Good luck.

cheers, Aus

[LeonMötter]

16 hours ago, Flex727 said:

What is your scan time (SI 0)?

around 13/14 so not too bad. when the calculations are not running it is about 9/10. so there is a significant impact on the cycle time.

I also should have specified a little better what i meant with a single cycle. We still do only 1 calculation in each PLC cycle. but in our math program we have to do 2 calculations for each data point (so 51 data points gives 102 calculations). then this cycle repeats until the calculated error is within acceptable range. in the latest test this was around 50 cycles.

9 hours ago, Ausman said:

I realise now it seemed a dumb question

Not at all, it is almost inevitable that we are going to use it in the end. just to get everything optimized. The biggest reason we didn't started that way is because our test program is written in python. Because of the complexity of the math it is easier to just copy the formula's in to math blocks without converting everything. it also doesn't help that my colleague is a mathematician and not a PLC programmer. so getting him to understand what he can or can't do has been a lot of fun.

i hope that in the future that i can post some of program. i have to make sure that there isn't any sensitive information in it before i am allowed to do that. and probably add some more comments to make it somewhat understandable. 

what i can is that we are using this method:

https://en.wikipedia.org/wiki/Newton's_method 

[LeonMötter]

So a small update, we got everything we working as we want to (almost). it took a bit of fine tuning to get all the calculations in the right range so that precision isn't hurting us to much. There are still a few things to improve, first cleaning the nets. It is working but it is a bit of mess. 

We have a lot of this going on. but that should be easy to fix.

The number of PLC cycles we have to do to get an accurate model at the moment is (((2 * N) * 50) * 15) where N is the sample size for the model fit. the latest test we used 66 samples. so in this case i took 99000 cycles to finish the calculation. This took about 12,5 minutes. The next goal is getting this down to about 10 min. if we get below 10 minutes we can calculate a model faster then the cycle time of the machine. 

i also have to say it is kind of satisfying to start the calculation and watch it in the debugger. Just seeing all the numbers fly by and then stopping when a solution is found.

[Ausman]

8 hours ago, LeonMötter said:

it is kind of satisfying to start the calculation and watch it

Yes!  Some of my things constantly adjust ramping rate on a host of different controls, with all of them are trying to arrive at the same time on another control's figure, which is also tweaked by lots of it's own adjustments.   I have them in a watch.....to do just that!  It's just maths being worked out, nowhere near as complex as what you are doing, but still very absorbing to watch after doing all the brain-teasing involved.

cheers, Aus