Right, a lot of people do that. But, EMC also supports real servo systems where the CPU is in the middle of the servo loop. That is the kind of interface I make. The computer sends a velocity command to the interface, it generates either steps, a DC voltage or a PWM pulse train where pulse width is proportional to desired velocity. Encoders feed back position to encoder counters which are read periodically by the CPU. If you choose the PWM or analog interface, then there are NO steps anywhere in the system. With these systems, you can hit E-stop, move the machine manually while EMC2 acts as a DRO, then clear the E-stop and go back to CNC, while the system maintains the coordinate system all the time.
With my boards, the parallel port is a communications channel, and the CPU can read and write banks of registers, representing position and velocity.
Not just NEC MultiSync, but any other which can handle the needed scan rate. I was using "multisync" as a generic term, not a brand name. Note that I used lower case in the term.
The converter card which you posted a link to (or someone else posted the link) looks as though it will also handle scan rate conversions -- so that and a LCD monitor looks like the best bet in terms of surviving shop conditions -- with a sheet of Plexiglas or Lexan to protect the screen from hot chips and coolant splatters.
NAME ecpp - IEEE 1284 compliant parallel port driver
SYNOPSIS #include
#include
ecpp@unit-address
DESCRIPTION The ecpp driver provides a bi-directional interface to IEEE 1284 compliant devices as well as a forward single- directional interface to Centronics devices. In addition to the Centronics protocol, the ecpp driver supports the IEEE 1284Compatibility, Nibble, and ECP protocols. ECPP_COMPAT_MODE and ECPP_CENTRONICS modes of operation have logically identical handshaking protocols, however devices that support ECPP_COMPAT_MODE are IEEE 1284 compliant dev- ices. IEEE 1284 compliant devices support at least ECPP_COMPAT_MODE and ECPP_NIBBLE_MODE. Centronics devices support only ECPP_CENTRONICS mode. ======================================================================
That is only about half of the first of nine pages in the "man page" for this device. So -- it probably would work.
O.K. Then anything that I have around would handle it easily. I was wondering whether it needed to supply power to something a bit more power hungry, and I guess that it does not.
I think that what the Sun has would handle it -- as long as there is information on what your bus and cards expect in the way of command format.
Now -- *that* sounds quite attractive.
Will the board have ethernet? I like to do my design work on other computers and access the files from the net.
Please let us all know when it is ready.
Since I will be using servo motors with tach feedback on this Bridgeport, I think that the 1 mS rate would do. It comes from "librt" (also called "libposix4")
====================================================================== DESCRIPTION Functions in this library provide most of the interfaces specified by the POSIX.1b Realtime Extension. See stan- dards(5). Specifically, this includes the interfaces defined under the Asynchronous I/O, Message Passing, Process Scheduling, Realtime Signals Extension, Semaphores, Shared Memory Objects, Synchronized I/O, and Timers options. The interfaces defined under the Memory Mapped Files, Process Memory Locking, and Range Memory Locking options are pro- vided in libc(3LIB). ======================================================================
But your board would elminiate the need for that. I particularly like the SD memory cards -- if you can find ones which provide enough read/write cycles to have a reasonable life. I really don't like hanging disk drives on something which vibrates like a milling machine. :-)
Warning! this is a top post, top post Nazi's please go to Lowes, buy a bag of sand, and pound it up your a**.
Iggy, I converted my lathe to EMC2 and plan to convert my mill to EMC2 in the future. Since my original control works, I plan to convert using the same connectors that are on the original controls. So, I can remove plugs and plug in my EMC2 control for trial and testing, if I need to run something, I can plug the cables back into the original control and go.
Since my original control works you may wonder why I would want to convert to EMC2. My Anilam control can handle 1000 moves in the program, the EMC2 control could handle much more. I have to program the Anilam control with a RS-232 cable, the EMC2 control can use flash drive, network, internet, etc, and programs can be saved on the hard drive. I could have 1000's of part programs and easily load by selecting the file to load. The most expensive part of the EMC2 control is the $199 board versus the much higher Crusader II boards. I can add I/O to the EMC2 control, it would cost hundreds to add I/O to the Anilam Control I can add control for a variable speed drive with the EMC2 control I can add a 4th, 5th and 6th axis with the EMC2 control. If I could make the mechanical part, I could add a tool changer to the EMC2 control.
So, there are many reasons to upgrade my control even though the old control runs fine. And by keeping compatible with the original controls I don't have to take my machine down while getting the new control functioning.
RogerN, unless some magical event happens and old control is perfectly working after jiggling some cables, I will replace it with EMC2 as well. I have already set up a PC for EMC2 and printed out the manuals. It would seem that the extra hardware (besides a POS PC that I have anyway) costs only $500 or so.
Not clear whether the Sun system has native EPP mode or they do this in software emulation. The default operating mode is for the EMC2 driver (hal_ppmc.c) to read position and auxilliary sense inputs 1000 times a second and then output new velocity and aux. outputs. This takes about 30 EPP byte transfers. Typically, on a reasonable 1 GHz Pentium CPU the whole transaction including the PID servo loop calculation takes about 100 us.
Anyway, this driver is a USER-mode driver, so it might not work directly in the RT environment. And, the hal_ppmc.c driver doesn't use any driver, it manipulates the parallel port control register bits directly. (That may actually be virtualized in the RTAI environment, but not by much.) So, unless this ecpp driver closely mimics the Microsoft/Intel EPP parallel port register layout, the hal_ppmc.c driver would need to be reworked.
Yes, if you can deal with getting to the EPP address and data transfer operations, then it is all here :
formatting link
in each of the board description links, and there is a register definition page for it. The above link is for the analog velocity servo interface, I have a different page for the PWM controller.
Ethernet is not native, but you can get a $9 USB dongle that adds 3 USB ports plus Ethernet. That's how we use it.
Yes, I will keep everybody posted on progress, but don't hold your breath. First, we need to get RTAI running on the Beagle Board. Then, we need to get EMC2 ported to the specific environment. We need to find out if the OMAP3530 CPU is fast enough. It SEEMS like it ought to be, since we used to run this stuff (with less abstraction between EMC and the hardware) on 100 MHz Pentium classic CPUs. HAL has added a certain amount of overhead, but it shouldn't be all that much. Then there are some performance bottlenecks in the simulated parallel port arrangement. I was hoping that the close integration of the OMAP CPU and peripherals all in one chip would lead to incredibly fast access to the GPIO pins, but apparenty the GPIO functionality is multiplexed in some way, so you can only flip a pin's status every 250 ns. That is not a major bottleneck, it is no slower than a good PCI parallel port card, but it isn't BETTER, which is what I wanted. There are other peripherals in the OMAP that are not multiplexed, and so they may be a way to a much faster I/O channel.
EMC2 no longer explicitly supports rtlinux, which I think this might be a parallel to. We have an abstraction layer to the RT system, but nobody has used the rtlinux branch of that in a long time. So, there might be some parts of the interface that no longer work right. But, it did work once, so most of the code is still in place. You need shared memory regions, the ability to start and stop RT processes and the RT fifos, as I understand it.
====================================================================== Tunables Characteristics of the ecpp driver may be tuned by the variables described in /kernel/drv/ecpp.conf. These vari- ables are read by the kernel during system startup. To tune the variables, edit the ecpp.conf file and invoke update_drv(1M) to have the kernel read the file again.
Some Centronics peripherals and certain IEEE 1284 compatible peripherals will not operate with the parallel port operat- ing in a fast handshaking mode. If printing problems occur, set "fast-centronics" and "fast-1284-compatible" to "false." See /kernel/drv/ecpp.conf for more information.
Read/Write Operation The ecpp driver is a full duplex STREAMS device driver. While an application is writing to an IEEE 1284 compliant device, another thread may read from it. ======================================================================
User mode? It is in the kernel, and its behavior is tuned by /kernel/drv/ecpp.conf at boot time. All changes at run time are made by IOCTLs, as is standard for all other unix variants I believe. The two major ioctl calls for his are:
ECPPIOC_GETPARMS and ECPPIOC_SETPARMS
with quite a few others for other kinds of control.
Hmm ... I'm not sure that Solaris would allow direct access to the registers.
Great! This is the sort of thing I was looking for.
Reading the encoder counter register section, I am quite pleased to see the latched count, given the number of cycles needed to read one encoder value (set address, read byte, repeat for three bytes) -- not counting the control register write needed before the reads.
I would otherwise consider it quite likely that there would be a change in a register which could create confusion -- whether you read it LSB first or MSB first.
A pity that there is not an available 32-bit or even 64-bit read path available, which would reduce the number of CPU cycles needed to get a value significantly.
Since the analog velocity servo is what I need, this is fine.
O.K. That will do.
Understood. I've been sitting on this project for quite a while, waiting until I get around to making a new mount for the Y-axis servo motor (the original mount for the stepper assumes a much shorter motor and won't accept the servo).
O.K. I'll not hold my breath.
I hope so. Good luck with that.
Wasn't rtlinux the one which had a real time kernel below the linux kernel, and switched the kernel as one of the tasks?
You know -- OS-9 (the original Microware multi-user multi-tasking OS, not the later Apple Macintosh one of the same name) has some major advantages for real-time operation. Instead of swapping memory maps (which takes time), each task runs wherever there is physical memory available, and the whole OS and all the applications can run from ROM if desired. It was originally written for the Motorola
6809, which might be too slow for all of this, but it has been ported to many other CPUs (the Motorola 68000 series first) which offer a lot larger memory map and a lot faster CPU clocks. I'm pretty sure that it has been ported to the Intel processors as well.
O.K. But your board which is still in development sounds like it will do all that I need.
O.K. I think all of that is present -- though I'm not sure about the fifos. There are a *lot* of pages in the man page for rt_dptbl(4), but it tells you how to compile and activate a custom dispatch table.
If you send me e-mail about the board when it is ready, please don't use HTML in the e-mail, as it is likely to get tossed into the spam folder, at which point I will need a good Subject header to recognize it. :-) Yes -- my e-mail address above (and below) is valid.
Sharing the EPP port won't work. Because the Pico Systems devices have a register address counter that increments for every data transfer cycle, sharing would get the counter out of sync. Anyway, it sounds pretty wierd to have a printer or scanner on the same port as a CNC control that could cause injury if something went wrong. NOT a good idea.
Also, it is not clear if this driver permits the level of throughput required for fast back and forth transfers. It is doing very short bursts each way and does it at about 600 ns/byte on a PCI parallel port.
Well, of course, we had to do it RIGHT. Latching the count so it could be safely read later by the CPU was obvious. Dealing with zeroing the counter while searching for the home index pulse at the same time the servo loop is running was not so easy, but it handles that, too.
Both rtlinux and RTAI work approximately that way.
Some X-86 systems have been running step pulse generation tasks as fast as every 10 us! So, the task switching doesn't take very long.
Mach 3 registered has a learn mode in the collection of Wizards. Also, you can use keyboard controls to directly control the machine. I use both of those things. I'm curious how you thought us home shop guys zeroed the machine to the work piece?
Nor is it something which I would intend to do. I don't know how long it has been since I have used a parallel port to talk to a printer. :-)
O.K. Someone would have to do the experiment, I guess.
Good.
O.K.
It depends on how many registers need to be preserved and re-loaded. The SPARC cpu has a lot more registers than the X86 family of processors -- but it also has multiple sets of registers, so a process switch *can* be fast -- until you get more active processes than you have sets of registers -- then you still need to save everything from a set so it can be reloaded for another process.
A graph of load average vs increasing number of processes is a very shallow graph up to a certain point (which varies with which model of SPARC is involved, as the number of register sets has been increasing through the years) but at a certain number of processes the curve becomes suddenly much steeper.
Thanks, Bob.. the jog function was previously discussed, so I assumed that an operator had control capabilities, but I was curious about teaching/learning feaures.
Me, either. I'm thinking about cutting the plugs off of at least a
55 gallon drum of parallel printer cables to sell them for scrap copper. Of course there won't be much copper after they are run though a wire crusher to remove the insulation. It would barely fill a two gallon bucket. :(
I have a lot of 15 & 25 foot printer cables, and a lot have gold plating on the connector shells that caught the eye of the gullible who bought them.
There are cheap monochrome security monitors around. They are typically in 9" or 12", but I've seen 21 inch, as well. I have some aluminum cased composite monitors that were used as computer monitors, but I haven't used any in about 15 years.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.