Ignition totalizer for flow meter

Ignition
1

Due to PLC insufficient memory, I will have to totalize the flows on Ignition.

I found that I can use Hour Meter, but it’s insufficient for my purpose.

  1. Totalizing the flow starting on specific time of the day.
  2. Pause the totalizing if condition A is off, continue if condition A is On.
  3. Reset totalizer at specific time of the day, before resetting the totalizer, move the current totalizer value to previous totalizer value, meanwhile also add the current totalizer value to lifetime totalizer value.

The hour meter can achieve the first requirement easily, but it won’t pause by condition, it can only reset by condition.

Is there anyway to achieve the above requirements on Ignition?
Or I will have to write SQL to calculate them from the database, which could be last solution.

2

All this can be archived with 3 tags and scripts.

  1. Tag 1 [OPC], PLC value
  2. Tag 2 [Memory] for the totalizer
  3. Tag 3 [Memory] for t life time totalizer

In tag 1 use a value change Script:

if system.date.now() >= yourstarttimecondition:
     if conditionA:
          tag2path = '[provider]tag/path'
          currenttotalizer = system.tag.readBlocking([tag2path])[0].value
          system.tag.writeBlocking([tag2path], [currenttotalizer+currentValue.value])

Use ScheduledScripts and it should look like

tag2path = '[provider]tag/path'
totalizer = system.tag.readBlocking([tag2path])[0].value
tag3path = '[provider]another/tag/path'
system.tag.writeBlocking([tag3path],[totalizer])
#reset
system.tag.writeBlocking([tag2path],[0])
1 Like
3

In your second script, you can condense your tag writes to one call.

system.tag.writeBlocking([tag2path,tag3path],[0,totalizer])

It doesn’t make a huge difference for just two tags, particularly since this only runs once per day, but it might make a difference if there are going to be many totalizers all zeroing from this script.

2 Likes
4

The flow is a continuous process variable, for example 24m3/hr.
the delta increment of the flow totalizer will be the current flow/(elapsed time since last reading).
curTot = lastTot + PV/deltaTime
The script is triggered by value change, is there a way to capture the elapsed time since last value reading.

5

try:

delta = currentValue.timestamp-previousValue.timestamp
6

Can you explain a bit more on the currentValue and previousValue?

My understanding is that both values are from the same tag, for example, FIT0101.outPV
currentValue = FIT0101.outPV at current Scan,
previousValue = FIT0101.outPV at last Scan.

7

currentValue and previousValue are QualifiedValues with accesible methods like .value or .timestamp, and yes those are related to value changes.

Yes, that 's right.

8

is there a expression to get the timestamp of the value from the last scan?

9

Nop,
But I don’t either see the need to have an expression for that

10

Um, no.

curTot = lastTot + PV*deltaTime*unitConversion

1 Like
11

I am a bit confused.

At current scan, I can get the current value and current timestamp by using the tag properties. But unless I saved the last scan value to a memory tag, how do I get the the timestamp of the tag from the previous scan?

Please advise further.

12

If you use a tag change script, it is provided with the previous value. Except on tag startup. If using an expression tag, it isn’t available. If you must use an expression, I recommend using objectScript()'s state dictionary to capture it on tag startup and update as you go.

13

Not really, you will still have access to previousValues either you store it or not. The auxiliar tags are useful to perform the accumulation.

I see a problem here, if you're dealing with time variation that's actually an integrator.

1 Like
14

Thank you.

Just sorted it out with your help.
I built a data structure for it to be duplicated easily.

Just wondering, if there are 10 totalizers each project, running the same script every second, if there are 50 projects running at the same time, how is it going to affect the gateway performance.

15

Hard to say, it depends on server specs and scripting complexity. But naturally the performance should be fine, 500*3 tags is not actually that much.

Constantly check the performance page while in this implementation.

16

If I assume you are sending the tag values to the history database, you may be able to calculate the total by querying the database asking for the flowrate between both times. Since you are just taking values every x hours or minutes, you will end up with a number values reading1, flow rate… so on.
Because the period is constant between the 2 times you can do:
Total_volume = TimePeriod * ( flowrate1, flowrate2… flowrate_n)/number of items.
note: the longer the period between readings, the less accurate the total is, no matter how you do it.
Also, doing it this way you can store the total in a separate table being a calculated value, you would not have to do it again.
Thanks

17

True, but Involving a DB makes it “complicate”.
This probable is for Ignition Edge, and in that case I would avoid involving a db engine.

19

So there is not historical data being kept.
What is the user supposed to do with the Total-Flow calculated because if the gatway or the client workstation have a problem then you may lose the Total-Flow. This value should also be important for inventory calculations, so in my opinion the sensible thing to do is store it somewhere.

Best,
Francisco

20

The idea was to create a live totalizer. It is not efficient to ask the historian for the previous value every time a new value comes. Even worst for 500 history requests at ones.
Nothings stops you to enable history for a particular tag.