CNC Bridgeport with Heidenhein control

Ignoramus26960 wrote:


OK, I have two flavors. One is for use with velocity servo amps that take +/- 10 V analog velocity command signals. It is a very flexible board set, meaning you can mix and match boards for the actual number of I/Os you need. It runs $780 for the basic 4-axis set, that gives 4 encoder counters, 4 16-bit 10 V DACs and 16 digital inputs and 8 SSR output locations, plus an E-stop circuit.
See http://pico-systems.com/oscrc4/catalog/index.php?cPath=8 for a look at this system.
I also have another system that is for use with my own servo amps, which use digital PWM commands to the amps. This is here http://pico-systems.com/oscrc4/catalog/index.php?cPath=3 and the controller board is $250, and the servo amps are $125 each for the brush motor version. If your servo amps are in good shape, velocity servo amps with tachometer feedback can be VERY smooth, and reusing them will save you some rewiring. The cost between the two systems is not all that different.
Jon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

    [ ... ]

    Intesting. I see that it expects to be driven by a parallel port, and is not on cards which plug directly into the system bus, which suggests that I could use it with on of my Sun workstations instead of requiring an Intel based system. This I would like. I should be able to compile EMC2 to run under Solaris 10 (which has a real-time feature).
    I am curious about the power supply shown. The voltages are specified, but I see no current capacity to suggest whether it would serve better than the many other power supplies which I already have.
    Is there anyplace where I can download the communication protocols being used with the parallel port?
    Thanks,         DoN.
--
Email: < snipped-for-privacy@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"DoN. Nichols" wrote:

Most of these systems send step and direction signals from the parallel port, not any sort of protocol. They rely on low level drivers to control the parallel port and generate the pulses.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Pete C. wrote:

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.
Jon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

    Just what I want.
    Thanks,         DoN.
--
Email: < snipped-for-privacy@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
DoN. Nichols wrote:

Well, the other problem is it was designed for the EPP mode (IEEE-1284) of data transfer. Not all other parallel ports support this natively. On the other hand, you could probably make any bidirectional parallel port that even loosely follows the old PC-style ports do it in software, either doing a software handshake or just skipping the handshake and assuming the controller board is always faster than the Sun CPU.

Which power supply? For the PPMC? It is a commodity +5, +/- 12 V supply, not much current at all. About 300 mA on +5 and +12, 100 mA on the -12.

Well, Jan Axelson's book kind of goes over it, there are some docs on SMSC's web site for the FDC37C665GT chip that I worked from 9 years ago. That was one of the popular ISA multi-IO chips when motherboards still used an internal ISA bus to handle serial, parallel and floppy devices. Basically, you have a bidirectional data bus, an address strobe, a data strobe, a direction signal and an acknowledge signal back from the device. There's also a well-hidden Intel/Microsoft document on the IEEE-1284 but that was more aimed at a standard register-level description of the port on the PC.
Anyway, due to the disappearing of the PC's parallel port, and the fact that real time performance of PCs is going down the tubes, I am working on porting EMC to the Beagle Board, a $149 3" square board that packs pretty much everything on a PC. Disk is replaced by SD memory cards. We don't have the RTAI real time system ready yet, but a guy is working on that.
EMC2 does need "hard" real-time performance, I don't know what level of RT support Solaris 10 offers. The software-generated step guys have the step generator dispatched every 10 us or so, which is really tough on the system. For the interfaces I do, a 1 ms interrupt rate works fine, which is a little less demanding.
Jon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

    O.K. From the beginning of the man page for "ecpp" (the output special device file):
=====================================================================Devices ecpp(7D)
NAME ecpp - IEEE 1284 compliant parallel port driver
SYNOPSIS #include <sys/types.h>
#include <sys/ecppio.h>
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. :-)
    Thanks much,         DoN.
--
Email: < snipped-for-privacy@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
DoN. Nichols wrote:

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 : http://jelinux.pico-systems.com/PPMC.html Look 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.
Jon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

    O.K. From later in the man page:
===================================================================== 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. ====================================================================> Anyway, this driver is a USER-mode driver, so 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.
    Thanks much,         DoN.
--
Email: < snipped-for-privacy@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
DoN. Nichols wrote:

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.
Jon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

    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.
    Enjoy,         DoN.
--
Email: < snipped-for-privacy@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"DoN. Nichols" wrote:

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.
--
Greed is the root of all eBay.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I'm sure you have run into http://www.linuxcnc.org /
I believe Winston uses emc2. Jon Ellison is very active with that iirc.
They have a forum:
http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/lang,english /
There is also an email discussion list.
https://lists.sourceforge.net/lists/listinfo/emc-users
I'm a lurker, I don't have a machine to cnc YET. I'll likely do one of the Seig X? conversions since a cnc mill is way more interesting to me than a lathe.
Wes
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Looks like you're interested in EMC2. Pretty steep learning curve but very capable software. I'm pretty sure this machine has servos with glass encoder scales for position feedback. It may (probably has) have encoders on the motor also. Dual loop control is an advanced subject.
Long story short, don't go in to this thinking its a quick easy job. You'll also spend a fair bit of bucks on servo drivers that work with EMC and run your servos.
Karl
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Karl, if you can give me a rundown of what I would need/how much time it will take/how much it will cost, it would be greatly appreciated.
i
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

It depends on what is already there. I replaced my Anilam control with EMC2, it closes the loop twice, once between the servo motors and tachometer feedback, the second with the encoder position feedback. I was able to use the original servos, drives, encoders, etc. A $200 board for the PC was able to read the encoders and an additional $69 board converted the PWM output to +/-10V for the servo drive command signal. It took a little time to read through the configuration files but the setup was fairly straight forward. There is a lot of good help available for EMC2 and I don't think you'd have a lot of problem.
RogerN
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

The major cost here will be your time. A lot to learn. My pure guess would be about two man months. The more equipment you can reuse the more you save and the more time you'll spend. Its easier to do a simple machine first, this one isn't it. Look in to how you do the servo drives with the Heidenhein scales and what all you'll need to interface all the I/O to your Linux box. These will be the two largest costs.
You'll end up with a machine you control from a computer keyboard - fine for hobby work. Most of my experience is with refitting a machine so its a professional job that is better than new. Costs easily run 15K to do this.
Karl
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

So, Karl, what would you (with your skills and all) do with this bridgeport, would you just try to restore its Interact 2 controls?
i
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus26960 wrote:

My recommendation would be to use the existing controls if it's a simple thing like replacing a monitor. Then investigate those controls to see if the servo drives and encoders would be reusable and plan the EMC2 or Mach3 retrofit while you use the current controls. When the current controls finally die and can't be repaired you'll be ready for the retrofit.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

If you're looking to make some money:
I'd part the machine out. The servos, scales, and head - sold separately - will bring you about a 4:1 return.
If you want a CNC machine:
I'd spend a short fixed amount of time, say 2 days tops, trying to make the old control run. It it works, great, but it won't last long. Either way, start learning EMC2, you're used to linux so its your best bet.
Iggy, you're in the heart of a dying industrial machine town. You can find a professional working CNC machine real cheap. IMHO, spend maybe 5K and get a real CNC machine. Have Gunner tell you what to get.
Karl
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.