Do you have a question? Post it now! No Registration Necessary
Threaded View
Subject
- Jon Elson
April 13, 2016, 4:46 pm
Reply
Save
Print
I've been making motion control devices that connect to the parallel port in
EPP mode since 2001. I had some problems many years ago with non-compliant
EPP implementations on motherboard multi-I/O chips and PCI cards, but it
seemed they got it figured out and they all worked since about 2006.
Then, I got a SIIG PCIe card a few days ago with the Oxford OXPCIe952 chip,
and it didn;t work with code that has been fine for almost 15 years.
Breaking out the logic analyzer, I found that all output operations were
fine (with bit 5 of the control reg set to 0) but when setting bit 5 of the
control reg to 1 to read, and giving the INB command to the EPP data
register, it produces no DATASTB/ pulse.
Anybody have any ideas what is going on? I think 3 generations of Oxford
chips in PCI cards have worked fine with the same code. I tried a number of
variations in the code to see if I could make it work with the Oxford 952
chip, but couldn't get anything to change.
Thanks in a dvance for any ideas!
Jon
EPP mode since 2001. I had some problems many years ago with non-compliant
EPP implementations on motherboard multi-I/O chips and PCI cards, but it
seemed they got it figured out and they all worked since about 2006.
Then, I got a SIIG PCIe card a few days ago with the Oxford OXPCIe952 chip,
and it didn;t work with code that has been fine for almost 15 years.
Breaking out the logic analyzer, I found that all output operations were
fine (with bit 5 of the control reg set to 0) but when setting bit 5 of the
control reg to 1 to read, and giving the INB command to the EPP data
register, it produces no DATASTB/ pulse.
Anybody have any ideas what is going on? I think 3 generations of Oxford
chips in PCI cards have worked fine with the same code. I tried a number of
variations in the code to see if I could make it work with the Oxford 952
chip, but couldn't get anything to change.
Thanks in a dvance for any ideas!
Jon
Re: problem with PCIe parallel port in EPP mode
Tim Wescott wrote:
USB is not, in a sense, real time. It is desinged to give regular bursts of
data, but if you want to read position, calculate PID and send velocity, all
in 1 ms, it gets VERY difficult. If you want to hand off a block of points
to hit to some microcontroller, and just keep feeding it waypoints, you can
do that with USB. If you want to have the PC's processor in the servo loop,
USB doesn't work. One advantage of having the PC in the loop is that you
can plot a whole bunch of parameters in real time when setting the system
up.
So, we have strong reasons to NOT use USB for real time motion control in
the LinuxCNC project.
Jon
USB is not, in a sense, real time. It is desinged to give regular bursts of
data, but if you want to read position, calculate PID and send velocity, all
in 1 ms, it gets VERY difficult. If you want to hand off a block of points
to hit to some microcontroller, and just keep feeding it waypoints, you can
do that with USB. If you want to have the PC's processor in the servo loop,
USB doesn't work. One advantage of having the PC in the loop is that you
can plot a whole bunch of parameters in real time when setting the system
up.
So, we have strong reasons to NOT use USB for real time motion control in
the LinuxCNC project.
Jon
Re: problem with PCIe parallel port in EPP mode
PCs are not, in most senses, real time. I'm surprised you've done as
well as you have.
I've never seen anyone construct a serious controller on a PC under a
non-real time operating system... but then I don't get out much.
I don't get the parameter plotting thing. Why can't you use a USB
connected processor that is powerful enough to do the job using the PC
as a remote keyboard and display in a sense? GUI on the PC, real time
guts on the USB MCU. I don't get why this can't work well and get
around the lack of real time I/O hardware on the PC?
Sorry I don't have any suggestions for making your parallel port work
better. Have you contacted Oxford? Or do they not support operations
other than printer comms?
--
Rick
Rick
Re: problem with PCIe parallel port in EPP mode
Den torsdag den 14. april 2016 kl. 21.25.12 UTC+2 skrev rickman:
usb have lots of bandwidth there is no reason you can't plot the same
parameters of something running in a USB device. people manage to tune
and debug complex control systems running on embedded devices all the time
lots of cnc run by mach3, it's running on windows!
anything is possible, but using a pc with "dumb" IO seems to still be the
norm
letting the PC do the heavy lifting with planning the optimum movements
and then use some cheap MCU on usb to actually do it seems like it would
be the more sensible option
I run a cnc from a cheap arm board and I've often thought if it wouldn't
be possible to to tack that onto linuxcnc to get all the features
-Lasse
usb have lots of bandwidth there is no reason you can't plot the same
parameters of something running in a USB device. people manage to tune
and debug complex control systems running on embedded devices all the time
lots of cnc run by mach3, it's running on windows!
anything is possible, but using a pc with "dumb" IO seems to still be the
norm
letting the PC do the heavy lifting with planning the optimum movements
and then use some cheap MCU on usb to actually do it seems like it would
be the more sensible option
I run a cnc from a cheap arm board and I've often thought if it wouldn't
be possible to to tack that onto linuxcnc to get all the features
-Lasse
Re: problem with PCIe parallel port in EPP mode
There are several real time options for Linux. RTAI is not keeping up with
the latest kernels, but if you don't mind running a few year old kernel, it
can produce real time latency jitter of around 5 us on selected
CPU/motherboard combinations. Most CPU/mobos can do under 15 us jitter.
We've been doing this since 1997 (using ISA plug-in cards), and I've been
making hardware for it since 2001 (using EPP parallel port.)
Jon
Re: problem with PCIe parallel port in EPP mode
rickman wrote:
Yes, exactly. But, there are now other options, Xenomai and rt-preempt,
although these don't give as good latency as rtai. They are getting much
closer, though, and have much better debug capabilities, as the RT
components run in user space, rather than kernel space.
Also, an offshoot is Machinekit, mostly aimed at ARM platforms like the
Beagle Bone.
Jon
Yes, exactly. But, there are now other options, Xenomai and rt-preempt,
although these don't give as good latency as rtai. They are getting much
closer, though, and have much better debug capabilities, as the RT
components run in user space, rather than kernel space.
Also, an offshoot is Machinekit, mostly aimed at ARM platforms like the
Beagle Bone.
Jon
Re: problem with PCIe parallel port in EPP mode
Den torsdag den 14. april 2016 kl. 23.50.50 UTC+2 skrev Jon Elson:
The beagle bone has a programmable realtime unit, basically a 32 bit 200MHz
cpu with fast IO and access to memory and peripherals.
Has anyone worked on moving the real time stuff to that?
-Lasse
The beagle bone has a programmable realtime unit, basically a 32 bit 200MHz
cpu with fast IO and access to memory and peripherals.
Has anyone worked on moving the real time stuff to that?
-Lasse
Re: problem with PCIe parallel port in EPP mode
Lasse Langwadt Christensen wrote:
Yes. Charles Steinkuehler did all the heavy lifting. So, the way
Machinekit works, now, is they still have a 1 ms real time task on the ARM,
that spoon feeds the PRUs position waypoints. Then, the PRU does the step
generation to hit those waypoints on time. This seems to be working quite
well, and they can run 6 stepper tasks and 5 PWM tasks all at once.
I did another project using his framework for the PRU to run a laser
photoplotter. I make up a file with run length encoded pixels (500 pixels
of laser off, 53 pixels laser on, 192 pixels laser off, etc.) So it is a
16-bit token with an on/off bit followed by 15 bits of count. The PRU has
to unpack this and spoon feed the laser a bit every 5 us. Works like a
champ, and replaces an ancient PC running Windows 3.1 with an ISA bus DMA
card.
Jon
Yes. Charles Steinkuehler did all the heavy lifting. So, the way
Machinekit works, now, is they still have a 1 ms real time task on the ARM,
that spoon feeds the PRUs position waypoints. Then, the PRU does the step
generation to hit those waypoints on time. This seems to be working quite
well, and they can run 6 stepper tasks and 5 PWM tasks all at once.
I did another project using his framework for the PRU to run a laser
photoplotter. I make up a file with run length encoded pixels (500 pixels
of laser off, 53 pixels laser on, 192 pixels laser off, etc.) So it is a
16-bit token with an on/off bit followed by 15 bits of count. The PRU has
to unpack this and spoon feed the laser a bit every 5 us. Works like a
champ, and replaces an ancient PC running Windows 3.1 with an ISA bus DMA
card.
Jon
Re: problem with PCIe parallel port in EPP mode
And, I just got another cheap PCIe parallel port card from China, that is
even less functional than the Oxford chipset one. This one behaves like it
has no EPP funtionality at all. PCI enumeration lists it as serial only,
but it seems to do SPP/Bidir, too.
So, right now, I only know of ONE PCIe plug in card that works, with the
MosChip 9900. This appears to be going obsolete, now there's the MosChip
9901. I will have to test that one, hopefully they didn't break any
functionality.
Jon
Re: problem with PCIe parallel port in EPP mode
snipped-for-privacy@gmail.com wrote:
Express/dp/B003D3MFHC/ref=pd_rhf_pe_p_img_12?ie=UTF8&refRID=HVCHWQYKE5NTM06V6DFR
Yup, the one with the chip mounted at 45 degrees is the one that I have
shown to work in all modes. I probably need to get a sample of the newer
one with the MCS9901 chip and find out if it works, too.
Jon
Express/dp/B003D3MFHC/ref=pd_rhf_pe_p_img_12?ie=UTF8&refRID=HVCHWQYKE5NTM06V6DFR
Yup, the one with the chip mounted at 45 degrees is the one that I have
shown to work in all modes. I probably need to get a sample of the newer
one with the MCS9901 chip and find out if it works, too.
Jon
Re: problem with PCIe parallel port in EPP mode
On Thursday, April 14, 2016 at 11:50:52 AM UTC-7, Jon Elson wrote:
Parallel ports on the PCI bus work essentially the same way, through deferred procedure calls. No such thing as "real time" on a PC anymore, if there ever was. Your best bet is to plan accordingly.
-- john, KE5FX
Parallel ports on the PCI bus work essentially the same way, through deferred procedure calls. No such thing as "real time" on a PC anymore, if there ever was. Your best bet is to plan accordingly.
-- john, KE5FX
Re: problem with PCIe parallel port in EPP mode
John Miles, KE5FX wrote:
NIST has been been doing this since 1996 or so, I started using the EMC
program in 1998. We got about 10 us jitter on a 100 MHz pentium classic,
which was sure good enough for regular motion control.
I'm now using LinuxCNC (the successor of the old EMC and EMC2 program) and
on a good motherboard you can get jitter down to about 4 us. I've sold
about 300 motion control interfaces that use the EPP parallel port, it has
worked fine for years. When using the RTAI real time package, as far as I
know, an INB or OUTB instruction is just what it says, read or write a byte
from an I/O port.
Jon
NIST has been been doing this since 1996 or so, I started using the EMC
program in 1998. We got about 10 us jitter on a 100 MHz pentium classic,
which was sure good enough for regular motion control.
I'm now using LinuxCNC (the successor of the old EMC and EMC2 program) and
on a good motherboard you can get jitter down to about 4 us. I've sold
about 300 motion control interfaces that use the EPP parallel port, it has
worked fine for years. When using the RTAI real time package, as far as I
know, an INB or OUTB instruction is just what it says, read or write a byte
from an I/O port.
Jon
Re: problem with PCIe parallel port in EPP mode
I've always wondered how much buffering goes on with those.
Obviously(?), you can't get a parallel port going into the nanoseconds (Fclk
= 8MHz, at least in the original case). PCI (33MHz+) PPs exist, so are they
inserting wait states, or what?
Are IO instructions cached/buffered, or do they WAIT the CPU until the
transaction is complete? I never looked deep enough to get a clear answer.
I know all the memory space of a Pentium is pulled through caches -- that
was one of its big features after all, internal L1 cache plus expandable
external L2 cache (if you had the money to afford it). And it's very
typical to have PCI cards with large memory apertures, usually directly into
e.g. video or texture RAM, or IO buffers.
Tim
--
Seven Transistor Labs, LLC
Electrical Engineering Consultation and Contract Design
Seven Transistor Labs, LLC
Electrical Engineering Consultation and Contract Design
We've slightly trimmed the long signature. Click to see the full one.
Re: problem with PCIe parallel port in EPP mode
On Tue, 19 Apr 2016 18:34:40 -0500, "Tim Williams"
Depends but generally pipelined. I/O instruction ordering can be
forced but I wouldn't expect it in the general case. PowerPC has an
EIEIO instruction (Enforce In-order Execution of I/O) to accomplish
this, for example.
Main memory is, of course, coherent. Anything mapped into I/O is up
for grabs but probably not coherent. I/O devices generally don't
snoop caches.
Depends but generally pipelined. I/O instruction ordering can be
forced but I wouldn't expect it in the general case. PowerPC has an
EIEIO instruction (Enforce In-order Execution of I/O) to accomplish
this, for example.
Main memory is, of course, coherent. Anything mapped into I/O is up
for grabs but probably not coherent. I/O devices generally don't
snoop caches.
Re: problem with PCIe parallel port in EPP mode
krw wrote:
On X-86 PCs, I/O is a separate address space, so totally separate from the
memory address space. I would think in all systems, out of order execution
and memory tricks must leave I/O order as programmed. Writing GO to the
command register before writing the memory location or disk location could
cause real trouble.
Jon
On X-86 PCs, I/O is a separate address space, so totally separate from the
memory address space. I would think in all systems, out of order execution
and memory tricks must leave I/O order as programmed. Writing GO to the
command register before writing the memory location or disk location could
cause real trouble.
Jon
Site Timeline
- » OT: Bowerbird mating dance
- — Next thread in » Electronics Design
-
- » economics, scary variety
- — Previous thread in » Electronics Design
-
- » diy Gyrotrons?
- — Newest thread in » Electronics Design
-
- » Do You Love Me?
- — Last Updated thread in » Electronics Design
-
- » diy Gyrotrons?
- — The site's Newest Thread. Posted in » Electronics Design
-
- » Potenza trafo incognita
- — The site's Last Updated Thread. Posted in » Electronics Hobby (Italian)
-
XML Sitemap