problem with PCIe parallel port in EPP mode

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

--
www.wescottdesign.com

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

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

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

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

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

Are you running LinuxCNC under RTAI?

--

Rick

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

Jon, on the read operation, could you see if the data returned to the computer was correct?

Hul

J> I've been making motion control devices that connect to the parallel port in

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

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

No data could possibly be returned to the computer, as the DATASTB/ pulse was never generated. The target device waits for DATASTB/ to become active with WRITE/ high (inactive write) to send data.

So, the whole problem is when you write to the EPP data port it DOES generate DATASTB/ with WRITE/ low, but when you read from the EPP data port with an INB instruction, it is SUPPOSED to generate DATASTB/ with WRITE/ high, but the DATASTB/ never pulses.

The Saba board with the NetMos 9900 chip works fine (as did a bunch of older Oxford chips, and others.)

While it is possible I'm doing something really odd, registers set to strange values or whatever, this code has been used on dozens of different MoBo parallel ports and at least half a dozen PCI cards without trouble. To change from write to read, I only flip one bit of the control register.

Jon

are you using a driver(parport/ppdev?) or accessing the ports directly from userspace? is a driver loaded? will it interfere?

I just use some functions by including io.c, these are inb and outb, which are supposedly X86 instructions. But, not completely clear what these functions freally do at the hardware level.

I have a diagnostic that runs in userspace (with sudo priviledges.)

The actual CNC program (LinuxCNC) runs real time tasks as either kernel modules under RTAI or as user-space real time tasks under Xenomai or rt- preempt.

These all run without using a classic device driver. We have a routine in our API that reserves the use of the port, and releases it when done, so it is not SUPPOSED to cause any interference.

Jon

Your os is Linux? Your program runs in userspace? what does lsmod | grep parport and lsmod | grep ppdev show? any suspicious dmesg messages?

The diagnostic does, yes.

These are really uninformative, yes these two drivers are loaded.

No. But, the problem is that code that has been running with almost any EPP-capable parallel port for 15 years doesn't work with ONE SPECIFIC PCIe interface chip. Works fine with all Dell motherboard parallel ports, works fine with SIIG and a few other PCI cards, works fine with the Saba PCIe card, but not the Oxford OXPCIe952 chip on different manufacturer's parport cards.

The specific problem is when you write (OUTB instruction) to either the EPP data or address I/O port, it sets write, puts the data on the bus, and generates the appropriate DATASTB/ or ADDRSTB/ pulse, handshaked by the WAIT/ line. But, when you read from the data port (INB) it does NOT generate the DATASTB/ pulse, as it is supposed to. I can't see, from the EPP definition, how this could be considered correct behavior. They have changed SOMETHING in the logic in this chip.

Anyway, now that I have identified at least one PCIe parport card that works flawlessly, I can just tell people to buy that model. (I've got another one coming from China that I will test, so hopefully I have a 2nd source.)

Jon

It's because I've seen the parport module come up with different defaults for different hardware in the past. And there's interrupt handling code in there and stuff. You want to avoid loading it altogether during your boot sequence to make sure it won't interfere.

The symptom is write commands (OUTB) to the EPP address and data ports work perfectly, read commands (INB) to the data port appear to be ignored. We do not use the interrupt function at all. We do not use any driver code, we use CPU hardware instructions that read/write the device's I/O registers directly.

Since the write commands work, we know we have the right I/O port addresses. We change one bit in the command register to set the port to read mode, and then issue the read command, and nothing happens.

Jon

ts

in

ot

rk

do

es.

nd

SPP vs. EPP mode ?

-Lasse