Typically scans are skipped because the interface can't read all of the tags in the scan class before it's time to read again. This can be caused by too many tags in the scan class and the OPC server can't serve them fast enough.
Are these polled or advise tags?
What is the OPC server being read by PI-OPC? Does it have logs that you can examine?
When you said "I've just run pigetmsg and it prints out the lines like an old dot matrix printer, character by character rather than line by line", is that being run on the PI interface computer or the PI server? That sure sounds like the computer is running extremely slowly.
Are your other PI-OPC interfaces running on the same interface PC, or a different one?
Are you seeing any "The OPC server did not respond to the last Refresh call for scanclass N, and has not responded to the previous nnn Refresh call(s)." messages in the logs? Those would indicate the OPC Server itself being overloaded.
If you are simply seeing scans skipped (as described by Steve Boyko), then you should take a look at pretty much all of your scan classes. In average, you seem to only get 50% of the scans on time.
- Depending on your number of tags, you may want to split your interface instance in two separate instances. Since the interface is single-threaded, splitting it in two can make a big difference and allow multiple calls to be made at the same time.
- Move the majority of your tags in Advise polling instead of polled. Since the tags will be "subscribed" to changes it will also help the interface perform significantly better. If using advise, change your group size (/AM) to a number smaller than default (200-400)
- Include all of the most time-sensitive tags in advise groups. This should actually reduce overall network load as you are only getting updates from the server when new values happen, whereas Polled tags will make many unnecessary calls back and forth to the server.
- For your polled tags, the easiest fix is to increase the time for each scan rate. The scan rate is sent to the OPC server, and the OPC server makes a good faith effort to keep data in a cache as fresh as the scan rate. However, whether the OPC server is able to reach out to all of the end devices to do so is not guaranteed. Increasing the scan rate provides the OPC server more time to gather data from the data sources before going back out for another device scan.
Hope this helps,