Perspective Reporting Best Practices

Hi all,

I may be off the mark on my paradigm here, so let me know if the question doesn't even make sense to ask, but here goes:

We currently use excel with RSLinx to create DDE topics to import PLC data to generate reports for things like shift production, downtime, etc. Downsides to this method are numerous: data is logging in the PLCs, DDE topics are annoying and sometimes break for seemingly no reason, we have almost no ability to historize this data (as it'd have to be stored in the PLCs again, or break out some VBA to make some excel scripts to do that...), and I'm sure there's many more reasons.

So, I'm trying to shift away from that method into Ignition's Perspective Reporting functionality! I have played around creating a singular report thus far, and I've found mixed results, likely due to inexperience. I have things like operating efficiency over the last 5 minutes, hour, and total shift thus far. These log to my database on those time periods, and are therefore able to create a graph easily, or do a quick and easy calculation to find the average.

I'm wondering what the best practices would be for things like end-of-shift totals. Should I just calculate the total production number in the PLC, and then write that to the database once, moments before generating the report (or perhaps quarterly, then have the ability to break it down as such)?

Another question: is there a way to do simple math on multiple tags? For example, suppose you have a total production number through two production lines. On the report, I'd like to display totals for each line, as well as a "grand total" - in excel this is just a simple =sum, is there anything I can do like that? Or would it be better practice to do that math in the PLC, and write all three tags to the database?

Other advice is absolutely welcome regarding best practices, methods, etc!

Thanks for your knowledge!

Tip: as far as I know reporting is independent of both Perspective and Vision. You can call a report from either but the report is designed and executed separately using the Report module which is a separate item in Project Browser..

1 Like

@param1@+@param2@

1 Like

Link to user manual: Reporting - Ignition User Manual 8.1 - Ignition Documentation

You should also check out the Inductive University videos on the topic.

1 Like

Edit, might actually be @param1+param2@, haven't done any reports in a while!

https://docs.inductiveautomation.com/display/DOC81/Keychain+Expressions

1 Like

General advice:
Separate concerns as much as possible. As in:

  • Leave the PLC in charge of 'live' data
  • Use your SCADA platform to log live data from the PLC into the database
  • Use your database (as much as feasible) to perform data aggregation, such as totals/shift or counts/timeslice, or whatever else
  • Use your SCADA to deliver results from the database in a convenient form.

Every piece of the system that's interconnected is a piece you have to untangle if requirements change and you have to, say, swap SCADA platforms. Or PLC brands, or DBs, or whatever. Also, play to the strengths of the thing you're dealing with. PLCs are not the right tool to aggregate together large datasets, databases are not the right tool to generate PDFs, etc.

Concrete advice: You probably want to store "production count thus far" at a regular interval to your database. Then it's trivial to write a query to determine "piece count for time slice" - just subtract the count at the final period from the count at the beginning.

While you can do simple math like this in reports, again, it's an intermingling of concerns. Instead of your report being a fairly "dumb" presentation of data collected from the database, any change of reporting platforms in the future would require to untangle all the myriad bits of execution in your report. Again, I would say to play to the strengths of what you're working with - make a single DB query you can use that returns A, B, and A - B together, and just use that in the report.

3 Likes

That's not my experience, Paul. I've found that the historian doesn't interpolate values to the timeslice boundaries.


So far I have been unable to get hourly counts from a historian query. I discussed this problem in
Tag history interpolation - not returning interpolated values
.

1 Like

Counters should not be stored in the historian. It is not the kind of value (like a process sensor) that is compatible with the historian's recording method. Use a Transaction Group or script the insert into the DB. Capture in the same DB table any other values that you might want to use to filter against when querying those counts.

(Note: @PGriffith did not say to use the historian. Paul says to "record in the database". @Transistor took that to mean "use the historian", but that is a bad assumption.)

2 Likes