[Emc-users] usb to parport adapter

[ben yates]

I am attempting to build a low-cost motion control
device for a digital camera that would allow for
smooth pan, tilt, and possibly tracking shots (i.e.
for time lapse applications). LinuxCNC combined with
Sherline's 4-axis driver box seems like an ideal fit.
The catch is I need my system to be extremely portable
(I'll be shooting in the woods), and my Powerbook has
no parallel port. Has anyone used a usb to parport
adapter in conjunction with LinuxCNC? I have done
some reading on this issue for linux more generally
(like the USS720 parport driver), but was wondering
how easy this would be to configure with LinuxCNC. My
motion control needs are quite simple, and will
comprise of stepping the motor a certain number of
steps, taking a picture, then repeat. Any help would
be much appreciated.

Thanks,
Ben Yates




__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

[Gene Heskett]

Post by ben yates
I am attempting to build a low-cost motion control
device for a digital camera that would allow for
smooth pan, tilt, and possibly tracking shots (i.e.
for time lapse applications). LinuxCNC combined with
Sherline's 4-axis driver box seems like an ideal fit.
The catch is I need my system to be extremely portable
(I'll be shooting in the woods), and my Powerbook has
no parallel port.

How about a pcmcia slot with a parport card in it? Probably more
money than a usb<->parport adaptor though.

Post by ben yates
Has anyone used a usb to parport
adapter in conjunction with LinuxCNC? I have done
some reading on this issue for linux more generally
(like the USS720 parport driver), but was wondering
how easy this would be to configure with LinuxCNC.

I'm not a real guru, gettin too old for that I think, but it looks as
if that driver has whats required if you've got the cable, a Lucent
Technologies thing. Some of the caveats mentioned in the header of
that file may no longer exist in later versions of the ohci driver,
so it may be possible to use interrupts and the ECP/EPP modes today.
The last mod to that file according to its self contained ChangeLog
was back in 2001, and lots of fixes have been done to the usb
protocols in the last 3 years.

Getting emc to talk to it might take some wrapper coding unless
someone a lot more familiar with it than I currently am knows a
shortcut or 10. So I'll shut up and defer to the real authors of
emc.

Post by ben yates
My
motion control needs are quite simple, and will
comprise of stepping the motor a certain number of
steps, taking a picture, then repeat. Any help would
be much appreciated.
Thanks,
Ben Yates

[Kim Lux]

I've used several USB to serial adapters that work well in Fedora Core
3. They show up just like any other serial device would, except the
file name is different. Ie where normally one would get /dev/ttyS0, you
get /dev/ttyUSB0, for example.

I image a parallel port would work similarly.

The only issue I have is that the serial ports mount with root
permissions, so I have to do a chmod before a user app can access them.
I'm sure there is a way to fix this, I just haven't looked into it.

Post by Gene Heskett

Post by ben yates
I am attempting to build a low-cost motion control
device for a digital camera that would allow for
smooth pan, tilt, and possibly tracking shots (i.e.
for time lapse applications). LinuxCNC combined with
Sherline's 4-axis driver box seems like an ideal fit.
The catch is I need my system to be extremely portable
(I'll be shooting in the woods), and my Powerbook has
no parallel port.

How about a pcmcia slot with a parport card in it? Probably more
money than a usb<->parport adaptor though.

Post by ben yates
Has anyone used a usb to parport
adapter in conjunction with LinuxCNC? I have done
some reading on this issue for linux more generally
(like the USS720 parport driver), but was wondering
how easy this would be to configure with LinuxCNC.

I'm not a real guru, gettin too old for that I think, but it looks as
if that driver has whats required if you've got the cable, a Lucent
Technologies thing. Some of the caveats mentioned in the header of
that file may no longer exist in later versions of the ohci driver,
so it may be possible to use interrupts and the ECP/EPP modes today.
The last mod to that file according to its self contained ChangeLog
was back in 2001, and lots of fixes have been done to the usb
protocols in the last 3 years.
Getting emc to talk to it might take some wrapper coding unless
someone a lot more familiar with it than I currently am knows a
shortcut or 10. So I'll shut up and defer to the real authors of
emc.

Post by ben yates
My
motion control needs are quite simple, and will
comprise of stepping the motor a certain number of
steps, taking a picture, then repeat. Any help would
be much appreciated.
Thanks,
Ben Yates

[Jon Elson]

Post by Kim Lux
I've used several USB to serial adapters that work well in Fedora Core
3. They show up just like any other serial device would, except the
file name is different. Ie where normally one would get /dev/ttyS0, you
get /dev/ttyUSB0, for example.
I image a parallel port would work similarly.
The only issue I have is that the serial ports mount with root
permissions, so I have to do a chmod before a user app can access them.
I'm sure there is a way to fix this, I just haven't looked into it.

No, actually it is much more complicated than that. EMC has motion code
that runs under the real time system (rt-linux or rtai) to send the step
pulses.
The auxilliary I/O runs as a normal Linux program (although with permissions
to access the parallel port directly). Getting the USB adaptor to work from
the real time code will be tricky, but is doable. Getting it to work
simultaneously
with both real time AND linux sounds like a nighmare! I have made mods to
EMC so as to route all auxilliary I/O through the real time section, so that
might be one help. Also, you may not need auxilliary I/O in this
specific application.

Still, it is not going to be a plug it in and go conversion. The
PC-card parallel
port might work better. They seem to look to the hardware pretty much as
a normal parallel port once the BIOS-level driver has configured the unit.

Jon

[Kim Lux]

I don't see your point, Jon. emc generally uses a standard parallel
port, right ?

And which port is set in the emc config file, right ?

ie /dev/parport0 or something like that, right ?

If if does, then change /dev/parport0 in the config file
to /dev/parportUSB0 and it should allow the machine to use a USB
parallel port instead of a regular parallel port.

Whether the parallel port access happens in the main program or in a
another process makes no difference: a USB parallel port acts the very
same as a standard parallel port, or at least that is the way it is for
the USB Serial devices, including things like hardware handshaking and
communicating at 115KBaud.

I was only commenting on the substitution of the USB parallel port and
not anything else.

Kim

Post by Jon Elson
No, actually it is much more complicated than that. EMC has motion code
that runs under the real time system (rt-linux or rtai) to send the step
pulses.
The auxilliary I/O runs as a normal Linux program (although with permissions
to access the parallel port directly). Getting the USB adaptor to work from
the real time code will be tricky, but is doable. Getting it to work
simultaneously
with both real time AND linux sounds like a nighmare! I have made mods to
EMC so as to route all auxilliary I/O through the real time section, so that
might be one help. Also, you may not need auxilliary I/O in this
specific application.
Still, it is not going to be a plug it in and go conversion. The
PC-card parallel
port might work better. They seem to look to the hardware pretty much as
a normal parallel port once the BIOS-level driver has configured the unit.
Jon
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Paul]

I don't see your point, Jon.  emc generally uses a standard parallel
port, right ?

Correct - EMC does use a standard parallel port.

And which port is set in the emc config file, right ?  

The base address is declared.

ie /dev/parport0 or something like that, right ?

NO. The base address of the port is declared.

If if does, then change /dev/parport0 in the config file
to /dev/parportUSB0 and it should allow the machine to use a USB
parallel port instead of a regular parallel port.

IF EMC used file descriptors to communicate with the hardware via the kernel's
own drivers, this *might* work. However, there is absolutely no way that you
could have a deterministic realtime system operating at high speed.

Whether the parallel port access happens in the main program or in a
another process makes no difference: a USB parallel port acts the very
same as a standard parallel port, or at least that is the way it is for
the USB Serial devices, including things like hardware handshaking and
communicating at 115KBaud.

IF you are talking about a user space application that can tolerate the delays
introduced by the USB layer, perhaps. EMC does not use any of the low level
drivers provided by the kernel for any of the realtime code. USB is out,
period.


Regards, Paul.

[Jon Elson]

Post by Kim Lux
I don't see your point, Jon. emc generally uses a standard parallel
port, right ?

Yes, and it accesses it with outb and inb instructions, which access
bytes of
the standard parallel port as I/O addresses. Alpha, PowerPC and most of the
newer architectures (and I think IA-64, too) do not have a separate I/O
path, everything looks like memory. And, I would expect that the
parallel port
on those machines would not be byte (register) compatible with a standard
PC parallel port. The code automatically knows that the status byte can be
read at the address of the data port plus one. It knows that the
control byte
is at the address of the data port plus two. This is not configurable
from the
.ini file, it is wired into the code.

Post by Kim Lux
And which port is set in the emc config file, right ?
ie /dev/parport0 or something like that, right ?

No, it is usually set as IO_BASE_ADDRESS = 0x378
and MOTION_IO_ADDRESS = 0x378

Post by Kim Lux
If if does, then change /dev/parport0 in the config file
to /dev/parportUSB0 and it should allow the machine to use a USB
parallel port instead of a regular parallel port.

No, it accesses the port with inb and outb c macros, which expect to read
or write one byte to/from a specified I/O address.

Post by Kim Lux
Whether the parallel port access happens in the main program or in a
another process makes no difference: a USB parallel port acts the very
same as a standard parallel port, or at least that is the way it is for
the USB Serial devices, including things like hardware handshaking and
communicating at 115KBaud.

Yes, it makes a big difference, as the real time (motion) section of EMC is
running in real mode, and has no kernel services available whatsoever.
It can allocate memory, free memory, return control to the scheduler,
and a few things like that. It has access to a block of sharable structures
that are mapped both in the RT modules and the Linux code, to communicate
back and forth between these components. That is just about it! No printf,
no file system, no stdio, no access to /dev/xxx, and so on. It is basically
running in an environment similar to an embedded microprocessor with a
real time kernel to manage the tasks, but anything beyond scheduling tasks
is left to you to handle.

Jon

[Craig]

Thanks Jon and Paul for your explinations found in the usb to parport
adapter discussion. I now have a beter fundamental understanding of
how EMC works. A couple of pennies droped

Suggestion: It might be usefull to have a short discussion real time
and its constraints in the users manual.
Could save some time answering questions.

Question: How easy is it to switch in and out of real time operation?
e.g. to multiplex real time and full operaing system operation.
Constrainst?

Craig

[Paul]

Hi Craig

One would normally break a task down in to threads that can be run
concurrently. Some threads are inherently non-realtime, such as the user
interface, or file access. Others could be realtime depending on the timing
constraints and penalties involved.

Generally, realtime processes are enabled in kernel space when the module is
inserted - It would be here that you would set the priority and schedule the
frequency. Resources for communications (shared memory, fifos or mail boxes)
would also be allocated at module load time..

A link to some documentation that explains it better than I can..
http://people.mech.kuleuven.ac.be/~bruyninc/rthowto/

For the PowePC and Arm chips, ready to use tools can be downloaded from
http://www.denx.de/e/index1.php

Regards, Paul.

Question:  How easy is it to switch in and out of  real time operation?
e.g. to multiplex real time and full operaing system operation.  
Constrainst?

[Jon Elson]

Post by Craig
Thanks Jon and Paul for your explinations found in the usb to parport
adapter discussion. I now have a beter fundamental understanding of
how EMC works. A couple of pennies droped
Suggestion: It might be usefull to have a short discussion real time
and its constraints in the users manual. Could save some time
answering questions.
Question: How easy is it to switch in and out of real time
operation? e.g. to multiplex real time and full operaing system
operation. Constrainst?

The real time system is available all the time that a rt-modified system
is running.
You have the option to run a real time program, a linux program, or both at
the same time. You don't have to reboot or do anything to switch between
the modes. I move files over the network, edit files, dig through
directories
looking for the right file, use the calculator, read help files, etc.
all while EMC
is running.

Jon

[Ray Henry]

Post by Jon Elson

Post by Craig
Thanks Jon and Paul for your explinations found in the usb to
parport adapter discussion. I now have a beter fundamental
understanding of how EMC works. A couple of pennies droped
Suggestion: It might be usefull to have a short discussion real time
and its constraints in the users manual. Could save some time
answering questions.
Question: How easy is it to switch in and out of real time
operation? e.g. to multiplex real time and full operaing system
operation. Constrainst?

The real time system is available all the time that a rt-modified
system is running.
You have the option to run a real time program, a linux program, or
both at the same time. You don't have to reboot or do anything to
switch between the modes. I move files over the network, edit files,
dig through directories
looking for the right file, use the calculator, read help files, etc.
all while EMC
is running.
Jon

I know that there is work being done on a serial driver, including usb,
for rtai. A search of google will turn up more than 800 hits for the
combination Linux rtai usb driver. I don't have a clue how they expect
to be able to get predictible timing but they seem to be working on it.

Ray

[Kim Lux]

inb and outb are pretty standard functions. They will be present on the
other architectures.

The USB driver presents an interface that looks exactly like a "real"
parallel port. My guess is that inb and outb should work fine with the
USB parallel port and with the other architectures. Linux and Unix are
written for portability.

I'm very interested to hear if this works.

Post by Jon Elson

Post by Kim Lux
I don't see your point, Jon. emc generally uses a standard parallel
port, right ?

Yes, and it accesses it with outb and inb instructions, which access
bytes of
the standard parallel port as I/O addresses. Alpha, PowerPC and most of the
newer architectures (and I think IA-64, too) do not have a separate I/O
path, everything looks like memory. And, I would expect that the
parallel port
on those machines would not be byte (register) compatible with a standard
PC parallel port. The code automatically knows that the status byte can be
read at the address of the data port plus one. It knows that the
control byte
is at the address of the data port plus two. This is not configurable
from the
.ini file, it is wired into the code.

Post by Kim Lux
And which port is set in the emc config file, right ?
ie /dev/parport0 or something like that, right ?

No, it is usually set as IO_BASE_ADDRESS = 0x378
and MOTION_IO_ADDRESS = 0x378

Post by Kim Lux
If if does, then change /dev/parport0 in the config file
to /dev/parportUSB0 and it should allow the machine to use a USB
parallel port instead of a regular parallel port.

No, it accesses the port with inb and outb c macros, which expect to read
or write one byte to/from a specified I/O address.

Post by Kim Lux
Whether the parallel port access happens in the main program or in a
another process makes no difference: a USB parallel port acts the very
same as a standard parallel port, or at least that is the way it is for
the USB Serial devices, including things like hardware handshaking and
communicating at 115KBaud.

Yes, it makes a big difference, as the real time (motion) section of EMC is
running in real mode, and has no kernel services available whatsoever.
It can allocate memory, free memory, return control to the scheduler,
and a few things like that. It has access to a block of sharable structures
that are mapped both in the RT modules and the Linux code, to communicate
back and forth between these components. That is just about it! No printf,
no file system, no stdio, no access to /dev/xxx, and so on. It is basically
running in an environment similar to an embedded microprocessor with a
real time kernel to manage the tasks, but anything beyond scheduling tasks
is left to you to handle.
Jon
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Jon Elson]

Post by Kim Lux
inb and outb are pretty standard functions. They will be present on the
other architectures.
The USB driver presents an interface that looks exactly like a "real"
parallel port. My guess is that inb and outb should work fine with the
USB parallel port and with the other architectures. Linux and Unix are
written for portability.

I'm very interested to hear how they do this. OK, assuming you replace
inb and outb macros with something that translates to the USB, will it do
this with real-time code, too? That is a totally different environment.
Then, can it allow one parallel port to be controlled by BOTH RT and Linux
concurrently? And, what will it do to pulse timing? I think that is
going to
be the death of it, that you can only get 1000 level changes per second,
and that means 500 steps/second, tops. Alternatively, the driver batches
changes into packets, and then does them all as fast as it can when each
packet is sent. This will totally destroy any attempt to make smooth, or
even coordinated moves.

Jon

[Kim Lux]

Here is how they probably* do it: the USB driver creates a virtual
parallel port interface for the application to use. It probably looks
exactly like a real parallel port. A real parallel port is, after all,
a collection of memory locations. When the driver "sees" a change in
the value of one of the virtual memory locations, it sends a command to
the USB device and it manipulates the data (levels) that appear on the
USB connector.

This isn't a slow operation either. The parallel port devices I've seen
are USB2.0 thus support USB data rates to 480 Mb/sec.


* caveat: I have not looked at the code, but I've looked at code for USB
Serial devices and used USB serial devices in some recent development
work.

Interesting fact: I asked a lot of questions before buying the USB
serial device. The salesman told me they didn't work with all Windows
applications and were frequently troublesome. My experience with them
under Linux has been stellar. They hot plug properly and run everything
that I've ever sent at them without problems.

Post by Jon Elson

Post by Kim Lux
inb and outb are pretty standard functions. They will be present on the
other architectures.
The USB driver presents an interface that looks exactly like a "real"
parallel port. My guess is that inb and outb should work fine with the
USB parallel port and with the other architectures. Linux and Unix are
written for portability.

I'm very interested to hear how they do this. OK, assuming you replace
inb and outb macros with something that translates to the USB, will it do
this with real-time code, too? That is a totally different environment.
Then, can it allow one parallel port to be controlled by BOTH RT and Linux
concurrently? And, what will it do to pulse timing? I think that is
going to
be the death of it, that you can only get 1000 level changes per second,
and that means 500 steps/second, tops. Alternatively, the driver batches
changes into packets, and then does them all as fast as it can when each
packet is sent. This will totally destroy any attempt to make smooth, or
even coordinated moves.
Jon
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Stephen Wille Padnos]

Post by Kim Lux
Here is how they probably* do it: the USB driver creates a virtual
parallel port interface for the application to use. It probably looks
exactly like a real parallel port. A real parallel port is, after all,
a collection of memory locations. When the driver "sees" a change in
the value of one of the virtual memory locations, it sends a command to
the USB device and it manipulates the data (levels) that appear on the
USB connector.

Nope. That would be the method that a protected operating system would
use to trap I/O access, and use a driver to send the data elsewhere, but
the Linux kernel doesn't do this to itself. Even if it did, the data
would get bursted to the adapter at USB wire speed after some delay, and
then the "port changes" would get written to the parallel port at its'
"wire speed" - ie, all pulses from the previous USB frame time (1ms for
USB1.1, I believe it's the same for USB 2.0) would be output to the
parallel port as fast as the port could make the state changes (unless
it requires handshaking, in which case the first output would occur, and
the rest wouldn't).

If you used soemthing like DOSEMU to run TurboCNC or the like, then you
would get this type of bunched data output.

Post by Kim Lux
This isn't a slow operation either. The parallel port devices I've seen
are USB2.0 thus support USB data rates to 480 Mb/sec.

Data transfer speed isn't the issue. It's timeliness of the port pin
changes. All that fast data is still split into small chunks that are
sent once per millisecond.

Post by Kim Lux
* caveat: I have not looked at the code, but I've looked at code for USB
Serial devices and used USB serial devices in some recent development
work.
Interesting fact: I asked a lot of questions before buying the USB
serial device. The salesman told me they didn't work with all Windows
applications and were frequently troublesome. My experience with them
under Linux has been stellar. They hot plug properly and run everything
that I've ever sent at them without problems.

Standard serial and parallel usage are a different beast. There are two
things that happen with a standard serial or parallel port - data
transfer and synchronization. Data transfer isn't at issue here, so we
need to think about synchronization. For a printer or almost any serial
device, there's a "busy" signal that tells the PC to stop sending data.
If it's handled by the hardware, then software doesn't need to worry
about it (and it's useless to EMC). If it's handled in software
(XON/XOFF), then the expectation is that the software sending the
information would check to see if it got an XOFF, and not send any more
data until it receives XON - also useless to EMC.

- Steve

[Kim Lux]

Post by Stephen Wille Padnos
Nope. That would be the method that a protected operating system would
use to trap I/O access, and use a driver to send the data elsewhere, but
the Linux kernel doesn't do this to itself.

But I think that emc does do something like this. I agree that in
general Linux uses a device driver to handle pport and serial and other
hardware requests, but I don't think that emc uses that interface. Like
Jon said, I think the real time emc process is inb and outbing the data
to the port. At some level the parallel port is just a memory mapped
hardware device, whether emc accesses it directly or a driver is
inbetween.

Post by Stephen Wille Padnos
Even if it did, the data
would get bursted to the adapter at USB wire speed after some delay, and
then the "port changes" would get written to the parallel port at its'
"wire speed" - ie, all pulses from the previous USB frame time (1ms for
USB1.1, I believe it's the same for USB 2.0) would be output to the
parallel port as fast as the port could make the state changes (unless
it requires handshaking, in which case the first output would occur, and
the rest wouldn't).

I'm using hardware handshaking on a USB serial device using the PL2303
serial driver and it is NOT my experience that any bunching or queuing
is taking place. I actually looked at the handshake signal with a scope
and it looked like the data went (on RS232) as soon as the level was
changed in the code that called it. I wasn't paying particular
attention at the time, but I was trying to see if we had the handshaking
right speed wise and I was checking for delays in rts signaling. I
could set up the scope again and have another look...

A lot of parallel and serial port software depends on "twiddling bits"
for rts, etc. I'd be surprised if these devices acted the way you
say.

Post by Stephen Wille Padnos

Post by Kim Lux
This isn't a slow operation either. The parallel port devices I've seen
are USB2.0 thus support USB data rates to 480 Mb/sec.

Data transfer speed isn't the issue. It's timeliness of the port pin
changes. All that fast data is still split into small chunks that are
sent once per millisecond.

I'm not aware of that delay. I'm trying to think of a way to test it,
for sure, using the serial port. Would the delay happen to disappear if
there is only one device on the bus ?

Post by Stephen Wille Padnos

Post by Kim Lux
* caveat: I have not looked at the code, but I've looked at code for USB
Serial devices and used USB serial devices in some recent development
work.
Interesting fact: I asked a lot of questions before buying the USB
serial device. The salesman told me they didn't work with all Windows
applications and were frequently troublesome. My experience with them
under Linux has been stellar. They hot plug properly and run everything
that I've ever sent at them without problems.

Standard serial and parallel usage are a different beast. There are two
things that happen with a standard serial or parallel port - data
transfer and synchronization. Data transfer isn't at issue here, so we
need to think about synchronization. For a printer or almost any serial
device, there's a "busy" signal that tells the PC to stop sending data.

Yep.

Post by Stephen Wille Padnos
If it's handled by the hardware, then software doesn't need to worry
about it (and it's useless to EMC). If it's handled in software
(XON/XOFF), then the expectation is that the software sending the
information would check to see if it got an XOFF, and not send any more
data until it receives XON - also useless to EMC.

I coincidentally checked out serial handshaking and I didn't see any
delays. Maybe I wasn't looking close enough.

Post by Stephen Wille Padnos
- Steve
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Jon Elson]

Post by Kim Lux

Post by Stephen Wille Padnos
Nope. That would be the method that a protected operating system would
use to trap I/O access, and use a driver to send the data elsewhere, but
the Linux kernel doesn't do this to itself.

But I think that emc does do something like this. I agree that in
general Linux uses a device driver to handle pport and serial and other
hardware requests, but I don't think that emc uses that interface. Like
Jon said, I think the real time emc process is inb and outbing the data
to the port. At some level the parallel port is just a memory mapped
hardware device, whether emc accesses it directly or a driver is
inbetween.

On x-86 hadware, the parallel port is NOT memory mapped! The Pentium
has a totally separate function called I/O, that is parallel to the way
memory
is accessed, but uses different control lines (or different PCI function
commands).
The PC I/O subsystem has 65536 possible I/O addresses. And, yes, you are
right, that EMC does not use any Linux driver for the parallel port. In the
RT code, it just accesses the hardware directly, as it is in real mode. For
the access by the Linux code, it uses a kernel call to ask the OS to open
access to the phisical hardware addresses needed. This is either
ioperm() for
the standard port address of 0x378, or iopl() for ports above 0x7ff. This
causes protection hardware in the Pentium CPU to permit access to selected
I/O address ranges from protected mode programs. Once this access has been
allowed, then the program can access the port hardware directly. A single
CPU instruction is generated by the inb or outb macro, and it communicates
directly through the appropriate bus bridge hardware on the motherboard to
the parallel port chip. This chip usually integrates the floppy drive,
par port
and serial ports on the one chip.

I had to decipher much of this info when figuring out how to perform
IEEE-1284
transfers to my interface boards, without using any drivers or support
software. I had to find all sorts of HIGHLY obscure documents, and trace
the communication from the CPU to the par port chip to make it all work.

Jon

[Gene Heskett]

On Tuesday 30 November 2004 02:10, Jon Elson wrote:
[...]

Post by Jon Elson
On x-86 hadware, the parallel port is NOT memory mapped! The
Pentium has a totally separate function called I/O, that is
parallel to the way memory
is accessed, but uses different control lines (or different PCI
function commands).
The PC I/O subsystem has 65536 possible I/O addresses. And, yes,
you are right, that EMC does not use any Linux driver for the
parallel port. In the RT code, it just accesses the hardware
directly, as it is in real mode. For the access by the Linux code,
it uses a kernel call to ask the OS to open access to the phisical
hardware addresses needed. This is either ioperm() for
the standard port address of 0x378, or iopl() for ports above 0x7ff.

And this is one of the missing bits of info I needed to know, thanks.

Post by Jon Elson
This causes protection hardware in the Pentium CPU to permit
access to selected I/O address ranges from protected mode programs.
Once this access has been allowed, then the program can access the
port hardware directly. A single CPU instruction is generated by
the inb or outb macro, and it communicates directly through the
appropriate bus bridge hardware on the motherboard to the parallel
port chip. This chip usually integrates the floppy drive, par port
and serial ports on the one chip.

What if its actually a group of 82C55's on a pci card thats trying to
look like an ISA card in a pci slot? No bios extensions or any
access support on the card, just I/O and a dipswitch programmable
address decoder. Does this iopl() work for this scenario if the card
is set to respond to $F100 (and up in 4 byte increments)?

Post by Jon Elson
I had to decipher much of this info when figuring out how to perform
IEEE-1284
transfers to my interface boards, without using any drivers or
support software. I had to find all sorts of HIGHLY obscure
documents, and trace the communication from the CPU to the par port
chip to make it all work.

So I'm finding out, even the web is not always the ultimate lookup
machine :)

Post by Jon Elson
Jon

[Jon Elson]

Post by Gene Heskett
What if its actually a group of 82C55's on a pci card thats trying to
look like an ISA card in a pci slot? No bios extensions or any
access support on the card, just I/O and a dipswitch programmable
address decoder. Does this iopl() work for this scenario if the card
is set to respond to $F100 (and up in 4 byte increments)?

Sure. You would use ioperm(0xf100,4,1); to turn on the addresses from
0xf100 through 0xf103 (4 contiguous bytes). The '1' means to enable
access, a zero would disable access.

Jon

[Gene Heskett]

Post by Jon Elson

Post by Gene Heskett
What if its actually a group of 82C55's on a pci card thats trying
to look like an ISA card in a pci slot? No bios extensions or any
access support on the card, just I/O and a dipswitch programmable
address decoder. Does this iopl() work for this scenario if the
card is set to respond to $F100 (and up in 4 byte increments)?

Sure. You would use ioperm(0xf100,4,1); to turn on the addresses
from 0xf100 through 0xf103 (4 contiguous bytes). The '1' means to
enable access, a zero would disable access.
Jon

Well, since there are 4 addresses per chip and 3 chips, then it would
be:

ioperm(0xf100, 0x30, 0x1);

which would enable access from 0xf100 to 0xf12f. I think the first
chip is at 0xf100-03, for portA, 0xf104-7 for portB, 0xf108-B for
portC, and the mode register then is at 0xf10C-F, repeat the sequence
at 0xf110 for chip 2, and 0xf120 for chip 3. Correct?

Then once this is done, then iopl() comes in to set the priority of
the service up?

What about IRQ's that can also come from an 82C55 in some modes, the
default mode 0 comes to mind. (I think, its been 23 years since I
last fooled with an 8255, from the design something around it
viewpoint, and that was using a Z-80 as the driver, so the memory is
in dire need of a few hundred refresh cycles here)

I've a mind to do, because the cabling for output is a simple 34 pin
ribbon cable for the first 3 axis's, use one chip as all outputs, and
the next chip as all inputs, or at least as many as it will take for
3 axis's.

Limit switches: Presumably I'll need a pair of switches for home on
the x/y table, which can be at either end of the table travel, and as
far forward out from under the spindle as the x can safely move
without the leadscrew coming out of the nut.

So 2 microswitches for that are a given. Can the opposite end of the
travel limits be set in a config file, or do these also need
microswitches?

And, since the work piece, unless backed into a cleaned up fixed jig
on the table, is always going to be subjected to how accurately you
can clamp a new piece down when making more than 1 copy, how does one
go about zeroing this error out? But that question is putting the
cart before the horse I haven't bought yet. :-)

I did get the other motor mount made and mounted today, and the
handwheels drilled for the drive pins to engage them, but haven't
made the drive pins and the bar that holds them yet. My shop isn't
heated very well so I had to come in and thaw out my feet after
awhile. Looking at the gearbox innards of these motors, I can see
they will have a fairly low torque limit beyond which the gears will
be damaged, so I'm inclined to do the drive with a piece of steel
strap carrying the drive pins, and just one shouldered bolt into the
center of the sleeve thats setscrewed to the motor shaft, with a
bellvue washer for a breakaway slip clutch. At least it sounds like
a plan for right now.

For the z motion, I think the best thing I can do is ream out the
shaft hole for the drive pinion axle about 1/8" all around, and make
an eccentric bushing so the rack/pinion play can be adjusted down to
something reasonable. The front z wheel has over a full turn of play
in it right now, mostly due to poor pinion to spindle rack
engagement. But thats another day too. One thing at a time, but I
can't stop trying to think ahead either.

I tried to heat the shop 3 years ago, with one of those horizontal,
blowered kerosene jet engine things. It worked fairly well at
heating the shop, but put so much moisture into the air that every
cold tool in it that didn't have a very fresh coat of WD-40 turned
bright red with rust, all in about 30 minutes. As its a wood shop
too, that was a lot of work cleaning up my wood planes, the
mini-lathe, this mill, lots of other hand tools. Needless to say
that heater left rapidly, with 3 of the first 4 gallons of fuel still
in the tank. So if I have anything out there that shouldn't freeze,
there is a 1500 watt electric on a thermostatic switch I can set for
about 35-40 degrees.

But I ramble and its late.

[Jon Elson]

Gene Heskett wrote:
OOPS, wrong info in previous message, ioperm is for below 0x3ff, for above
(PCI address range) you need ioperm(3);
This is all or nothing, the hardware map in the CPU only has 0x400 bits to
map permission for the first 1024 IO ports.

Jon

[Paul]

Hi Jon

From the man pages for iopl and ioperm:

SYNOPSIS

int ioperm(unsigned long from, unsigned long num, int turn_on);

DESCRIPTION
Ioperm sets the port access permission bits for the process for num
bytes starting from port address from to the value turn_on. The use of
ioperm requires root privileges.

Only the first 0x3ff I/O ports can be specified in this manner. For
more ports, the iopl function must be used. Permissions are not inher-
ited on fork, but on exec they are. This is useful for giving port
access permissions to non-privileged tasks.


SYNOPSIS

int iopl(int level);

DESCRIPTION
iopl changes the I/O privilege level of the current process, as speci-
fied in level.

This call is necessary to allow 8514-compatible X servers to run under
Linux. Since these X servers require access to all 65536 I/O ports,
the ioperm call is not sufficient.

Post by Jon Elson
OOPS, wrong info in previous message, ioperm is for below 0x3ff, for above
(PCI address range) you need ioperm(3);
This is all or nothing, the hardware map in the CPU only has 0x400 bits to
map permission for the first 1024 IO ports.

[Gene Heskett]

Post by Jon Elson
OOPS, wrong info in previous message, ioperm is for below 0x3ff, for
above (PCI address range) you need ioperm(3);
This is all or nothing, the hardware map in the CPU only has 0x400
bits to map permission for the first 1024 IO ports.
Jon

Humm, 0x400 bits=1024 ports, or 1024 actual i/o addresses, and I
assume those are addresses on 4 byte wide boundaries due to the
nature of the bus decoding? I have the man page on another screen,
so I can probably figure it out if it wasn't past midnight already.

This is getting interesting, because I might actually learn something!

Thanks Jon.

[Kim Lux]

In case my previous explanation wasn't clear, they don't have to replace
the inb and outb macros. A real parallel port is a piece of memory
mapped hardware. The virtual USB parallel port presents a memory map
that looks like the real parallel port. inb and outb will work on
either the real driver or the virtual driver.

BTW: USB is a pretty low overhead protocol. I can transfer data from an
external hard drive to my laptop internal drive at 20+ MB/sec and only
use 3% of the processor resource. (3GHz P4, 1GB RAM, 800 MHz FSB) The
20 MB/sec is a hard drive speed limitation, not a processor or USB
limitation.

If USB can move 20MB/sec, I don't think it is going to have trouble with
a few stepper motor pulses.

Kim

Post by Jon Elson

Post by Kim Lux
inb and outb are pretty standard functions. They will be present on the
other architectures.
The USB driver presents an interface that looks exactly like a "real"
parallel port. My guess is that inb and outb should work fine with the
USB parallel port and with the other architectures. Linux and Unix are
written for portability.

I'm very interested to hear how they do this. OK, assuming you replace
inb and outb macros with something that translates to the USB, will it do
this with real-time code, too? That is a totally different environment.
Then, can it allow one parallel port to be controlled by BOTH RT and Linux
concurrently? And, what will it do to pulse timing? I think that is
going to
be the death of it, that you can only get 1000 level changes per second,
and that means 500 steps/second, tops. Alternatively, the driver batches
changes into packets, and then does them all as fast as it can when each
packet is sent. This will totally destroy any attempt to make smooth, or
even coordinated moves.
Jon
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Stephen Wille Padnos]

Post by Kim Lux
In case my previous explanation wasn't clear, they don't have to replace
the inb and outb macros. A real parallel port is a piece of memory
mapped hardware. The virtual USB parallel port presents a memory map
that looks like the real parallel port. inb and outb will work on
either the real driver or the virtual driver.

It's not memory mapped (on x86) - there are separate instructions for
I/O operations. This means that there is NO copy of the port value
available to software. There isn't even any guarantee that if you write
a value to a port, that you could read back the same value in the next
processor cycle. This means that a driver can't look for changes in a
memory region to see what should be sent to USB - it would have to trap
the instructions that send the data. Other architectures (68K, PPC,
others) don't have a separate I/O space, so your description could be
closer to reality.

Post by Kim Lux
BTW: USB is a pretty low overhead protocol. I can transfer data from an
external hard drive to my laptop internal drive at 20+ MB/sec and only
use 3% of the processor resource. (3GHz P4, 1GB RAM, 800 MHz FSB) The
20 MB/sec is a hard drive speed limitation, not a processor or USB
limitation.

(an aside - your 800MHz FSB should be able to pump 6.4GB/sec - 3% of
that is 192M/sec, so a rough calculation has the CPU doing 10x the work
that should be necessary for the data transfer - and it should be DMA
anyway, and not even use the CPU that much)

Post by Kim Lux
If USB can move 20MB/sec, I don't think it is going to have trouble with
a few stepper motor pulses.

Even in the scenario you describe, there would be a problem with the
*timing* of the pulses.

Post by Kim Lux
Kim

- Steve

[Kim Lux]

Post by Stephen Wille Padnos
(an aside - your 800MHz FSB should be able to pump 6.4GB/sec - 3% of
that is 192M/sec, so a rough calculation has the CPU doing 10x the work
that should be necessary for the data transfer - and it should be DMA
anyway, and not even use the CPU that much)

This is a copy (move actually) from one Linux mounted partition to
another. It isn't straight DMA, not by a long shot. Both of the
partitions are ext3 and thus journalling, file system nodes, etc, have
to be kept up to date. There is a lot of work for the cpu to do other
than just move the data itself. I also run it konqueror to konqueror so
that I could see a rate as it moved the data. All of this takes
overhead.

To be a fair comparison of USB overhead, one should perform an IDE to
IDE copy (move) and see what happens. I don't happen to have that
capability on this machine.

At this point I need to mention that artsd uses 4% when playing flac
encoded audio. This is all occurring on a Fedora Core 3 installation.


Once again: I'd be very interested to know if the USB parallel port
works for emc.

[Stephen Wille Padnos]

Post by ben yates
I am attempting to build a low-cost motion control
device for a digital camera that would allow for
smooth pan, tilt, and possibly tracking shots (i.e.
for time lapse applications). LinuxCNC combined with
Sherline's 4-axis driver box seems like an ideal fit.
The catch is I need my system to be extremely portable
(I'll be shooting in the woods), and my Powerbook has
no parallel port. Has anyone used a usb to parport
adapter in conjunction with LinuxCNC? I have done
some reading on this issue for linux more generally
(like the USS720 parport driver), but was wondering
how easy this would be to configure with LinuxCNC. My
motion control needs are quite simple, and will
comprise of stepping the motor a certain number of
steps, taking a picture, then repeat. Any help would
be much appreciated.
Thanks,
Ben Yates

My bet is that it won't work, unless you're using a board like Jon
Elson's universal stepper controller (
http://www.pico-systems.com/univstep.html ). The reason is that EMC
needs VERY fast access to the I/O pins to generate step pulses. USB
runs on a 1ms timeslice. So, even if you wrote a driver for EMC, it
would only be able to generate 500 pulses per second - and that's if
you're lucky. (ie, the timing of the EMC step generation thread happens
to stay perfectly in step with the USB packet clock...) If they got out
of sync, you might still get all of the pulses you hoped for, but they
would be in a bunch at the beginning of each 1ms timeslice. (ie, if EMC
had output 30 pulses in the previous millisecond, and the output chip
can switch its outputs every microsecond, then you would get all 30
pulses in the first 60 microseconds after the USB packet containing
those port transitions arrives at the adapter)

The reason Jon's board may work is that it relieves the system of the
high speed pulse generating burden, and presents an IEEE1284 interface
to the computer - it just takes 32 bytes or so every millisecond - which
should work just fine over USB.

Note that (as far as I know, and I'm no expert), EMC doesn't work on
processor architectures other than Intel x86, so you may be out of luck
with a Powerbook anyway - you should definitely check on that, though.

Sorry to be the bearer of bad news (the bright side is - I could be wrong :)
- Steve

[Gene Heskett]

Post by Stephen Wille Padnos

Post by ben yates
I am attempting to build a low-cost motion control
device for a digital camera that would allow for
smooth pan, tilt, and possibly tracking shots (i.e.
for time lapse applications). LinuxCNC combined with
Sherline's 4-axis driver box seems like an ideal fit.
The catch is I need my system to be extremely portable
(I'll be shooting in the woods), and my Powerbook has
no parallel port. Has anyone used a usb to parport
adapter in conjunction with LinuxCNC? I have done
some reading on this issue for linux more generally
(like the USS720 parport driver), but was wondering
how easy this would be to configure with LinuxCNC. My
motion control needs are quite simple, and will
comprise of stepping the motor a certain number of
steps, taking a picture, then repeat. Any help would
be much appreciated.
Thanks,
Ben Yates

My bet is that it won't work, unless you're using a board like Jon
Elson's universal stepper controller (
http://www.pico-systems.com/univstep.html ). The reason is that EMC
needs VERY fast access to the I/O pins to generate step pulses. USB
runs on a 1ms timeslice. So, even if you wrote a driver for EMC, it
would only be able to generate 500 pulses per second - and that's if
you're lucky. (ie, the timing of the EMC step generation thread
happens to stay perfectly in step with the USB packet clock...) If
they got out of sync, you might still get all of the pulses you
hoped for, but they would be in a bunch at the beginning of each
1ms timeslice. (ie, if EMC had output 30 pulses in the previous
millisecond, and the output chip can switch its outputs every
microsecond, then you would get all 30 pulses in the first 60
microseconds after the USB packet containing those port transitions
arrives at the adapter)
The reason Jon's board may work is that it relieves the system of
the high speed pulse generating burden, and presents an IEEE1284
interface to the computer - it just takes 32 bytes or so every
millisecond - which should work just fine over USB.
Note that (as far as I know, and I'm no expert), EMC doesn't work on
processor architectures other than Intel x86, so you may be out of
luck with a Powerbook anyway - you should definitely check on that,
though.
Sorry to be the bearer of bad news (the bright side is - I could be
wrong :) - Steve

I got the impression that this job isn't in any great hurry, and being
quiet is probably an advantage, as in wildlife tracking or security
surveilance. Since he has mentioned portable, in the field, I'd have
to assume the former. In that event, relative silence is a Good
Thing(tm).

In that event the number of interrupts per second might very well be
slowed down to be compatible with the 1ms timing of the usb port (I
wasn't aware of any such limitation, but I've not studied the
protocol in depth either)

There is a value in emc.ini that can be adjusted to meet that
criteria, and setting that way up in terms of the time its specified
in, and lowering the voltage on the motors, will both reduce the
speed to a maximum of 500 to 1k steps/second, probably fast enough
for this app, and reduce the stepper noise and motor power
consumption considerably. For field usage, power consumption may be
the paramount consideration. I would reduce the motors supply
voltage until a locked, but gently shaking condition is found, then
raise it by 25% or so and it should still run quite silently if
theres no rattling panels or couplings to amplify the noise.

If the gearing is such that the steppers can be run at an even lower
rate, I think I'd write the driver to only power the motor for maybe
5 or 10 milliseconds and then essentially shut it off until time for
the next step. That would reduce the power consumption by quite a
bit, but could lead to resonance problems at the higher speeds.

[Paul]

I would beg to differ on this point - There is nothing in the EMC code that is
specific to x86 hardware, and certainly no assembler routines. As long as you
have a functioning realtime kernel, it should run on Arm, PowerPC, or any
number of other processor.

Regards, Paul.

Post by Stephen Wille Padnos
Note that (as far as I know, and I'm no expert), EMC doesn't work on
processor architectures other than Intel x86, so you may be out of luck
with a Powerbook anyway - you should definitely check on that, though.

[Stephen Wille Padnos]

As I said - I'm no expert :)

I wouldn't think that there would be problems with EMC (possibly in low
level drivers, but nowhere else). The issues would be with the RTOS and
installation. As far as I know, BDI is only available for x86, so
installation on other architectures is somewhat more involved. Also,
RTOS support (and the kernel itself, in some areas) generally lags on
other architectures.

If I can find whatever it was that gave me the impression that EMC
wouldn't work on ppc, I'll let you know where it is so it can be fixed.
Until then, let's assume it was a figment of my imagination.

Thanks for the correction
- Steve

Post by Paul
I would beg to differ on this point - There is nothing in the EMC code that is
specific to x86 hardware, and certainly no assembler routines. As long as you
have a functioning realtime kernel, it should run on Arm, PowerPC, or any
number of other processor.
Regards, Paul.

Post by Stephen Wille Padnos
Note that (as far as I know, and I'm no expert), EMC doesn't work on
processor architectures other than Intel x86, so you may be out of luck
with a Powerbook anyway - you should definitely check on that, though.

[Jon Elson]

Post by Paul
I would beg to differ on this point - There is nothing in the EMC code that is
specific to x86 hardware, and certainly no assembler routines. As long as you
have a functioning realtime kernel, it should run on Arm, PowerPC, or any
number of other processor.

Well, it is not a big point, but the x86 is one of the older
architectures that has a
separate access mechanism for I/O and memory. Most of the other
architectures
unify I/O and memory. The different I/O access mechanisms are pretty much
the only thing that is not directly portable (assuming that a suitable
rt package were
available.) This could easily be fixed, of course, and the various outb
and inb functions could be replaced with the right functions.

Jon

[Mark Pictor]

I hate to throw cold water on your party, but there
are several issues here.

As far as I know, EMC has never been used sucessfully
on a Mac. Even if it will work, it will require
completely re-compiling a lot of software - EMC,
rcslib, and a patched linux kernel with RTAI. Do you
currently use Linux on that Mac? It is required,
because EMC needs a real-time operating system. There
aren't (m)any free choices other than using RTAI - and
thus linux.

I doubt that EMC will work directly with the usb card,
EMC needs a hardware i/o port address to work directly
with, as opposed to something in /dev - which is where
the usb device will show up. Even if you were able to
write a driver for the card, you would have to find or
write a driver for the USB subsystem itself, and this
would not be easy even on x86.

Also, this isn't something most EMC users are greatly
interested in, as USB introduces delays which would
wreak havoc on *most* of the equipment EMC is used to
control. What I am saying is that you probably won't
find someone to write the driver for you...

To me, this application sounds pretty trivial. Are
you a decent programmer? I don't think it would be
too hard; (for example) I doubt you need to move
multiple axes at once, and acceleration can probably
be ignored. I imagine that there are other programs
out there that can do this with far, far less
modification. Here's a very simple one:
http://bigasterisk.com/parallel
I seem to remember another specifically for
cameras...?

Steppers and a stepper controller will take a fair
amount of juice! I hope you don't plan on running it
off of your laptop battery...


Good luck,
Mark

Post by ben yates
I am attempting to build a low-cost motion control
device for a digital camera that would allow for
smooth pan, tilt, and possibly tracking shots (i.e.
for time lapse applications). LinuxCNC combined
with
Sherline's 4-axis driver box seems like an ideal
fit.
The catch is I need my system to be extremely
portable
(I'll be shooting in the woods), and my Powerbook
has
no parallel port. Has anyone used a usb to parport
adapter in conjunction with LinuxCNC? I have done
some reading on this issue for linux more generally
(like the USS720 parport driver), but was wondering
how easy this would be to configure with LinuxCNC.
My
motion control needs are quite simple, and will
comprise of stepping the motor a certain number of
steps, taking a picture, then repeat. Any help
would
be much appreciated.
Thanks,
Ben Yates

__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com

[Steve Stallings]

Modern interfaces like USB and Firewire have worked wonders
with the rate at which they can stream data. Their performance
in handling single bits or events is not that great. They
rely on sending lots of data in one transaction, something
that real time "bit twiddling" does not allow.

Regards,
Steve Stallings

-----Original Message-----
Sent: Monday, November 29, 2004 1:29 PM
Subject: Re: [Emc-users] usb to parport adapter
In case my previous explanation wasn't clear, they don't
have to replace
the inb and outb macros. A real parallel port is a piece of memory
mapped hardware. The virtual USB parallel port presents a
memory map
that looks like the real parallel port. inb and outb will work on
either the real driver or the virtual driver.
BTW: USB is a pretty low overhead protocol. I can transfer
data from an
external hard drive to my laptop internal drive at 20+
MB/sec and only
use 3% of the processor resource. (3GHz P4, 1GB RAM, 800
MHz FSB) The
20 MB/sec is a hard drive speed limitation, not a processor or USB
limitation.
If USB can move 20MB/sec, I don't think it is going to have
trouble with
a few stepper motor pulses.
Kim

Post by Jon Elson

Post by Kim Lux
inb and outb are pretty standard functions. They will

be present on the

Post by Jon Elson

Post by Kim Lux
other architectures.
The USB driver presents an interface that looks exactly

like a "real"

Post by Jon Elson

Post by Kim Lux
parallel port. My guess is that inb and outb should

work fine with the

Post by Jon Elson

Post by Kim Lux
USB parallel port and with the other architectures.

Linux and Unix are

Post by Jon Elson

Post by Kim Lux
written for portability.

I'm very interested to hear how they do this. OK,

assuming you replace

Post by Jon Elson
inb and outb macros with something that translates to the

USB, will it do

Post by Jon Elson
this with real-time code, too? That is a totally

different environment.

Post by Jon Elson
Then, can it allow one parallel port to be controlled by

BOTH RT and Linux

Post by Jon Elson
concurrently? And, what will it do to pulse timing? I

think that is

Post by Jon Elson
going to
be the death of it, that you can only get 1000 level

changes per second,

Post by Jon Elson
and that means 500 steps/second, tops. Alternatively,

the driver batches

Post by Jon Elson
changes into packets, and then does them all as fast as

it can when each

Post by Jon Elson
packet is sent. This will totally destroy any attempt to

make smooth, or

Post by Jon Elson
even coordinated moves.
Jon
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products

from real users.

Post by Jon Elson
Discover which products truly live up to the hype. Start

reading now.

Post by Jon Elson
http://productguide.itmanagersjournal.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

--
Kim Lux (Mr.) Diesel Research Inc
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products
from real users.
Discover which products truly live up to the hype. Start
reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Steve Stallings]

Post by Kim Lux
I coincidentally checked out serial handshaking and I didn't see any
delays. Maybe I wasn't looking close enough.

Serial handshaking will tolerate delays on the order of
several hundred microseconds whereas step pulses to a
stepper motor need reliable timing on the order of tens
of microseconds to operate smoothly. USB can only
transfer date once per millisecond, so any timing
better than that must come from the target device, not
the host software.

Regards,
Steve Stallings

[Kim Lux]

I'm running our CNC equipment on TurboCNC (DOS) and thus I can't really
test a parallel port USB device. I'm under the assumption that if bus
contention isn't an issue that the USB to parallel converter is just a
fancy shift register, ie serial in and parallel out and any delays
should be constant. I was not aware of the 1 mSec queuing delay you
speak of. If I get time (ya right!) I might have a closer look at the
kernel source for the PL2303 driver.

This is a very interesting discussion.

Post by Steve Stallings

Post by Kim Lux
I coincidentally checked out serial handshaking and I didn't see any
delays. Maybe I wasn't looking close enough.

Serial handshaking will tolerate delays on the order of
several hundred microseconds whereas step pulses to a
stepper motor need reliable timing on the order of tens
of microseconds to operate smoothly. USB can only
transfer date once per millisecond, so any timing
better than that must come from the target device, not
the host software.
Regards,
Steve Stallings
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Jonathan Stark]

A microcontroller on the 'far' side (the non PC side)
could make USB a reality, by handling all of the time-sensitive
aspects, but it really just isn't possible for USB to do
what EMC (or TurboCNC for that matter) does with the parallel
port.

Bandwidth and transfer speeds aren't the issue. Latency and
consistency in latency is.

Kim, if you want to do a simple test, set up a loop back on your
serial<->usb interface. Connect the transmit and receive pins
so that each byte you transmit out the serial interface comes back
on serial receiver. Then write a simple program to output a
stream of characters, and read them back noting how long each
character takes to make the round trip. See how consistent
the round trip time is. I think you'll see a very wide variation in
the round-trip times, as well as bursting due to the USB protocol.

Jonathan

[Kim Lux]

That would be a good way to test it except:

a) I'm not running a real time OS and I'm not sure how to separate USB
delays from OS delays. I could send a char, my process could be
preempted and the time I read it could be wrong.

b) emc is only worried about outputting data, not receiving it. AFAIK
the only inputs to emc via the parallel port are for non time critical
things like end of travel switches. About the only exception to this
that I can think of is receiving a spindle pulse to sync threading to,
if it came in via the parallel port.

I think a better way to test this would be to periodically toggle the
rts line at the USB interface and see if there is any jitter on the
output at the RS232 end. If there is a queuing delay, the pulses should
bunch up. If they are even and periodic, then the effect isn't worth
worrying about.

Does anyone know of a way to generate a perfectly periodic pulse train
of about 50KHz in Linux without installing a RT patch ?

Post by Jonathan Stark
A microcontroller on the 'far' side (the non PC side)
could make USB a reality, by handling all of the time-sensitive
aspects, but it really just isn't possible for USB to do
what EMC (or TurboCNC for that matter) does with the parallel
port.
Bandwidth and transfer speeds aren't the issue. Latency and
consistency in latency is.
Kim, if you want to do a simple test, set up a loop back on your
serial<->usb interface. Connect the transmit and receive pins
so that each byte you transmit out the serial interface comes back
on serial receiver. Then write a simple program to output a
stream of characters, and read them back noting how long each
character takes to make the round trip. See how consistent
the round trip time is. I think you'll see a very wide variation in
the round-trip times, as well as bursting due to the USB protocol.
Jonathan
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Kim Lux]

btw: have we agreed that inb and outb should work with the <virtual> USB
interface ? Did we agree that at some level the USB interface looks
like its hardware mapped I/O counterpart or is that wrong ?

As USB becomes more prevalent and parallel and serial ports gradually
disappear, it will be more important to know this. My laptop, for
example, has no serial ports but does have 4 USB ports.

BTW: Here is the code that checks rts on an application I am working on.
I did not write it.

It works whether I am using a real serial port or a USB serial port.

static int
read_cts_state (void)
{
/* assuming UNIX */
unsigned int cts_state;
ioctl (ser_desc->fd, TIOCMGET, &cts_state);
return (cts_state & TIOCM_CTS) ? 1 : 0;
}

[Stephen Wille Padnos]

Post by Kim Lux
btw: have we agreed that inb and outb should work with the <virtual> USB
interface ? Did we agree that at some level the USB interface looks
like its hardware mapped I/O counterpart or is that wrong ?

No - we haven't agreed on that, because it's not done that way :). You
will never write user code that does inb and outb on a parallel or
serial port (or any other supported device) - that's the whole point of
a driver. It allows you to use higher level abstractions like open(),
read(), and ioctl(). There is no need for the kernel to trap in/out
instructions, because they aren't used by high level code.

Post by Kim Lux
As USB becomes more prevalent and parallel and serial ports gradually
disappear, it will be more important to know this. My laptop, for
example, has no serial ports but does have 4 USB ports.
BTW: Here is the code that checks rts on an application I am working on.
I did not write it.
It works whether I am using a real serial port or a USB serial port.
static int
read_cts_state (void)
{
/* assuming UNIX */
unsigned int cts_state;
ioctl (ser_desc->fd, TIOCMGET, &cts_state);
return (cts_state & TIOCM_CTS) ? 1 : 0;
}

Note that this code uses ioctl(). The driver maintains a variable with
the last known modem state (or asks for a current copy, and blocks your
process until it arrives), and returns that. No file operations are
allowed in RT code - they're too unpredictable.

A simple test program, which shouldn't require RT Linux extensions,
would be to write a program that sets the (USB) serial port to 115200
baud (or faster, if you can), and outputs one byte to the serial port
every 300 or 500 microseconds (usleep should work well enough). Look at
the serial output on a scope, and see if you get fairly evenly spaced
bytes, or if you get pairs/triplets every millisecond or so, with a long
(relatively speaking) pause between groups.

- Steve

[Kim Lux]

I wholeheartedly agree that inb and outb shouldn't be used to access the
port. Did we agree that *IF* we decided to access it this way that the
virtual port would (software wise) act the same as the real port ?

Post by Kim Lux
btw: have we agreed that inb and outb should work with the <virtual> USB
interface ? Did we agree that at some level the USB interface looks
like its hardware mapped I/O counterpart or is that wrong ?

[Stephen Wille Padnos]

Post by Kim Lux
I wholeheartedly agree that inb and outb shouldn't be used to access the
port. Did we agree that *IF* we decided to access it this way that the
virtual port would (software wise) act the same as the real port ?

What I'm saying is that there *is* no virtual port. Then, I go on to
say that even if there were, it wouldn't work because of the 1ms USB
packet rate.

So, I guess that either way, it's a no-go for direct port access. It
*might* work with something like Jon Elson's universal stepper
controller, because that actually looks a lot more like a printer than a
geckodrive (in terms of data transfer protocols).

Post by Kim Lux

Post by Kim Lux
btw: have we agreed that inb and outb should work with the <virtual> USB
interface ? Did we agree that at some level the USB interface looks
like its hardware mapped I/O counterpart or is that wrong ?

As far as I know, that's the wrong part :) I took a look at
drivers/usb/uss720.c, which is a pretty generic USB<-> parallel driver.
When you do a write to the device, it just makes a bulk data packet to
be transmitted in the next USB frame.

(of course, it does look the same at the open / read / write / close
level, but that's not too relevant to this discussion)
- Steve

(there is no spoon)

[Jonathan Stark]

Post by Kim Lux
a) I'm not running a real time OS and I'm not sure how to separate USB
delays from OS delays. I could send a char, my process could be
preempted and the time I read it could be wrong.

Oh, I thought you were running in dos and were able to use inb
and outb directly? My mistake.

Post by Kim Lux
b) emc is only worried about outputting data, not receiving it. AFAIK

Well, this was just a test to illustrate that USB is bursty, and
inconsistent.

Post by Kim Lux
rts line at the USB interface and see if there is any jitter on the
output at the RS232 end. If there is a queuing delay, the pulses should

EMC doesn't use RTS either. :)

Jonathan

[Kim Lux]

I've never used a USB device in DOS. I was wondering about that the
other day... our DOS machines don't support USB. I'd love to get those
DOS machines running Linux.

The machine I'm at now is running Fedora Core 3.

Bye for now...

Kim

Post by Jonathan Stark
Oh, I thought you were running in dos and were able to use inb
and outb directly? My mistake.

[Dean Hedin]

Post by Kim Lux
b) emc is only worried about outputting data, not receiving it. AFAIK
the only inputs to emc via the parallel port are for non time critical
things like end of travel switches.

The turnaround time on these items are critical, so it is also with probing.
The probe is moved towards the surface and we must stop motors promptly when
contact is made.

The only way to have a USB controller is to acutally have the motion control
inside the USB device.

[Kim Lux]

As interesting as this discussion is, I need to bow out to get some work
done. Please continue the discussion in my absence as I'm dying to
know.

--
Kim Lux (Mr.) Diesel Research Inc