When you have a hardware issue like this with xPC Target, you should contact MathWorks tech support and it will get routed to one of us to work on.
Now, there is a problem with PCI parallel ports.
First, the parallel port hardware is very primitive. It does not latch the existence of an input pulse. There is no way to determine if the parallel port was really the source of the interrupt if the hardware is sharing the same IRQ with other devices. So, if you use that IRQ and another device interrupts, we run the model. This is the main issue with this.
If you disconnect xpcexplr from the target and don't use external mode, the number of interrupts should be more correct. How does the timing look if you unplug the Ethernet cable?
There's another problem. On many PCI parallel port boards, an additional register has to be written to enable the interrupt. Our code doesn't know about that register since it's different on different boards. You may not get any interrupts. You can still use the input/output pins as digital IO, but the interrupt won't work. You could customize the start/stop code to work on your specific board.
Many BIOS setups allow you to assign different IRQs to different slots, but some (perhaps yours) just assign the same IRQ to all PCI slots.
It sounds like your motherboard has a legacy parallel port. The assignments to the legacy port, IRQ 7 and 0x378 are only relevant to the legacy port. They have nothing to do with the PCI parallel port. The machine builder may have simply not brought the legacy port out to a connector. In that case, there may be a header inside the box on the motherboard that's disconnected that you could possibly connect the interrupt to.
It's also possible that the bus interface chip set has the parallel port, but no external connections that you could use. Then you're stuck.
If none of this help, then contact tech support for more followup.
Gordon Weast xPC Target Development MathWorks
Nicolas wrote: > Hi all, > > We use an xpctarget for realtime robot control, which gets an external > interrupt (from a Linux computer) over parallel port. > > With our old setup (r2009a) and our older xpctarget PC everything works > fine. > > However, we are replacing the old xpctarget computer with a newer > machine and have difficulties with the xpctarget execution time. > > The target options are: > Execution mode: Real-Time > Real-time interrupt source: 7 > I/O board generating the interrupt: Parallel_Port > ISA base adress: 0x378 > > With the old xpctarget computer this works fine, however with the new > computer we have several differences and difficulties: > -parallel port is now a PCI card not on board > -even if AMI BIOS entry for the parrallel port is set to 0x378, IRQ7 the > getxpcpci('all') shows an IRQ of 11 for the parallel port and the model > cannot run. > > We can get the model to run with our new computer by changing the AMI > BIOS entry for the parallel port to 0x378 IRQ=(5,7,10,11,12) and > changing the xpctarget option "Real-time interrupt source" to 11. > However, then the execution time shown on the xpctarget runs faster than > Real-Time. > Interestingly, the xPCTargetTime block with the standard division of > 1.139 runs in seconds, whereas the excecution time runs way too fast. > > We have tried several different settings (e.g. using another ISA base > adress e.g. 0x278) or all the three possible settings in the AMI BIOS > for the IRQ channel: > - IRQ5 > - IRQ7 > - IRQ(5,7,10,11,12) > But we experienced the same behavior. > > I am afraid that the xpc gets more interrupts than the Linux sends > because it uses IRQ11 for a lot of different cards (e.g. also > EthernetControllers) and therefore might just receive more interrupts > than 1 every ms and therefore run too fast. > However, I am confused, that the getxpcpci('all') always tells me IRQ11 > independant of BIOS settings. > I am also confused because the xPCTargetTime block seems to work correctly. > > I have also tried to use different PCI slots for the parallel port and > remove all other PCI cards, but without success (there are still other > mainboard components using IRQ11 according to getxpcpci('all'). > > However, I am pretty sure the signal sent from our Linux computer over > parallel port is timed correctly as it has been working with the old > xpctarget on IRQ7 and the functionality of the xPCTargetTime block with > the new computer. > > Do you have any ideas how to ressolve this? > What would be possible steps to ressolve this? > Did we forget any setting? > Does the execution time shown on the xpcTarget matter at all? Or does it > run according to the time given from the xPCTargetTime block? > > Thanks a lot for your help, I appreciate any hints. >