Issue with rounding. [SOLVED]

I have a modbus read node which communicates a PLC at 20 ms polling rate, and returns the status of a memory address (true or false). I have set up a flow which calculates the status change between false and true (through a RBE filter node) and a message counter counts the number of messages and resets every minute through internal clock within the message counter, the output of the message counter is fed into a function which divides the result by 2 (since one false+ one true = 1 count) and rounds off to next integer if it is an odd number.
so far so good.
Here is my issue. If the number of messages (true+false put together) is even, i don't have any problem, but if it happens to be odd (the object being counted passes under the sensor, triggering it, and before the sensor is deactivated, the minute counter reaches 00 seconds, resetting it), then it rounds off to next integer in the process increasing one count extra compared to physical count.

(for example
false+true+false+true = 4/2 = 2)
false+true+false+true+false = 5/2 = 2.5 = 3)

the count varies with physical count and it is highly random depending upon at the stroke of 00 in internal clock , the total number of message happens to be odd or even.

in the below picture we can see,
at 5:03 it is 12, so will result in 6, (equal to physical count)
at 5:04 it is 10, so will result in 5, (equal to physical count)
at 5:05 it is 10, so will result in 5, (equal to physical count)
at 5:06 however, it is 11, so will result in 6, (one higher than physical count)
this over an hour or a day, accumulates and gives me wrong count.

how do i tackle this ?

I would like to move the last message before the stroke of 00 to next minute if it happens to be odd, else do nothing.

Wouldn't it be easier simply to count the true values?

The modbus read node reads the memory address every 20 ms and checks the status and returns the status, so it may return many 'true' status for one single physical count, (the 'sensor ON' status may last upto say 600 ms. so it returns 600/20 = 30 true values before changing over to FALSE. hence the RBE filter node to see only the changes from true to false.

if it were possible to read the event of TRUE or FALSE when it happens in PLC directly, what you said might be possible. but the modbus read node only can be set to read at specific intervals of time and not at an event.
I am sorry if i could not explain it much clearer

Count the true values after the RBE node. Then you should get one for each item.

Now Why didn't i think of that :thinking: I am actually counting after RBE node only, but was counting both True and False, now i tried counting only TRUE as you suggested with a switch node, and compared with my old flow. It does the trick,

in this image top debug node is new flow with a Switch node to count only true
and below debug node is my old flow. the results are for previous minute

the top message counter is showing 1 ( only true) and below is showing 2 (true + false) for the current minute

image

sorry, i could not get earlier what you said, i believe you were also mentioning the same,

thanks Both

Would it perhaps be better to keep a running total in the PLC? Then you would need to keep polling so fast. Also it would not lose items if node-red were restarted.

I need to talk to my PLC programmer, how to do that. would i still be able to get per minute count ? I am actually eventually writing this to a database (every minute count from 20 machines)

Poll it every minute and subtract the previous value. If the counter in the PLC wraps round then you can cope with that easily enough in node-red.
Or if they can give you a counter that increments for each item, but you can subtract a value from it via modbus then you could read it once a minute, to get the count since you last polled, then you tell it to subtract that number from the current count (you can't just reset it in case the count has gone up before the reset gets there), and the next time you poll it it will have the count since you last polled.
There may be even better ways, I don't know what facilities modern PLCs have for this sort of thing. There has to be a better way than polling 500 times/second.

and i have kept my polling rate at 20ms, since there are machines which run at 300-400 bpm. some are as slow as 6 bpm. i would love to decrease the polling rate if possible, but in the current setup any higher polling rate, and i miss the count on faster machines

Believe me, I tried very hard convincing my PLC programmer to give me a solution from PLC end, but since my flow was giving result (with the now solved problem of some random increase in 1 count once in some few minutes) i did not pursue much. now you have given me some basic idea of how to do it. I shall reopen the case with him. Thanks again.!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.