Ce mode permet d'interrompre le programme d'application principal par un signal d'interruption physique extérieur. Ce signal arrête l'exécution du programme logique principal par l'UC Quantum et force l'UC à démarrer le traitement événementiel configuré pour l'entrée associée. Les données d'entrée d'interruption émises vers l'UC Quantum sont traitées à leur réception et sont lues par l'UC à l'aide d'une connexion matérielle sur le système d'embase.

Les interruptions matériel et temporisateur sont traitées dans l'UC Quantum de la même manière. Les deux systèmes utilisent des événements pour le gestionnaire d'interruptions. Au sein du gestionnaire d'interruptions, le programme d'application utilisateur détermine les étapes nécessaires à la gestion de l'interruption. Dans tous les cas, au sein de ce gestionnaire, si des entrées supplémentaires doivent être lues ou si des sorties doivent être écrites, les blocs fonction E/S immédiates IMIO_IN et IMIO_OUT s'en chargent (pour de plus amples informations, voir : Bloc fonction d'E/S directes IMIO_IN et Bloc fonction d'E/S directes IMIO_OUT). Les blocs fonction IMIO peuvent lire ou écrire des informations d'E/S depuis l'embase locale. Par exemple, si une interruption survient et que la logique a besoin de savoir la position actuelle résidant sur le module compteur rapide, le bloc fonction IMIO_IN est activé et lit la position de manière asynchrone par rapport au cycle. Ces informations peuvent ensuite être utilisées dans la section logique du gestionnaire d'interruptions pour prendre plusieurs décisions logiques établies sur la position et, à la fin du programme, mettre à jour un module de sortie local à l'aide du bloc fonction IMIO_OUT, terminant ainsi le programme du gestionnaire d'interruptions.

Les interruptions peuvent être déclenchées plusieurs fois par cycle, comme l'indique le schéma ci-dessous, avec un impact minimal sur l'ensemble du cycle de la plupart des applications. Il existe cependant des applications où la durée du cycle est relativement courte (10 ms) et l'application requiert une interruption toutes les millisecondes. L'utilisation du traitement des interruptions permet de traiter plus rapidement les sections critiques par rapport au reste de l'application. Toutefois, vous devez garder à l'esprit qu'il se peut que vous demandiez à l'automate de traiter un nombre d'interruptions plus élevé qu'il n'est capable d'en gérer. Nous recommandons aux utilisateurs de créer un chronogramme afin de vérifier que l'utilisation de interruptions ne représente pas plus de 40% du temps de traitement total de l'automate. Un pourcentage supérieur signifierait que le processus est totalement occupé par les interruptions au détriment du reste du programme d'application. Pour ces applications, il est conseillé de fragmenter l'application sur plusieurs processeurs. Le taux d'utilisation des interruptions est également essentiel pour déterminer l'impact sur le cycle. Il s'agit du temps qu'une même interruption passe à demander à l'automate une prise en charge.

L'impact sur le cycle dépend de la taille de la section du segment de sous-programme à exécuter. Le temps passé à résoudre la logique du sous-programme du gestionnaire d'interruptions peut être calculé en ajoutant les temps d'exécution des instructions utilisés dans le sous-programme donné.

Dans la zone de traitement des interruptions, les performances sont mesurées de l'arrivée du signal d'entrée au module d'entrée jusqu'au changement d'état d'un point de sortie, en prenant en compte tous les éléments compris entre ces deux points ; ce qui implique les temps d'attente du module d'E/S, la gestion système de l'automate pour le traitement des interruptions et la taille du gestionnaire d'interruptions, comme l'illustre le schéma ci-dessous.