How can I beat this error? Samples must be ordered by their keys!

[Ivan Berry]

Quote (400) Bad Request - Samples must be ordered by their keys! Sample (2023-04-22T22:19:40.083999600Z, 2.1432340145111084ppm) is followed by (2023-04-22T22:19:40.083999488Z, 2.1432340145111084ppm) When adding properties to capsules I sometimes get this error, it is fairly random across many different PI tags in different servers. I believe it may be related to seeq version R61.1.6 as I have only just started seeing it. It is consistent for the tag and time period that the error occurs for. This is the offending seeq formula. The signals in question trend just fine in Seeq. $condition.setProperty('CO (minimum)', $co, minValue())                         .setProperty('CO (maximum)', $co, maxValue())                         .setProperty('O2 (minimum)', $o2, minValue())                         .setProperty('O2 (maximum)', $o2, maxValue())       I am sure there is something that needs to be fixed here in Seeq or PI to resolve this correctly, but I am looking for a crafty workaround I can use in the short term while our IT support figures this out. Any ideas much appreciated!

[John Cox]

Hi Ivan,

I would suggest clearing the cache on all the raw signals and conditions that are inputs to your Formula, as well as clearing cache on the Formula itself. You can clear the cache on an item using Item Properties in the Details Pane ("Clear Cached Values" under the Advanced section).

If this does not resolve the issue, I would suggest making an Office Hours appointment, so that a Seeq analytics engineer can assist you further: https://info.seeq.com/office-hours

[John Cox]

Hi Ivan,

It's also possible that this is related to a software bug in version 61. This bug is fixed in future versions (starting in R64), but in the event you are falling victim to that same bug, here is a quick workaround you can try. It may or may not help, but is something you can try quickly. Basically you need to apply a .round(12) to each numeric signal used in the Formula, prior to the .setProperty functionality:

$rounded_co = $co.round(12)
$rounded_o2 = $o2.round(12)
$condition.setProperty('CO (minimum)', $rounded_co, minValue())
                        .setProperty('CO (maximum)', $rounded_co, maxValue())
                        .setProperty('O2 (minimum)', $rounded_o2, minValue())
                        .setProperty('O2 (maximum)', $rounded_o2, maxValue()) 

[Ivan Berry]

Thankyou John! That round(12) did work, 🎵 I'm on the road again 🎵

Edited October 12 by Ivan Berry

[Ivan Berry]

OK new problem, any ideas on how to overcome this same error for this type of seeq formula:

$s.aggregate(totalized('hr'),months(), durationKey()).setUnits('BTU/month')

I've tried round and resample. 

 

Edited November 8 by Ivan Berry

[Patrick]

Hi Ivan - Have you tried clearing the cache on the source signal via Item Properties in the Details Pane ("Clear Cached Values" under the Advanced section)?

[Ivan Berry]

I just tried that, no luck. Thanks.

[Patrick]

Thanks for checking Ivan.  I'm not sure what is happening here.  I've not been able to reproduce this issue on our server.  I also checked our ticketing system and am unable to find known issues related to the calculation you are trying to perform (the previous bug you encountered was related to min/max formulas and is fixed in 62.0.7.)

I suspect there might be an issue upstream of the calculation - are you performing any min/max or other operations on $s?.  It might be more expedient to sign up for an office hour session so we can work this 1:1.

https://outlook.office365.com/owa/calendar/SeeqOfficeHours@seeq.com/bookings/

[Ivan Berry]

Yes there are upstream calcs, including max, but they are all working.

 

Thanks Patrick, I'll sign up for an office hour.