Release Note: Update 5.0.1293.16965

PNE-1666

https://slxdev.atlassian.net/browse/PNE-1666

Currently there is one system wide limit for how far back in time data is queried to by the historical aggregator queries. This is currently 2020-01-01.

• Allow Analytics to get earlier data without having to customize every PNE.

• Allow a limit to be placed on how early data is loaded, regardless if there is data available.

• Don't ask for data earlier than a machine has data available

Additionally, there are two parameters for controlling how many days of data is loaded per query. This should be customizable per cube

Update https://slxdev.atlassian.net/wiki/spaces/R/pages/953155585 with instructions on making settings changes.

Acceptance

Should be demonstrated by configuring a cube such that

• Set “dev19_v00016” cube

  • default_requested_start to Dec 15. 2020

  • max_requested_start to Nov 28, 2020

• Run with new aggregator, old PNE, data should load back until Dec 15

  • While loading, set backload_days to 15. Data should start adding at 15 days per build instead of the default 1

• Update PNE to version with changes

  • Data should now load back until Nov 18, 2020

Testing

• Set “qa_v??000” cube

  • default_requested_start to Jan 1. 2020

  • Two dates

    • Step 1 - max_requested_start to Nov 15, 2019

    • Step 2- max_requested_start to Jan 1, 2018

    • Run with new aggregator, old PNE, data should load back until Dec 15

  • While loading, set backload_days to 30. Data should start adding at 30 days per build instead of the default 1

• Update PNE to version with changes

  • Data should now load back until Nov 18, 2020

CS-7167

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

We are experiencing issues with the PEConfig that is copying settings from one machine to the next when making multiple changes on multiple machines. It looks like whatever machine you are working on in the PEConfig the configuration is carried onto the next machine you work on so when you switch to work onto another machine parts of the other machines config are carried over. I noticed this when I was using the PEConfig to update Machine state OPC ID

• Machine state opc IDs being changed to another OPC ID from another machine

• Part Count OPC ID being changed to another machine

Engineers are resorting to use the Flash config because the saving issues that are causing the team to redo their work repeatedly.

Engineers have also reported that the following settings are also affect or reset to default as welll:

• DT percentage being changed to seconds

• % being changed to 5 seconds

• Machine timezone being changed or deleted 

Steps to reproduce the issue:

1. Log into PEConfig and go to machine states on any machine (machine A)

2. Make any change to the machine state such as name of the state then save

3. On the same machine go to Variables and also make a change such as a DT reason name change and save

4. Navigate to a different machine (machine B ), repeat steps 1 & 3 but make different changes and save.

5. Refresh the config page and you will see that the changes saved for machine A are now on machine B.

Sample URL

https://saas141.shoplogix.com/peconfig/#/

CS-7139

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

Yesterday at 10:14 am start problems with the whiteboard on this client, in some machines we have a big delay and the others machines does not shows all data, data are in realtime on the saas, but the both connectors shows issues from yesterday at 10:14am a going wiht the same problem today. For example in the machine 6292DFF4-4B8F-E243-4CAF-62E929C8682B we should see an order that started at 1:38 am, but it is not being shown in the Whiteboard but it is seen in the OPCcombined. Attached images.

Thanks and regards.

Sample URL

https://saas139.shoplogix.com https://lamitech.shoplogix.com/whiteboard/#/perioddetail/0938A90B-DC72-74B3-FBA5-5F529ED3DD0D/start/20210310T070000.000/end/20210310T190100.000/bucket/60/timeMetric=0 https://lamitech.shoplogix.com/web/xmldata/cn_lamitechcol1/logs/2b35d602-4115-466a-84f5-b362d232a23b/2021-03-09%20RealtimeSync.txt?contentType=text/plain https://lamitech.shoplogix.com/web/xmldata/cn_lamitechcol2/logs/70a4cf74-6f32-466a-b9f2-56a475bbe6cb/2021-03-09%20RealtimeSync.txt?contentType=text/plain https://lamitech.shoplogix.com/whiteboard/#/perioddetail/6292DFF4-4B8F-E243-4CAF-62E929C8682B/start/2021-03-10T00:00:00-05:00/end/2021-03-10T19:01:00-05:00/bucket/60/timeMetric=0 https://lamitech.shoplogix.com/Web/query.axd?type=OpcCombined&start=20210310&machines=6292DFF4-4B8F-E243-4CAF-62E929C8682B

CS-7024

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

Configuring Timezones failed yesterday and caused crash in the server.
Even after following this google sheet where it specifies which machines are “not safe" to configure .

https://docs.google.com/spreadsheets/d/1z00zOpHB0U-VB46btIbN_kGIlzKXc_ajIxyHVTNEz-w/edit?ts=60414aa8#gid=114571122

An error shows that it is because of SIROP 3 according to the attached log (Ben’s investigation).
SIROP 3 was one of the safe machines configured.

See comments on the linked case where some machines were left out because they were one of the "not safe" machines.

Sample URL

saas117.shoplogix.com

CS-6977

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

We have not received any of the old style flash reports since 05.37 this morning. I was under the impression we would continue to receive these reports as the new reports are not yet to standard.

Best regards,

Sean Gallagher.

Sample URL

saas117.shoplogix.com

CS-6352

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

All 3 germans sites in coveris are looking to send jobs to an area and not to a machine. Like it is done in Campine (also on saas141).

Coveris, Neuwied is the test site and the following details have been added to the configuration.xml for the plant:
<AreaID>89</AreaID>
<Name>Neuwied, DE</Name>
<Order>2</Order>
<Plant>1</Plant>

• <JobListRunOnce>1</JobListRunOnce>
  <JobScheduleTransform>AreaToMachines</JobScheduleTransform>
  <JobScheduleReader>XmlTransformerJobConverter</JobScheduleReader>*

This allows jobs to be sent to an area ID through their xml job files. Rather than using MachineID as an attribute AreaID is used.

For example:
AreaID="92"

Attached is the job file that customer sent as a test and shoplogix failed to accept the jobs.
Sample URL

saas141.shoplogix.com