Is there a good way to set up the Rpi3 to wait for the data and process it as it comes in?

Probably not via I2C, although you could try and see what happens if you request information from a slave allowing an indeterminant amount of time for the request to complete, then just implement things on the Arduino such that you assume such a request is always pending (which it could be if this works, and you do the pi side implementation appropriately). It may be that such requests will fail quickly, but that could be leveraged by making requests at intervals and only processing the ones that don't throw an error.

Otherwise you'd have to poll (sucessfully) for information at intervals, but that would lead to this:

the Arduinos then would have to spend much more time looking for the requests. My Arduino programs utilize specific delay() times (like when they are moving the solar panels) so interrupts would be a problem in maintaining proper timing.

Regarding which I'd say if your ISR just sets a volatile boolean indicating a request is ready, then you handle that outside the ISR in your main loop, the ISR is unlikely to take more than a few microseconds to execute, which I doubt is going to create any timing problems for you moving solar panels.

However, doing things the other way around should not be hard if you are determined to avoid any possible interference. When new data is ready, send an interrupt to the Pi using a non I2C pin; the Arduino could then wait for the request, which should be very quick, reply, and continue on.

Is there a good way to set up the Rpi3 to wait for the data and process it as it comes in?

Probably not via I2C [normatively; see joan's answer], although you could try and see what happens if you request information from a slave allowing an indeterminant amount of time for the request to complete, then just implement things on the Arduino such that you assume such a request is always pending (which it could be if this works, and you do the pi side implementation appropriately). It may be that such requests will fail quickly, but that could be leveraged by making requests at intervals and only processing the ones that don't throw an error.

Otherwise you'd have to poll (sucessfully) for information at intervals, but that would lead to this:

the Arduinos then would have to spend much more time looking for the requests. My Arduino programs utilize specific delay() times (like when they are moving the solar panels) so interrupts would be a problem in maintaining proper timing.

Regarding which I'd say if your ISR just sets a volatile boolean indicating a request is ready, then you handle that outside the ISR in your main loop, the ISR is unlikely to take more than a few microseconds to execute, which I doubt is going to create any timing problems for you moving solar panels.

However, doing things the other way around should not be hard if you are determined to avoid any possible interference. When new data is ready, send an interrupt to the Pi using a non I2C pin; the Arduino could then wait for the request, which should be very quick, reply, and continue on.

Is there a good way to set up the Rpi3 to wait for the data and process it as it comes in?

Probably not via I2C, although you could try and see what happens if you request information from a slave allowing an indeterminant amount of time for the request to complete, then just implement things on the Arduino such that you assume such a request is always pending (which it could be if this works, and you do the pi side implementation appropriately). It may be that such requests will fail quickly, but that could be leveraged by making requests at intervals and only processing the ones that don't throw an error.

Otherwise you'd have to poll for information at intervals, but that would lead to this:

the Arduinos then would have to spend much more time looking for the requests. My Arduino programs utilize specific delay() times (like when they are moving the solar panels) so interrupts would be a problem in maintaining proper timing.

Regarding which I'd say if your ISR just sets a volatile boolean indicating a request is ready, then you handle that outside the ISR in your main loop, the ISR is unlikely to take more than a few microseconds to execute, which I doubt is going to create any timing problems for you moving solar panels.

However, doing things the other way around should not be hard if you are determined to avoid any possible interference. When new data is ready, send an interrupt to the Pi using a non I2C pin; the Arduino could then wait for the request, which should be very quick, reply, and continue on.

Is there a good way to set up the Rpi3 to wait for the data and process it as it comes in?

Probably not via I2C, although you could try and see what happens if you request information from a slave allowing an indeterminant amount of time for the request to complete, then just implement things on the Arduino such that you assume such a request is always pending (which it could be if this works, and you do the pi side implementation appropriately). It may be that such requests will fail quickly, but that could be leveraged by making requests at intervals and only processing the ones that don't throw an error.

Otherwise you'd have to poll (sucessfully) for information at intervals, but that would lead to this:

the Arduinos then would have to spend much more time looking for the requests. My Arduino programs utilize specific delay() times (like when they are moving the solar panels) so interrupts would be a problem in maintaining proper timing.

Regarding which I'd say if your ISR just sets a volatile boolean indicating a request is ready, then you handle that outside the ISR in your main loop, the ISR is unlikely to take more than a few microseconds to execute, which I doubt is going to create any timing problems for you moving solar panels.

However, doing things the other way around should not be hard if you are determined to avoid any possible interference. When new data is ready, send an interrupt to the Pi using a non I2C pin; the Arduino could then wait for the request, which should be very quick, reply, and continue on.