Page Comparison

CS-5804

https://slxdev.atlassian.net/browse/CS-5804

SAAS16.shoplogix.com
kamtek-cosma-magna.shoplogix.com

Neither one displays the asset tree. Just see the Shoplogix tree.

Email from customer last night to support group at 6:42 PM.

I did a check at 7:15 and got in to see data and then at 7:30, not working.

CS-5752

https://slxdev.atlassian.net/browse/CS-5752

All uptime is being categorized as Slow Running.
Slow Running is not configured for this machine.

This should be uptime.

Please assist asap as the customer is extremely confused and is unsure what way to interpret the data.
Slow Running has not been a machine state used at this customer and therefore no operators have been trained on this.

Sample URL

https://saas105.shoplogix.com/whiteboard/#/shifthours/48E753E5-C653-B002-C51A-3C716974B655

CS-5736

https://slxdev.atlassian.net/browse/CS-5736

The speed calculation is incorrect for the area level. The machines are reporting correct speeds individually but for the area the speed is incorrect based on the formula for speed in uptime = Total (Good & scrap during uptime) / Uptime. Example below with details

https://coveris.shoplogix.com/whiteboard/#/shiftrollup/areas/25/offset/-1/cycle=1&gauge1=1&gauge2=8&gauge3=3&timeMetric=0&goalgreen=1&goalyellow=0.75&goalred=0.5&scrapgreen=0.02&scrapyellow=0.05&scrapred=0.1&cycleDP=1&cycleTOL=0&gaugeTOL=0&nojobs=true&noplot=true&noreason=true&nocomment=true

Sample URL

https://saas126.shoplogix.com/whiteboard/#/shiftrollup/areas/25/cycle=1&gauge1=1&gauge2=8&gauge3=3&timeMetric=0&goalgreen=1&goalyellow=0.75&goalred=0.5&scrapgreen=0.02&scrapyellow=0.05&scrapred=0.1&cycleDP=1&cycleTOL=0&gaugeTOL=0&nojobs=true&noplot=true&noreason=true&nocomment=true&noloss=true

CS-5227

https://slxdev.atlassian.net/browse/CS-5227

We have a diferente translation from english in portuguese, can you help us?

https://incm.shoplogix.com/whiteboard/#/dashboard/CD656907-BEFE-F963-DCD1-7852FF312727

Tks.
TS

CS-4923

https://slxdev.atlassian.net/browse/CS-4923

We found a not a good point today ; with "shift recency" we are supposed to take the 3 last completed shifts...

On the report joined here you will see we selected shift recency. But if you look at the result on the OEE + good production / per lines : the result for line 302 says : 53,37% and 4 296 parts.

Meaning : On the same dashboard I have result from yesterday but also result from the last time that the line was running (in this example line 302 on the 12th november... )

I looked into the whiteboard and that true, ast time was on the 12th !
then we have rsult from the 16 / 11 / 2020 and the 12 / 11 / 2020 on the same report however we want the result of yesterday !

Sample URL

https://portal.shoplogix.com/app/main#/dashboards/5fa159c2b8b341002d1d3e23 https://fareva.shoplogix.com/whiteboard/#/shifthours/00d0c9bab117/offset/-1/gauge1=1&gauge2=8&gauge3=0&timeMetric=0&showoccurrs=true&cycleDP=1&cycleTOL=0&gaugeTOL=0&goalgreen=1&goalyellow=0.75&goalred=0.5&scrapgreen=0.02&scrapyellow=0.05&scrapred=0.1

CS-4425

https://slxdev.atlassian.net/browse/CS-4425

There is something going on with the API when pulling by Shift Instance and excluding Capacity Times

See below example
https://saas113.shoplogix.com/web/api/export/summary?Start=20200919T060000&End=20201019T060000&metrics=uptimeHours,downtimeHours,setupHours,total,scrap,OEE,availability,performance,quality,&groupBy=machine,shiftInstance,&areas=12&classificationFilter=capacity&classificationFilterType=Exclusive&format=xml

This is for the 1st machine Killian 1 [D94EF857-3E38-5134-8C77-02C1C8437029]

If you see the highlighted shift instance is pulling from the Oct 13 up to Oct 15 as one instance, and production shown is actually for the 15

ShiftCalendar for Killian 1 (Shifts are scheduled okay)

If I remove the Exclude Capacity Time, then Shift Instance works as expected

https://saas113.shoplogix.com/web/api/export/summary?Start=20200919T060000&End=20201019T060000&metrics=uptimeHours,downtimeHours,setupHours,total,scrap,OEE,availability,performance,quality,&groupBy=machine,shiftInstance,&areas=12&format=xml

Sample URL

https://saas113.shoplogix.com/web/api/export/summary?Start=20200919T060000&End=20201019T060000&metrics=uptimeHours,downtimeHours,setupHours,total,scrap,OEE,availability,performance,quality,&groupBy=machine,shiftInstance,&areas=12&classificationFilter=capacity&classificationFilterType=Exclusive&format=xml

PROD-280

https://slxdev.atlassian.net/browse/PROD-280

SLX leadership recently presented the Paging beta to the potential customers. They are still interested but have 3 main concerns that they say need to be addressed:

• The paging banner is not prominent enough for across the shop-floor

• Each customer wants their own unique group of Paging recipient departments (e.g. Changeover, Quality, Maintenance team, etc.)

• Customers want to trigger pages (trigger them ON) based on an OPC tag

These items are part of this Epic, attached as Issues below.

How this workflow looks in the context of our application

1. Production supervisor configures and manages their group of “responders” to a shop-floor issue ( https://slxdev.atlassian.net/browse/PROD-281 )

2. Production supervisors also want to ensure that not only can pages be triggered near a computer, but also through their own industrial “OPC Events” (e.g. hitting a button on a forklift, etc.) ( https://slxdev.atlassian.net/browse/PROD-296 ).

3. Production supervisor wants some of their TVs to essentially “block” viewers from seeing any other metrics until a page is responded to ( https://slxdev.atlassian.net/browse/PROD-279 )

   For other TVs, the supervisor is OK with regular paging functionality

PROD-243

https://slxdev.atlassian.net/browse/PROD-243

Dev Refine results:

• probably acceptable difference from original report: We can’t provide every 15min for this data. Every hour is best we can do. This is due to the bucketing strategy we use for coredata (hourly).

• Investigated cost per (X) where X is (electricity, water, gas):

  • Export three values onto Dim Machine seems fine. 0 by default.

• Test with machine: https://qatesting.shoplogix.com/web/query.axd?type=coredata&machines=XMLCN_Simulator&start=20201110T090000.000&end=20201111T110000

  • two birds one stone: restore QA13 and copy QATesting’s data…

Acceptance Criteria:

• [Fact Core] 3 new fields:

  • Electricity

  • Water

  • Gas

• [Fact Core Line] will NOT include the 3 new fields.

• [Dim Machines] 3 new fields:

  • Electricity Cost

  • Water Cost

  • Gas Cost

  • Could add unit to each of these: “Per kWh”, “per L”, “per cubic meter”, respectively. Let me know which you prefer

• model _v00012 will contain the changes.

Server Example: saas124

Engineer: Francisco Salgado

Area/Machines: All the filler machines in Industrias Licoreras - Daily or Monthly

Reports: All reports should be moved to analytics. This includes: Consumption Table, Electricity Usage, Electricity Machine Rollup, Job Electricity Scatter

*Connected to core data

Missing Variables

• Electricity (kWh)

• Water (L)

• Gas (Cubic Meter)

• Expected Consumption - comes from jobs

• Cost per Unit of Measurement - INVESTIGATE (This could be built into the dashboard and saved - Can be with machine type) - WE KNOW comes from machine config

Calculated Variables

• Electricity ($)

• Water ($)

• Gas ($)

• Min, Max

More Information:

Consumption Table: Shows consumption of energy every 15 mins during one shift, as electricity usage in kWh, with start and end time.

Electricity Usage: Electricity consumption (kWh) during one shift, during unscheduled time, and total consumption (sum of shift + unscheduled)

Electricity Machine Rollup: Rollup of electricity usage by line

Job Electricity Scatter: Hover over this to see Energy> Electricity → Only way for users to see how much electricity an order (/job) uses → would prefer to have this in a table

Image Removed

Image Added

PROD-242

https://slxdev.atlassian.net/browse/PROD-242

Dev Refine:

• [Fact Core] add:

  • Inventory Name (hidden)

  • Inventory Consumed

• [Dim Inventory] create wit these columns:

  • Inventory Name

  • Inventory Start DateTime

  • Inventory End DateTime

  • Inventory Start Level

  • Inventory End Level

    • (note to self: inventory 0 is most common… but you could scan in a non-zero number… think coil consumption).

  • Inventory Filters 1-5 – Renamable! Translatable! in flash… we can use translations in analytics when thats ready…

    • (107’s example: PO/ItemNumber, etc, were all filters).

• We suspect default inventory records apply before coredata anyway, but wanted to mention they should play nicely.

Server Example: saas107

Report: Inventory Yield Summary

Machines/Areas: Any of the CTL devices in the Steel Drum Group - Weekly Report

Engineer: Brock

New Variables

• Inventory ID

• Inventory Filters 1-5

• Start of inventory record (time)

• End of inventory record (time)

• Start (Level)

• End (Level)

Calculated Variables

• Consumed (Level) - ( Inventory Cycle Factor x Pieces produced )

• Expected (Yield) - ( (start - end)/inventory cycle factor )

• Total (% Yield) - Total pieces made/Expected

• Good (% Yield) - Good pieces made/Expected

• Duration - ( Start time of inventory job - end time of inventory job )