Fast read data from ValueStream/Stream if and only if are written quickly in ValueStream/Stream

[dbologna]

Hello everybody,
I need to decrease the writing times within ValueStream and Stream. To do this just lower the values of the 'ThingworxPersistenceProvider: Rate stream queue is checked (milliseconds)' parameters for 'Stream Processing' and 'Value Stream Processing' (by changing the values in the platform-settings.json file) ? Might it be necessary to change other parameters for 'Stream Processing' and 'Value Stream Processing' ?
My goal is to be able to read the value stored in the ValueStream or Stream as soon as possible (especially by the service executed by the subscription on the DATA CHANGE event of the stored value).
Can anyone give me some suggestions?
P.S. I'm using Thingworx version 8.5.18

[bchaudhary]

Hello @dbologna ,

You may refer the article for tuning the valuestream:

https://www.ptc.com/en/support/article/cs240607

Let me know if it doesn't work for you.

Regards

Bhawna

[VladimirRosu]

Why would you need to access the value stored in the Stream through the same service executed by the Data Change event?

In that service you already have access to the Last and Current Values. I assume there's something else needed here - feel free to describe the use-case in more detail.

Note that even if you tweak the Stream/Value Stream parameters and reduce the rate stream queue is checked, to let's say 2 ms from the default of 5, there might be situations (eg: lots of properties incoming very fast) when this pattern will probably fail.

Streams and Value Streams were designed for fast data ingestion and for this you need all the time a queuing mechanism.

[dbologna]

The problem is as follows:
I have a number N of Thing TRIGGERS that have in the property 'formulaText' mathematical formulas that return a boolean value. Each formula is defined using the combination of other thing properties as operands. The properties are written into the formula as follows "<name_thing>:<name_property>". The value preceding the ':' character specifies the name of the thing, the value following the ':' character specifies the name of the property. Whenever one of the properties used as an operand changes value all formulas containing it as an operand must be calculated. If the formula of a calculated TRIGGER thing returns the value defined in the 'formual_result' property of the thing (possible values [true,false]) the thing must perform services. The frequency with property values change is on the order of milliseconds.
Example:
Thing A owns property VAL1 (NUMBER) which comes from kepware (via a Bind with a PLC variable)
Thing B possesses property VAL2 (NUMBER) that arrives from kepware (via a Bind with a variable of a PLC). Thing TRIGGER T1 contains the formula (A.VAL1 > 10) AND (A.VAL1 < B.VAL2) AND ( A.VAL1 != B.VAL2).
Suppose we have the following sequence of data from kepware.
event instant VAL1 VAL2 formula Result
t0 10 15 false
t1 14 15 true
t3 14 14 false
t4 14 18 true
if t(x+1) - tx < 100ms how can I be sure that I am using the correct values in the formula calculation. The idea is to get the values of the VAL1 and VAL2 properties from the ValueStreams of Thing A and B using the instant of the event (in condition <=, the smallest near or equal) as the key. In order for the values to be taken from the db, it is necessary to wait at least a time >= 5 sec
(time to handle the Value Stream thing). Waiting 5 sec is a time that is not good. How can I calculate formulas with temporarily correct data without relying on valueStreams ?

[VladimirRosu]

Hi @dbologna,

(trying to understand better the scenario) Are you expecting that both their timestamps will be equal when being changed? Eg: when A.VAL1 has a new value with timestamp t0, you'll have B.VAL2 with the exact timestamp t0?

What would you expect to happen if A.VAL1 timestamp <> B.VAL2 timestamp?

Reason I'm asking is the following:

-the eventTime is not guaranteed to be equal to the property timestamp (eg: I have property timestamp 20.09.2022, I updatePropertyValues at 14.02.2023 with property timestamp 21.09.2023)

-depending on the reading mode, the PLC properties are also not guaranteed to happen at that exact same time. I think you might have a way to set the platform to have readings at the same ms, just did not dig in too deep. With my question above I try to understand what exactly happens in reality.

I think I understand what you are trying to do, but I need to refine my understanding in the real context, of properties arriving with different timestamps.

As a last note, if you don't use the ValueStream, you can always check the property timestamp in the formula, in beginning to see if you can execute safely the formula (very rough idea, just crossed my mind now)