The Math Forum

Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Math Forum » Discussions » Software » comp.soft-sys.matlab

Notice: We are no longer accepting new posts, but the forums will continue to be readable.

Topic: Execution Time of xpctarget faster than Real-Time
Replies: 1   Last Post: Oct 11, 2013 10:00 AM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]
Gordon Weast

Posts: 734
Registered: 12/7/04
Re: Execution Time of xpctarget faster than Real-Time
Posted: Oct 11, 2013 10:00 AM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply


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

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.

Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© The Math Forum at NCTM 1994-2018. All Rights Reserved.