# All Activity

1. Today
2. ## Update From Worksheet in Organizer

Hi, In the organiser, is there a way to do "update from worksheet" for all the images at a time(bulk/mass update) rather doing it one by one. Thanks in advance.
3. Last week
4. ## Count of total signals above a threshold value

Kareem, Do all of your temperature signals have the same threshold value? If so, we could possibly do some math to create 1/0 signals for each of your temperatures in formula and add them up giving you a total above threshold value. If each of the temperature signals has a different value, we could still potentially do it in formula, but it might be advantageous to use the value search functionality to create capsules at that point. -Sean
5. ## Alternative to SCALAR.INVALID

Jason, A little bit more context on what you are trying to accomplish would help me offer a better suggestion. From what i can gather, you are trying to splice a bunch of different values together, one value for each condition \$a through \$m. When none of these values are present you want the signal to be without data (i.e. invalid) is that correct? do the conditions \$a through \$m ever overlap? Does the calculation go on endlessly giving you the spinning wheel? or does it error out in some way? If you only try splicing together say the first 4 conditions (\$a through \$d) will the calculation finish loading? if a 0 value is OK when no other data is present, try replacing scalar.invalid with 0 and see if it works. Using your formula and non-overlapping conditions i was able to get this long splice chain to work by commenting out, then retyping the offending lines of code (in my case, \$d and \$f both error-ed out for no clear reason. In retyping them they were accepted and the formula completed.)

7. ## Track a batch as it moves through different unit operations in a batch process

Suppose I have a batch process with several unit operations and I want to create a single capsule for a batch as it moves through the process. This is useful for optimizing the cycle time of a batch process with several unit operations. It is relatively simple to define a batch for a single unit operation: value search to find when a tank level is >0, composite condition to join the start and end capsules from an event frame, or using capsule properties (https://www.seeq.org/index.php?/topic/314-join-capsules-by-matching-capsule-properties/). However, what if I want to track a batch as it moves through several unit operations? In the process below, I have three steps: feed makeup (lane 1), reaction (2), and filtration (3) - the batch of raw material moves from tank to tank for each step in the process. I have created a capsule for each unit operation step by using the level of each tank. Note how the capsules overlap: this makes it not possible to first join the feed makeup and reaction step, then join that condition to the filtration step. See image below: The solution to this is to create one condition for Feed Makeup joined to Reactor and another condition for Reactor joined to Filtration Tank, then to join those two conditions (Full Batch). From here I could track the cycle time of each step in the process.
8. ## Calculate the Offset Between Signal Peaks

Alternative Solution If you already have conditions with capsules that start (or end) at the peak max then you can use a Composite Condition followed by Signal from Condition. Here is how... 1. Use Composite Condition to join the two capsules. In this example the capsules start at the peak max so the join will be inclusive of A but not inclusive of B. 2. Use Signal from Condition to calculate the duration of the Peak-to-Peak capsules.
9. ## Relative (rolling) calculation window

Hi John, The following method can be used to calculate an hourly average and standard deviation over the lagging 24 hours. 1. Create a periodic condition 24 hours in length that begins every hour. Periodic conditions this specific cannot be done in the Periodic Condition wizard tool, but can be done in Formula using the following syntax: periods(24h, 1h) 2. Use signal from condition to calculate an hourly average over the last 24 hours. Make sure to select end as where you want to put the timestamp of the summary statistic. 3. Use a similar method with signal from condition to calculate an hourly standard deviation over the last 24 hours. 4. Use formula to calculate an upper limit for your temp signal equal to your 24 hr lagging average + X*standard deviation. In this example we chose + 3 SD, so the formula syntax is \$average + (3*\$standardDeviation) 5. Use formula to calculate a lower limit for your temp signal equal to your 24 hr lagging average - X*standard deviation. In this example we chose - 3 SD, so the formula syntax is \$average - (3*\$standardDeviation) 6. Use the Boundaries tool to transform your upper and lower limit signals into shaded boundaries.
10. ## Relative (rolling) calculation window

I've seen some discussions on creating boundaries using periodic conditions. But am interested in seeing if now() can help with creating a relative, rolling window for calculations. For example, I am trying to create boundaries for temperature signal A (TempA) based on a prediction model for TempA, +/- the standard deviation of the model. Ideally, the StdDev would be calculated continuously over the preceeding 24hrs, offset by 1hr (i.e. the standard deviation of the model between -25h and -1hr). Right now I've started with this: (\$p = prediction model for TempA) \$p.standarddeviation(capsule(now()-25h,now()-1h)) But that yields a constant. And I would like it to continuously calculate over that relative -25hr:-1hr window.
11. ## Join Capsules by Matching Capsule Properties

Use Case Background Batch operations may be characterized by two conditions. The first condition represents the start of the batch and the second condition contains the end of the batch. Each capsule has the batch ID as a capsule property. The goal is to make a single condition that represents the duration of the batch by joining the start and end conditions. Solution 1 - Simple Join If the batches are orderly and the end of one batch does not overlap with the start of the next batch, then using the Join logic in the Composite Condition tool is the easiest option. However, if the end of one batch overlaps with the start of another, then some batches may not be joined. In the screenshot below the third batch on June 6 is not joined. Solution 2 - Use Formula to join based on matching the batch ID capsule property By using a transform in Formula all the batches in this scenario can be joined. In addition the batch ID property is assigned to the new capsules. Here is the Formula used to do this... Variables Name Item Type \$startCond Start Condition Condition \$endCond End Condition Condition Formula //Define the max time into the future to look for the end capsule \$lookAheadTime = 2d //Resize the starting capsule to extend for the druation of the look ahead time \$startCond.move(0s,\$lookAheadTime) //Use a transfrom to take each start capsule and look for a matching end capsule and join by making a new capsule .transform( \$startCap -> capsule(\$startCap.getStart(), //Get the start key for the capsule //Filter the end condition based on BatchID //Find the specific capsule by in the filtered condition using toGroup(\$startCap).first() //We can look for the first capsule because we only expect to find one capsule in the condition //Get the end key for the capsule using .getEnd() \$endCond.filter(\$endCap -> \$endCap.getProperty('BatchID') == \$startCap.getProperty('BatchID')).toGroup(\$startCap).first().getEnd()) //Assign the property of the starting capsule to the new capsule .setProperty('BatchID', \$startCap.getProperty('BatchID')) , \$lookAheadTime)
12. ## Alternative to SCALAR.INVALID

Hi Seeq, One of my calculations in Seeq requires me to use SCALAR.INVALID.toSignal() and a long chain of splice() formula. For example: SCALAR.INVALID.toSignal() .splice(22.32.toSignal(),\$a) .splice(23.23.toSignal(),\$b) .splice(24.54.toSignal(),\$c) .splice(25.72.toSignal(),\$d) .splice(26.02.toSignal(),\$e) .splice(27.11.toSignal(),\$f) .splice(28.54.toSignal(),\$g) .splice(29.79.toSignal(),\$h) .splice(30.95.toSignal(),\$i) .splice(31.45.toSignal(),\$j) .splice(32.72.toSignal(),\$k) .splice(33.97.toSignal(),\$l) .splice(34.76.toSignal(),\$m) However, the calculation is not able to complete loading. Is there an alternative to replace SCALAR.INVALID? Any suggestions on how to improve this calculation?
13. Earlier
14. ## Count of total signals above a threshold value

Hello, I would like to come up with a clean method of showing me the count of signals are above a specific threshold over a specific period of time. Say I have 30 temperatures, and one dips below my threshold. I would like my counter to reflect "29", indicating that one signal has dipped. I know I can begin with a value search and count them on a scorecard, but I do not want to write out a value search on 30 signals!
15. ## Calculate the Offset Between Signal Peaks

Use Case Background In this Use case, we have 2 signals: Signal 1 and Signal 2. We'd like to use Seeq to calculate the offset (in time) of the peaks in the two signals. The following steps can be used to perform this calculation. Analysis Steps 1. Use the Value Search tool to create a condition for the peaks. 2. Use the Signal from Condition tool (twice) to calculate the maximum value of each signal during the Peaks condition. Be sure to place the timestamp of the statistic at the point of maximum value. 3. Finally, use the following syntax in Formula to calculate the offset between each set of peaks. The result of this Formula is a new time series signal with a sample reporting the offset for each pair of peaks.
16. ## Delaying or Shifting the Time of a Signal

As stated in the previous post, correlationOffset() can be a useful tool for identifying what the optimum delay value should be in order to obtain a maximum correlation between two variables. This function is quite helpful, but in general should be applied when you as the user recognize or suspect that two signals might be correlated. While it will generate a value for any two given signals, the value may not be meaningful if the two signals are not inherently related. Lets say we have a temperature sensor in a reactor. At some point downstream of this temperature measurement, we have a relative humidity sensor that is sensing the same volume of air, but due to the positioning of the two sensors, we are certain they are offset but measuring the same volume of air, but are unsure of the offset between the two. This would be an excellent application of correlation offset! Here we can see the temperature leads the RH signal and the two are definitely inversely correlated, however we don't know what the delay between the two signals is. The code used to determine the offset is: \$offset = \$relativeHumidity.correlationOffset((1/\$temperature), \$correlationDetectionPeriod.toGroup(capsule('2019-06')), -6h, 6h, 5min, 0.9) \$relativeHumidity.delay(\$offset) The correlationOffset function takes the following arguments \$signal.correlationOffset(\$GoalSignal, Group of Capsules to Calculate Correlation On, Min Offset, Max Offset, Grid Period, Min R^2). In the above code, we are determining the correlation offset between relative humidity and 1/temperature (because the two are inversely correlated) using the \$correlationDetectionPeriod condition during the month of June, with a minimum offset of -6 hours, a maximum offset of 6 hours, re-sampling the data to a 5 minute grid, and a minimum R^2 of 0.9 Implementing the code gives us: The new Shifted Relative Humidity signal in orange seems to track quite well with the temperature signal in green (when temperature is at a maximum, the relative humidity is at a minimum) when compared to the original relative humidity signal in purple. This analysis was done in Seeq version R21.042

Thanks!
18. ## Prevent Jira alerts when user posts comment

Hi Damon, Thank you for the feedback. We've updated your settings so you should no longer receive an email about your own response or comment. Regards, Connor W.
19. ## Prevent Jira alerts when user posts comment

Hi Damon, Thanks for the feedback. We will look into this. We agree, getting a email about your own response is not right. Regards, Jon Peterson
20. ## Prevent Jira alerts when user posts comment

When I post a comment directly in Jira, or when I reply to a support email, I then get an emails with the text of my comment in it. This is useless and annoying. When I see an email from Seeq I want it to be from Seeq, not from me.
21. ## Exporting to Excel (Capsule Summary Problem)

Hi all, I have created a workbench with three temperature signals (x, y, z) and I have added six value search conditions (x Hi, x Lo, y Hi, y Lo, z Hi, z Lo). A High and Low condition for each signal. This has created a list of 95 capsules for the six conditions. I am exporting the summary data to excel. The information tab contains a list of my 95 capsules. However, the Capsule Summary tab contains a list of 285 line items. I am seeing the information for all three signals against each capsule ID, rather than just the signal that capsules condition was configured against. I have tried only selecting one signal and its two conditions and exporting. But I still get all 95 capsules and 285 line items. Not sure if I am doing something incorrectly? I expected the Capsule Summary tab to list just the 95 capsules with the relevant stats? I would like to avoid having to create a workbench for each signal and its conditions. Is there another work around? Also the time stamps in the excel export appear as EST despite my profile and workbench being set to GMT? TIA
22. ## Identifying Patterns in Discrete Sequences of Events

Use case: A piece of equipment has a start-up sequence in which it goes through different discrete states sequentially before completing the sequence and reaching steady state. When the equipment is off, the state is 0. When the equipment enters the start-up sequence it cycles through states 1-6 in the pattern "1-2-3-4-5-6". A successful start-up sequence will have all 6 states in the pattern "1-2-3-4-5-6." If a disruption occurs at any point in the start-up sequence the state number will read as state 7, thus a failed start-up sequence could have the pattern "1-7", "1-2-7", 1-2-3-7", etc. This use case describes methods to identify only the successful start-up sequences. Approach 1: If the signal for the state is numeric (e.g. with discrete numeric values of 0-7) 1. Create a new signal that is the running delta of the STATENUMBER signal. Use Seeq Formula and syntax: \$statenumbersignal.runningDelta() 2. Create a new condition for all start-up sequences using value search for when the runningDelta signal just created is greater than zero. 3. Calculate the delta in your STATENUMBER signal over each start-up sequence. This value should always be equal to 6 or 7 as the sequence will either complete successfully (go to 6) or fail and end with a value of 7. Use the signal from condition tool to calculate this. 4. Create a new condition for when this delta in the STATENUMBER signal just created is equal to 6. This must be done in Seeq formula (there is a known issue in using value search for this operation) with the following syntax: \$deltaInSTATENUMBERsignal.valueSearch(isEqualTo(6)) Approach 2: If the signal for the state is a string that is easily convertible to a numeric signal. This example is a string with discrete values "STAGE0", "STAGE6", etc. 1. In Seeq formula, use the replace() function with the following syntax: \$StringSignalForStateNumber.replace('STATE','') 2. In a new Seeq Formula Window apply the toNumber() function to the signal created in step 1 with the following syntax: \$SignalFromStep1.toNumber() - this will create a numeric signal with discrete values of 0-7. Approach 3: If the signal for the state is a string value, not easily converted to a numeric signal or if you wish to proceed using the string signal. 1. Use Value Search to identify STATE6 2. Use Value Search to identify STATE7 3. Use Composite Condition (union operator) to create a combined condition "finalStateinSequence" for the final state in sequence, either STATE6 or STATE7. 4. Use formula to create a condition for all start-up sequences (successful and failed). Syntax: \$FinalStateInSequence.inverse().move(0,1h) This formula code is identifying all of the time when the final state in sequence condition is not true and extending those capsules by a short amount of time so that the final state value is contained within the "all start-up sequences" capsules. 5. Use Signal from Condition to identify the ending STATENUMBER value for each of the start-up sequences. 6. Identify your successful start-up sequences by doing a valueSearch in Formula to identify when the ending STATENUMBER is equal to STATE7. Formula syntax: \$endingSTATENUMBERsignal.valueSearch(isEqualTo("STATE7"))

24. ## Boundaries based on mode of operation

Use Case Background Commonly, engineers are interested in calculating limits on a signal based upon the average and standard deviation. Additionally, there may be different modes of operation during which the performance - and limits - is different. This post describes how to develop mode based boundaries for a process signal to identify deviations from the normal or expected behavior. Mode Conditions In this example, I am interested in calculating boundaries on a Compressor Power signal based upon the mode of operation in a Compressor Stage Signal. (Note: These signals are from Example>Cooling Tower 1> Area A of the Example data shipped with each Seeq installation.) The first step is to identify the 3 stages of operation (Off, Running 1 Compressor, Running 2 Compressors) by performing a Value Search on the Compressor Stage signal: Average Compressor Power using Formula Next, I can use the Formula tool to calculate an Average Compressor Power signal, using the following variables and syntax: Variables Name Item Type \$Series Compressor Power Signal \$High Compressor High Condition \$Low Compressor Low Condition \$Off Compressor Off Condition Formula // Identify a reference capsule over which the statistic is calculated. You can think of this as the golden batch period or the period in time that we know that the system was operating properly. \$refPeriod = capsule("2016-04-01T00:00:00Z","2016-05-01T00:00:00Z") //Cut the single continuous time series signal (Compressor Power) into sections which correspond to the different modes of operation. This gives us three intermediate time series signals which only contain data for the three distinct modes of operation. \$highSeries = \$series.within(\$high) \$lowSeries = \$series.within(\$low) \$offSeries = \$series.within(\$off) // Create three intermediate time series signals, one for each mode of operation. Find the average value of the time series signal during the reference time period for each mode of operation, and then turn that scalar into a time series signal which only exists in the appropriate mode of operation \$highAve = \$highSeries.average(\$refPeriod).tosignal().within(\$high) \$lowAve = \$lowSeries.average(\$refPeriod).tosignal().within(\$low) \$offAve = \$offSeries.average(\$refPeriod).tosignal().within(\$off) // Splice together the three time series signals into a single signal and step interpolate the \$finalSeries \$finalSeries = \$highAve.splice(\$lowAve,\$low,false).splice(\$offAve,\$off,false).toStep() return \$finalSeries Boundaries Using Formula To start, let's calculate the upper boundary as the average + 3 std dev. I can use the Formula tool to calculate this upper boundary using the following variables and syntax. Variables Name Item Type \$Series Compressor Power Signal \$High Compressor High Condition \$Low Compressor Low Condition \$Off Compressor Off Condition Formula \$refPeriod = capsule("2016-04-01T00:00:00Z","2016-05-01T00:00:00Z") \$highSeries = \$series.within(\$high) \$lowSeries = \$series.within(\$low) \$offSeries = \$series.within(\$off) \$highAve = \$highSeries.average(\$refPeriod).tosignal().within(\$high) \$highStdDev = \$highSeries.standarddeviation(\$refPeriod).tosignal().within(\$high) \$highBoundary = \$highAve + \$highStdDev*3 \$lowAve = \$lowSeries.average(\$refPeriod).tosignal().within(\$low) \$lowStdDev = \$lowSeries.standarddeviation(\$refPeriod).tosignal().within(\$low) \$lowBoundary = \$lowAve + \$lowStdDev*3 \$offAve = \$offSeries.average(\$refPeriod).tosignal().within(\$off) \$offStdDev = \$offSeries.standarddeviation(\$refPeriod).tosignal().within(\$off) \$offBoundary = \$offAve + \$offStdDev*3 \$finalSeries = \$highBoundary.splice(\$lowBoundary,\$low,false).splice(\$offBoundary,\$off,false).toStep() return \$finalSeries Similarly, I can calculate the lower boundary as average - 3 std dev using the following variables and Formula syntax. Variables Name Item Type \$Series Compressor Power Signal \$High Compressor High Condition \$Low Compressor Low Condition \$Off Compressor Off Condition Formula \$refPeriod = capsule("2016-04-01T00:00:00Z","2016-05-01T00:00:00Z") \$highSeries = \$series.within(\$high) \$lowSeries = \$series.within(\$low) \$offSeries = \$series.within(\$off) \$highAve = \$highSeries.average(\$refPeriod).tosignal().within(\$high) \$highStdDev = \$highSeries.standarddeviation(\$refPeriod).tosignal().within(\$high) \$highBoundary = \$highAve - \$highStdDev*3 \$lowAve = \$lowSeries.average(\$refPeriod).tosignal().within(\$low) \$lowStdDev = \$lowSeries.standarddeviation(\$refPeriod).tosignal().within(\$low) \$lowBoundary = \$lowAve - \$lowStdDev*3 \$offAve = \$offSeries.average(\$refPeriod).tosignal().within(\$off) \$offStdDev = \$offSeries.standarddeviation(\$refPeriod).tosignal().within(\$off) \$offBoundary = \$offAve - \$offStdDev*3 \$finalSeries = \$highBoundary.splice(\$lowBoundary,\$low,false).splice(\$offBoundary,\$off,false).toStep() return \$finalSeries Final Results Executing these 3 formulas results in 3 new time series signals: Average Compressor Power, Compressor Power +3sd and Compressor Power -3sd. The Customize menu in the Details Pane can be used to adjust how these signals are visualized on the screen:
25. ## Combining past Signal Data with Future Predictions

The above method for combining a Forecast Signal and a Measured Signal should work in any release of Seeq. New in R21 of Seeq however, we have the "forecastSplice()" function which greatly simplifies the workflow. As before, we need a Measured Data signal and some Forecast Signal that will be combined with the Measured Data. The Seeq R21 and later workflow: 1. Create the Master Signal In formula, use the new forecastSplice() operator to join the Measured Data and the Forecast Signal \$measuredData.forecastsplice(\$forecastSignal) The Master Signal now appears as solid line where points are known, and dashed line where the points are still uncertain and expected to change. This is slightly different from the view shown above where the entire Master Signal was dashed due to uncertainty of future data. This helps the Seeq user to visually see where the Measured Data ends and where our Forecast Signal begins. Just as the above formula, the forecastSplice() will update as new data comes in Another operator, forecastConstant() was also introduced with R21. This would do something similar to what is shown above, however, instead of combining the Forecast Signal with the Measured Data, forecastConstant() would project the last value for the Measured Data into the future for some specified amount of time i.e. \$measuredData.forecastConstant(1d) would create a Master Signal where the forecast is projected 1 day into the future: 2. Make sure the Master Signal is Auto-Updating Same as in the prior post
26. ## Combining past Signal Data with Future Predictions

When performing certain types of analysis, it is desirable to combine past measured data with some future prediction, whether that prediction is dynamic or static. Future predicted data can be used for degradation or maintenance date predictions, future performance modeling, signal forecasting, or a wide variety of other potential use cases. Combining some future data with a measured signal is simple in Seeq! Another major benefit? As new data comes in the predicted values can be automatically updated with the actual data! Here is one way to join past measured data with some future forecast signal. Signals To combine measured and forcasted data we will need: Measured Data - a signal(s) that will replace the predicted signal as it becomes available Prediction / Forecast Signal - This could be a flat signal entered in formula, a signal developed in the prediction tool, or some other signal that extends out into the future Method for Combining the Signals 1. Create Future Data Valid Condition This Condition defines the period of time in which the Forcasted signal will be spliced into the Measured Data signal. The formula is based on the last known measured time stamp. In formula we will create a condition by inputting the code snippet below and calling it \$validPlanningRange Formula: /* Define the period when planning data should be used. This time period will start at now (i.e., the last available measured data point) and extend to some point in the future. */ //Define a search window to look for now, This must have a past time to start in, and a future time to look through \$searchPeriod = capsule('2018-08-01T00:00-08:00', '2020-01-01T00:00-08:00') //Identify now by finding the last available measured time stamp \$now = \$measuredData.toGroup(\$searchPeriod).last().getKey() //Create a condition representing now to now plus 6 months \$nowCapsule = capsule(\$now, \$now + 6 months) condition(7 months, \$nowCapsule) Variable Descriptions \$searchPeriod - Capsule defining the search window which will be used to located the most recent data point. For best performance, the start date should be periodically updated to limit the number of measured data points which will be returned. The end date can be set way into the future. \$now - Date representing the point in time where the combined signal we are creating will switch from historical to future data. \$nowCapsule - This creates a capsule which is then made into a condition for use in the next step Create Combined Signal. For maximum performance, recommend keeping the capsule length to the minimum necessary duration (e.g., don't add 1 year if only 6 months is the standard analysis window). 2. Create a Combined Master Signal Once again, in formula we will input the code below to create a new signal that is the combination of the Measured Data and a Forcast Signal Formula \$measuredData.splice(\$forecastSignal,\$validPlanningRange) The result is one signal that combines our Measured Data and a Forecast Signal: The Master Signal appears as dashed line whereas the measured data appears as a solid line. The dashed line indicates the signal is uncertain and therefore, expected to change. 3. Make sure the Master Signal is Auto-Updating By default when the page is loaded or the time range adjusted, the Master Signal will be recalculated and any new data from the Measured Signal will replace the Forecast Signal. Additionally, the analysis can be set to Auto Update.
27. ## Lookup Table Equivelant

Hello Ruben, To best answer this question, we would need to look at your current look up table. If you are uncomfortable sharing it on a public site, I recommend opening a support ticket here. You can just copy and paste the text into the ticket. Normally we recommend using an equation to replace the look up table. However, there are some cases where other approaches are needed. Regards, Teddy

×