I’m a programmer but I’m new to Arduino so I didn’t recall that the loop function was actually built in, so to speak.
Well then, go install the Arduino IDE, get an Arduino UNO and start working through exercises with it, simply to develop familiarity with the system. Start having fun!
I see help on multiple sketches in one sketch, but I’m not sure that’s exactly what I’m looking for. It would need to actually stop the “sweep” sketch, go to the IR motion detector sketch and when that was invalid (no more movement in front of the IR) it would go back to the sweep program.
Multiple modules in one sketch is precisely what you are looking for.
Now note - when you say “stop the sweep sketch”, what you mean is that this particular module - which effectively runs in a loop - contains at the point of looping, a “switch” to determine when to cease and proceed to the alternate function, and the same for that alternate function.
There are actually two ways to do this.
Noting that all programs (or “modules”) execute as a loop, you can either have the two occurring sequentially in your main loop, each in its own loop out of which it breaks in order to permit the other to take over, or you can make the main loop() the only loop, and on each pass, use a “switch” to decide whether one or the other function will be performed on that pass through the overall loop.
As you might guess, the latter approach is favoured as it is by far the most flexible since it permits and is required for “multi-tasking” where more than one - or two - functions are to be performed effectively simultaneously as necessary by alternately performing a single defined step in the process of each. This single step would correspond to a traversal of the operating loop of that particular process if it were the only process running in its own loop.
The consequence of this is that no process is permitted to “busy wait” - to loop in any way within itself dependent on any event. Any event which is waited upon is tested, and if it is not ready for action, then the code simply passes on to whatever code follows that is not dependent on that event in the secure expectation that after all other potential events have been “polled” the code will loop back around to this one.
This mind-set is absolutely critical to writing “real world” applications, so you need to learn it at the point of this exercise, particularly as you probably intend to add further “features”.