Absolutely! Developers debug until their algorithms actually work. Users are not developers. They presume algorithms work and just monitor/analyze performance for tuning purposes. These use cases are very fundamentally different. No user wants to wade through tons of debug to get summary data they need for performance analysis. Another analysis example illustrates the point. I use PHD2 not because I don't like the internal guider, but because there's a post analysis tool (logViewer) that can show how guiding performed (and whether I need to tune or not). That's not debugging. The first rule of performance assessment/improvement is measurement. Without the summary measurements, it's hard to improve. I suggest the vision for INFO level should be to support performance assessment and aid users in tuning/improvement. Cheers, Doug

Jasem, I'd like to respectfully disagree with you on both your assertions and ask you to reconsider. Given that a plot method has already been created by another user, it shows that I'm not the only user who would envision plotting the summary. There is a big difference between debugging and performance monitoring/analysis. I'm suggesting that the summary info is perfectly in step with what INFO level should support. While the other focus algorithms are inconsistent in what/how INFO summary data is provided (a generalized problem probably needing to be addressed separately), they do provide INFO summary data consistent with this request (focuser position, HFR). I submitted the request when I saw that Hy's algorithm wasn't consistent with INFO data from the other algorithms. It's true that I can turn on debug to get the summary, but it shouldn't be true that if users want to monitor performance post-run, they should need to turn on debug. Hopefully after you reconsider the difference between debugging and performance monitoring/analysis, you'll agree. Cheers, Doug