I see the IRQ line in the wiring but find no description of it’s use by user programs. Any information on what if any use the IRQ line has for a user application. Is there a way to minimize serial polling by setting up certain I/O modules to trigger such an interrupt on an input change? What about counter or timer done, etc?
The IRQ lines were introduced a long long time ago on Mistic I/O, basically working as a kind of reversed RS485 comms line where any of the Mistic bricks could send an IRQ signal back to FactoryFloor based controllers, which would execute the Interrupt chart logic in the next available controller processing timeslice.
For compatibility, these are maintained on all serial based brains today. You can consult Chapter 3 of the mistic protocol guide 0270 manual for detailed information and examples. http://documents.opto22.com/0270_Mistic_Protocol_Manual.pdf
Although initially dropped by early versions of PAC Control, interrupt software support was reintroduced as from PACControl 8.2, where you can wire Mistic Bricks, and RS485 based brains B3000, B3000-B etc (and even SNAP-PAC-SB) brains to the serial COM ports on PAC-S1/PAC-S2 controllers. Mistic based command support is only possible by opening legacy support in PAC Control Professional.
Its fair to say that this concept has been widely replaced on Ethernet brains, either by using local memory mapped Event/Reaction logic on PAC-EB brains or by distributing PAC Control logic down to PAC-R controllers, on the same I/O rack.
Unless you have some specific preference for serial-based communication, using these features on Ethernet brains should be good enough for most applications. E/R capabilities are much more powerful than the previous single event/IRQ capabilities. But old-school RS485 Interrupt based logic is still supported, and will still work if wired and could even provider faster response in some instances, due to the lack of communication overhead.