Notes on reinforcement schedules

•	The manipulandum is not visible for a schedule that doesn't need one (i.e. no manipulandum is shown for a completely noncontingent schedule, other than an extinction schedule).

•	The manipulandum is not visible when the response marker replaces it for a brief time.

•	The manipulandum is not visible when any reinforcement device is busy (unless the schedule is a delayed-reinforcement schedule).

•	The manipulandum is not visible during a timeout (see below).

•	The manipulandum is not visible if the schedule has been stopped (i.e. after it's met a stopping criterion).

•	The manipulandum is visible during a changeover delay from another schedule (e.g. if you have a left and a right schedule, and you respond on the left one, the right schedule will ignore responses during the changeover delay but the right manipulandum will remain visible).

Ticks occur once per second and come from a clock whose timing is not altered. They are sent to the schedule(s), and may (for example) deliver or prime reinforcement. Ticks are blocked during timeouts. Ticks are not blocked by reinforcement (unless a timeout is occuring simultaneously).

When two concurrent schedules are running, MonkeyCantab flips a coin internally, each time, to determine which one gets its tick first. (Why? Because otherwise there would be a bias towards one schedule, which might consistently reinforce and therefore, under appropriate timeout conditions, block the other from doing so.)

Timeouts prevent responding and prevent ticks going to the schedule (so the schedule is effectively paused).

Note that reinforcement device being "busy" also prevents responding - but it doesn't prevent ticks. So if you want a schedule properly paused for the duration of reinforcement, set up a timeout that's the same duration as the reinforcer (or longer). Reinforcers report their total duration in their summary description, to make this easier.

Note that the pause is not phase-locked, in the sense that timeouts block ticks but don't alter the clock phase. For example:

What happens when you request a timeout on a delayed-reinforcement schedule? Should the timeout occur at the time of the response, or at the time of the reinforcement? Well, a timeout is to stop you responding, so it should occur at the time you respond; that's what will happen.

Timeouts, versus the lack of a response object, and application to combined contingent/noncontingent schedules

In a few schedules, which combine response-contingent and response-noncontingent reinforcement, it is important to know exactly when contingent and noncontingent schedules are active. Noncontingent schedules are only blocked by timeouts; contingent schedules are also ineffective if there's nothing to respond on! In particular, response manipulanda are not displayed when the reinforcing device is busy (except for delayed reinforcement schedules).

Therefore, in these circumstances, you will probably wish to ensure that your timeout extends beyond the reinforcement-device-busy-time, or your noncontingent schedule may resume operation before your contingent schedule does.

Temporal reinforcement conflict with a single reinforcer (reinforcers that try to overlap)

It is possible to cause reinforcement conflicts in this task. Most particularly, if you use a delayed-reinforcement schedule, it is possible that reinforcement is scheduled while the reinforcing device is busy. SimpleSchedules ignores requests for reinforcement for devices that are busy. It records in the event log (text-based and ODBC) whether a scheduled reinforcement was actually given.

Reinforcement conflicts are unlikely with brief reinforcers (e.g. a pellet dispenser that triggers using a 45-ms pulse and can operate quite fast). They are very likely if you use a delayed-reinforcement FR-1 schedule and a slow reinforcer (e.g. a 10-second pump).

What happens when your schedule wants to reinforce, and to give you a timeout, but your reinforcement device is busy? The tasks will not reinforce (because the device is busy reinforcing you anyway) but it will implement your timeout.

As the task stands, it will abort an ongoing reinforcer when a new one starts. For example, if your left schedule delivers a reinforcer, and then soon afterwards the right schedule delivers a reinforcer; the left one will be aborted (if it's still ongoing) and the right one started.

Why? Not least, because of the complexity of interpretation when a single licker drives lick-contingent reinforcement with two pump reinforcers simultaneously.

If this would be a problem, you probably want to enable "Timeouts on one schedule apply to both schedules, if two are running". That will prevent the problem.

Changeover delays are "invisible"; the schedule whose responses have been temporarily disabled will still show its manipulandum.