Jump to content
  • To Search the Seeq Knowledgebase:

    button_seeq-knowledgebase.png.ec0acc75c6f5b14c9e2e09a6e4fc8d12.png.4643472239090d47c54cbcd358bd485f.png

Search the Community

Showing results for tags 'product code'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Community Technical Forums
    • Tips & Tricks
    • General Seeq Discussions
    • Seeq Data Lab
    • Seeq Developer Club
    • Seeq Admin Forum
    • Feature Requests

Categories

  • Seeq FAQs
  • Online Manual
    • General Information

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Company


Title


Level of Seeq User

Found 3 results

  1. Seasonal variation can influence specific process parameters whose values are influenced by ambient conditions, or perhaps raw material make up changes over the year's seasons based on scheduled orders from different vendors. For these reasons and more, it may not suffice to compare your previous month's process parameters against current. For these situations, it may be best to compare current product runs against previous product runs occurring the same month, but a year ago in order to assess consistency or deviations. In Seeq, this can be achieved through utilizing Condition Properties. 1. Bring in raw data. For this example, I will utilize a single parameter (Viscosity) and a grade code signal. 2. Convert Product step-signal into a condition. Add properties of Product ID, Variable statistic(s), and month start/end times. // Create a month condition. Be sure to specify your time zone so that start/end times are at 12:00 AM $m = months('US/Eastern') // Create a signal for start and end times to add into "Product ID" condition $start_signal = $m.toSignal('Start', startKey()).toStep() $end_signal = $m.toSignal('End', startKey()).toStep() $p.toCondition('Product ID') // Convert string signal into a condition, with a capsule at each unique string // Specifying 'Product ID' ensures the respective values in Signal populate // a property named 'Product ID' .removeLongerThan(100d) // Bound condition. 100d as arbitrary limit .setProperty('Avg Visc', $vs, average()) // Set 'Avg Visc' property reflecting avg visc over each Product ID .setProperty('Month Start', $start_signal, startValue()) // Set 'Month Start' property to know what month Product ID ran .setProperty('Month End', $end_signal, startValue()) // Set 'Month End' property to know what month Product ID ran 3. Create another condition that has a capsule ranging the entire month for each product run within the month. Add similar properties, but note naming differences of 'Previous Month Start' and 'Previous Month Avg Visc'. This is because in the next step we will move this condition forward by one year. $pi.grow(60d) // Need to grow capsules in the condition to ensure they consume the entire month .transform($capsule -> // For each capsule (Product Run) in 'Product ID'.... capsule($capsule.property('Month Start'), $capsule.property('Month End')) // Create a capsule ranging the entire month .setProperty('Product ID', $capsule.property('Product ID')) // Add property of Product ID .setProperty('Previous Month Start', $capsule.property('Month Start')) // Add property of Month Start named 'Previous Month Start' .setProperty('Previous Month Avg Visc', $capsule.property('Avg Visc')) // Add property of Avg Visc named 'Previous Month Avg Visc' ) Notice we now have many overlapping capsules in our new condition ranging an entire month -- one for each Product Run that occurred within the month. 4. Move the previous 'Month's Product Runs' condition forward a year and merge with existing 'Product ID' condition. Aggregate properties of 'Previous Month Avg Visc'. This ensures that if a product was ran multiple times and had different avg visc values in each run, then what is displayed will be the average of all the avg visc values for each product. $previousYearMonthProductRun = $mspi.move(1y) // Move condition forward a year $pi.mergeProperties($previousYearMonthProductRun, 'Product ID', // Merge the properties of both conditions only if their // capsules share a common value of 'Product ID' keepProperties(), // keepProperties() will preserve all existing properties aggregateProperty('Previous Month Avg Visc', average())) // aggregateProperty() will take the average of all 'Previous // Month Avg Visc' properties if multiple exist... I.e. if // there were multiple Product Runs, each with a different value // for 'Previous Month Avg Visc', then take the average of all of // them. The resulting condition will match our original condition, except now with two new properties: 'Previous Month Start' & 'Previous Month Avg Visc' We can then add these properties in a condition table to create a cleaner view. We could also consider creating any other statistics of interest such as % difference of current Avg Visc vs Previous Month Avg Visc. To do this, we could use a method similar to gathering $start_signal and $end_signal in Step 2, create the calculation using the signals, then add back to the condition as a property.
  2. In Seeq's May 25 Webinar, Product Run and Grade Transition Analytics, we received a lot of requests during the Q&A asking to share more details about how the grade transition capsules were created and how they were used to build the histograms presented. So here is your step-by-step guide to building the condition that will make everything else possible! Defining your transition condition Step 1: Identifying product campaigns The "condition with properties" tool under "identify" can transform a string signal of product or grade code into a single capsule per campaign. In older versions of Seeq this same outcome can be achieved in formula using $gradeCodeStringSignal.toCondition('grade') Note: if you don't have a signal representing grade code, you're not out of luck, you can make one! Follow the general methodology here to search for set point ranges associated with different grades or combinations of set points that indicate a particular grade is being produced. Step 2: Create the transition condition encoded with the starting and ending product as a capsule property $t = $c.shrink(2min).inverse() //2 min is an arbitrary small amound of time to enable the inverse function to //capture gaps in the campaigns $t.removelongerthan(5min) // 5min is an arbitrarily small amount of time to bound calc (that is >2min * 2) .transform($capsule -> $capsule.setProperty('Transition Type', $pt.resample(1min).toscalars($capsule).first() + '-->' + $pt.resample(1min).toscalars($capsule).last())) .shrink(2min) Step 3: Identify time period before the transition Step 4: Identify time period after the transition Step 5: Optional - for display purposes only - Show the potential transition timeline (helpful for chain view visualizations) Step 6: Create a condition for on-spec data Here we use value search against spec limit signals. If you don't have spec limit signals already in Seeq, you can use the splice method discussed in the post linked in step 1 to define them in Seeq. Step 7: Combine condition for on-spec data and condition for time period before the transition Step 8: Combine condition for on-spec data and condition for time period after the transition Step 9: Join the end of the condition for on-spec before the transition to the start of the condition for on-spec after the transition to identify the full transition duration Your condition for product transitions is now officially ready for use in downstream applications/calculations! Working with your transition condition Option 1: Calculate and display the transition duration Use Signal from Condition to calculate the duration. The duration timestamp will generate a visual where the length of the line is proportional to the length of the transition. Increasing the line width in the customize panel will display the transition duration KPI in a gantt-like view. Option 2: Build some histograms Summarize a count of capsules like the number of times each distinct transition type occurred within the date range. Summarize a signal during each unique transition type, like the max/min/average transition duration for a distinct transition type. Option 3: Generate some summary tables Switch to the table view and toggle "condition" to view each transition as a row in the table with key metrics like total duration and viscosity delta between the two grades. Add the "transition type" property from the "columns" selector. If you run into hiccups using this methodology on your data and would like assistance from a Seeq or partner analytics engineer please take advantage of our support portal and daily office hours.
  3. Seeq is often used to contextualize data with respect to production runs. These product runs may be a text or string signal that is the product code, or a very large numerical signal. Users commonly use Value Search to find a specific product run to further analyze. If they want to work with a couple of similar product runs, for example ones that start with or end with the same few letters or numbers, a few Value Searches followed by Composite Condition may be acceptable. This approach may not be realistic if there are hundreds of different product codes to analyze. Recently a user asked for a trim function because they wanted to categorize all product codes by the first few letters the product code. For example, ABC-123-XYZ and ABC-456-DEF would both fall under the "ABC" product category. In Excel, users might use something like the functions LEFT and RIGHT to return the first few characters (LEFT(3) in this ABC example). One way to do this text or string manipulation in Seeq is to use the replace() function with a regular expression. Regular expressions can be intimidating to those who have not used them before, but they can also be very powerful. A little exploration on sites like https://regex101.com can help evaluate what kind of regular expression is appropriate for a specific use case. Given the above example product codes, the below Seeq Formula incorporates a regular expression within the replace() function to parse the string signal by the "-" and then return only the first part of that parsed string based on the "$1". $productcode.replace('/(.*)-(.*)-(.*)/', '$1') I could similarly categorize by the last three characters with a function like $productcode.replace('/(.*)-(.*)-(.*)/', '$3') Once this simplified text signal is available, any other tools can be used in the analysis. If the product code was a very large number instead of a string, apply toString() to benefit from the replace() function. There are often many ways to solve a problem. An alternate approach to categorize product codes like this might be to pair toCapsules() and filter() off the Value property in Formula. Perhaps the best solution is incorporating regular expressions into Value Search like in the example below to create conditions any time the product code starts with ABC (/^ABC.*/) or any time it ends with XYZ (/.*XYZ$/). The slashes here indicate regular expressions should be used, similar to searching with regex in the Data Pane. But this approach is likely not obvious or easy without a little experience with regular expressions. So while regular expressions may feel foreign at first, do not be intimidated! They really can pay off in the long run.
×
×
  • Create New...