problem with PCIe parallel port in EPP mode

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: problem with PCIe parallel port in EPP mode
On Wed, 13 Apr 2016 11:46:22 -0500, Jon Elson wrote:

Quoted text here. Click to load it

Make motion-control devices that connect to the USB port instead?

--  
www.wescottdesign.com

Re: problem with PCIe parallel port in EPP mode
Tim Wescott wrote:


Quoted text here. Click to load it
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
On 4/14/2016 2:52 PM, Jon Elson wrote:
Quoted text here. Click to load it

PCs are not, in most senses, real time.  I'm surprised you've done as  
well as you have.


Quoted text here. Click to load it

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

Re: problem with PCIe parallel port in EPP mode
Den torsdag den 14. april 2016 kl. 21.25.12 UTC+2 skrev rickman:
Quoted text here. Click to load it

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


Quoted text here. Click to load it

lots of cnc run by mach3, it's running on windows!

Quoted text here. Click to load it

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

Quoted text here. Click to load it

-Lasse

Re: problem with PCIe parallel port in EPP mode
Lasse Langwadt Christensen wrote:


Quoted text here. Click to load it
I'm not even sure they allow contact from "end users".  I have not found any  
"contact us" for them.  Oxford Semi was bought by PLX, then PLX was bought  
Avago.

Jon

Re: problem with PCIe parallel port in EPP mode
rickman wrote:


Quoted text here. Click to load it
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
On 4/14/2016 4:25 PM, Jon Elson wrote:
Quoted text here. Click to load it

Are you running LinuxCNC under RTAI?

--  

Rick

Re: problem with PCIe parallel port in EPP mode
rickman wrote:

Quoted text here. Click to load it
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:
Quoted text here. Click to load it

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:


Quoted text here. Click to load it
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
Jon Elson wrote:

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
On Wednesday, 27 April 2016 19:50:04 UTC+1, Jon Elson  wrote:

Quoted text here. Click to load it

Is this the one?

https://www.amazon.co.uk/Syba-Port-Parallel-Printer-PCI-Express/dp/B003D3MFHC/ref=pd_rhf_pe_p_img_12?ie=UTF8&refRID=HVCHWQYKE5NTM06V6DFR

John



Re: problem with PCIe parallel port in EPP mode
snipped-for-privacy@gmail.com wrote:

Quoted text here. Click to load it
Express/dp/B003D3MFHC/ref=pd_rhf_pe_p_img_12?ie=UTF8&refRID=HVCHWQYKE5NTM06V6DFR
Quoted text here. Click to load it
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:
Quoted text here. Click to load it

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:

Quoted text here. Click to load it

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
Quoted text here. Click to load it


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
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"

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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:



Quoted text here. Click to load it
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

Re: problem with PCIe parallel port in EPP mode
wrote:

Quoted text here. Click to load it

Sure, you don't want I/O cached, for one thing.

Quoted text here. Click to load it

Forcing in-order execution hits performance.  PowerPC gives the
programmer the option.


Site Timeline