When I set up SCADA signals with a 24-hour period, it works and I am able to view SCADA historical results in both the SCADA Signal preview menu or SCADA elements in the model. However, if I change to another time frame (such as 48 hours), WaterGEMS crashes suddenly and without any error messages.
I thought at first that it was due to the complexity of the model and the large number of signals, but the problem is reproducible with an empty model and only a single signal.
Version information: 10.01.01.04 32-bit
The following procedure works without issue:
However, if the exact same procedure is followed, except the second timestamp is changed to (TimeStamp<=08/22/2018), when you click Okay from entering the Custom SQL Statements, the program freezes for about 30 seconds, then crashes completely. There is no warning message or 'crash report' dialogue.
If you change the date range to 8/21/2018 - 8/22/2018, it works fine, but a date range of 8/21/2018 - 8/23/2018 crashes. So there doesn't seem to be a problem with a specific date, just with ranges greater than 24 hours.
Hi Stephen,
Can you provide the details of the crash dialog? If it is the standard Bentley crash dialog, you should see an icon in the lower-left corner, which will open the text of the error.
Does this only happen with custom SQL statements?
Regards,
Jesse DringoliTechnical Support Manager, OpenFlowsBentley Communities Site AdministratorBentley Systems, Inc.
Unfortunately there is no crash dialogue. WaterGEMS just exits straight to desktop. I was able to find the 'View SCADA Log' files in /AppData/Local/Temp. I'll post those as two following comments with some notes. I also found the crash dumps in /AppData/Local/CrashDumps - I could send you those if it would be helpful.
I can't connect without custom SQL statements. There are no entries in the 'Select SCADA Signals' dialogue if I haven't set the custom SQL. (That's true whether I don't select Historical/Real Time, or if I select either of those two options.)
Hi Stephen, thanks for all the observations. We will discuss internally and get back to you shortly.
One additional thought:
I had been noticing that when I had SCADA set up for a 24 hour query, after every model run the first SCADA Element I would try to Quick Graph would lag for a while before showing the graph, and then as I clicked around to other Elements they would graph very quickly. This seemed strange to me, as it should be the same amount of data each time. I figured it was just some initial connection lag.
But now it would make sense that perhaps on that initial connection to SCADA after running a simulation, WaterGEMS is first trying to verify the query generically, and doing the same stripping of the Tagname filter, causing the large number of returned records and the lag. So it may be that there are multiple places in the code where this verification is performed. If that's the case, not only would fixing it make things more stable, it would also improve performance by getting rid of that initial connection lag. I don't know if it's the same function being called each time (so fixing it once would fix it for all), or whether a similar routine is copied in multiple locations in the code.
Thanks, Stephen, our developer is currently looking into this. We'll keep you updated.
Sorry for the delay on getting back to you on this.
Is there a specific reason to include hard coded date ranges into that custom query? If not, you should be able to leverage the @startdatetime and @enddatetime variables and when querying the custom query for column metadata SCADAConnect will substitute those variables such that the time range is tiny, and you should not run into any such issue.
Wayne.
ps/ More information on those date/time variables can be found here:
https://communities.bentley.com/products/hydraulics___hydrology/w/hydraulics_and_hydrology__wiki/33335/how-to-define-real-time-custom-queries-in-scadaconnect
I have been playing around with the GE Historian some more.
I was able to reproduce the same DB_E_ABORTLIMITREACHED issue, albeit without any crash. That seems to be a side effect, like you found, of specifying a date range that results in too much data being returned. The amount of data is by default limited to 5000 rows, but the part of your query where you have set rowcount=0, turns off that limit. I would guess then that keeping some kind of limit in place is a reasonable idea.
Now, I'm not sure whether things have changed in different GE versions, but the version I am using seems to be working a lot better if I use a query like this.
set rowcount=5000, samplingmode=rawbytime select Tagname,Value,TimeStamp,Quality from ihRawData where Tagname=(@requestedsignals) and (TimeStamp>=@startdatetime) and (TimeStamp<=@enddatetime) and Quality = "Good NonSpecific"
I'm getting data back and it's coming back very fast now.
Some issues I am still looking into...
I'll post again if I find out anything new.
Answer Verified By: Stephen Jackson
Wayne,
Thanks so much for the help - this solved the problem for me. I'll put some details below to help the next person with this issue.
The query that I'm using now is:
set rowcount=5000, samplingmode=rawbytime select Tagname,Value,TimeStamp,Quality from ihRawData where (@requestedsignals) and (TimeStamp>=@startdatetime) and (TimeStamp<=@enddatetime) and Quality = "Good NonSpecific"
A few observations:
Once again, I very much appreciate both yours and Jesse's help. This has been an interesting issue to delve into and understand the software better.
Thanks for the detailed response Stephen. Glad this is working. Feedback like this is invaluable to us. SCADA and real-time operations is one of the areas in which we are currently focused, so please be sure to let us know if you run into any other issues and we will do our best to assist.