CNC Bridgeport with Heidenhein control



    [ ... ]

    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:

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

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:

Depends on the condition, how long it has been since it last ran, and whether the prints for the boards come with it. If no prints, you are in a HEAP of trouble.
My experience tells me to not bother unless all it needs is a new video monitor AFTER!!!! you get it moved to your location. If it has serious problems, it can become a total time sink.
I've had GREAT results with EMC, and would NEVER go back to the proprietary control.
Jon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus26960 wrote:

I gather you've already bought the thing. So, part of the decision is already done.
Sure, see if you can get the old control to fire up at all, you should be able to tell from lights on the control panel, etc. Maybe scope some of the EGA signals to determine if H and V sync is coming out of the 9-pin plug. If so, go ahead and get the EGA-VGA converter and see what the control can do, whether it suits your one-off machining needs. I don't know the TNC-151 control, it apparently came in two flavors, one with G-code and not much else, and one with Heidenhain's proprietary language and their conversational machining package. The conversational thing may be what you would find useful. Practically no need for CAD/CAM in that case.
If the control doesn't fire up after the move, then you have to see how much time you want to put into finding out what is wrong. It could be a board wiggled loose during the move, or much more serious. Connectors and tantalum capacitors are the two big problem areas in these older systems.
Jon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

It has conversational. I was reading manuals yesterday (I already took possession of tooling and manuals)

I will be sure to post this.
i
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

I have experience with Heide's recently & with B-Port series II's eon's ago. The old original seriesII NC (early 70's) had cog belt drive stepper moters for XYZ. The Z (knee) was air assisted. Also an pneumatic quill with a "spindle wizard" (stops for depths) The one I used back when,had a Bridgeport control, remex tape reader that I converted to a BTR floppy disk reader, had what they called "tab sequential" code to run it. But no handles to run it manually. I know some series II's did, but not the NC models.
Being that the Heide control is on yours, seems alot newer & most likely has servo's.. Fixing the Heide control is the way to go if possible. IMO their conversational input is only second to Hurco. But even easier on some things Hurco can't do.
looks like a fun project.
Good luck
--
___ ___
/ /\ / /\
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus21067 wrote:

You need to get into it to see what is there, and what it looks like (mouse-eaten wiring, burned parts, etc.)
First, ID the motors, and see what velocity feedback it may have there (encoder on motor, tach, etc.)
Second, ID the servo amps - just follow motor armature wires back into control cabinet, and wherever they stop should be the servo amp. Westamp and Servo Dynamics were the big players at that time, and a lot of control builders used them. Docs are still available.
See if the servo power supply needs 3-phase or can run off single.
3rd, ID the main position encoders. With a Heidenhain control, it is likely to be linear encoders on the machine table. But, Heidenhain had their own proprietary current-output scheme for encoders. Some of their encoders had very low native resolution, and the sine-wave current outputs were fed into interpolator boards to increase resolution. If so, you want to save those boards.
Once you have this info, you can start looking at interface hardware to connect to it. You can also decide whether to use the servo amps, or scrap them.
Jon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus21067 wrote:

Did it not come with a controller, Iggy?
--

Richard Lamb
http://www.home.earthlink.net/~cavelamb /
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I have not brought it home yet, but it does come with a controller and, if I am to believe the seller, the only thing wrong is the display that has a bad transformer (which is something weird and cannot be replaced).
i
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.