CNC Bridgeport with Heidenhein control

I am hoping that I could fix that system and use it as-is.

i
Reply to
Ignoramus26960
Loading thread data ...

Can you explain what you mean.

Tell us about it Jon.

i
Reply to
Ignoramus26960

How hard is it to take the head off to make it stand lower? 8 ft will not fit through my garage door, fsck

i
Reply to
Ignoramus26960

If the controls are single phase, I could then convert the whole mill to 1 phase, right? Maybe with just one 220v relay to drive a vfd from a 220v signal? (I want to disrupt the control as little as possible)

i
Reply to
Ignoramus26960

You certainly should be able to.

Since the existing motors are servo motors, not stepper motors, you will need a card for the computer which may be fairly expensive (about what you likely paid for the machine and the tooling).

And you may have to make some intermediate circuitry to feed the pulses from the Heidenhein scales into the computer. Other and later brands tend to output shaped square waves (two -- at a 90 degree phase shift) so you can count how far it moved, and in which direction. The older Heidenhein ones (such as some that I have) output a sine wave, and need special shaping circuitry before feeding it to the counting circuits.

O.K. You will have motors to move the axes. On many inexpensive home conversion projects, it will typically be using stepper motors, and the position will simply be inferred from counting the pulses fed to the steppers -- assuming that they never miss a step. This also applies to the early Bridgeport machines like the BOSS-3 Series I which has big heavy steppers, and mag amps to control the voltage to the steppers so higher speeds get higher voltages, and slower speeds get lower voltages to avoid overheating the windings. The higher speeds need the higher voltages to overcome the inductive characteristics of the windings.

Servo motors are a very low inertia DC motor, or special AC servos. The ones which I have experience with are the DC ones. Both have a tach generator so the speed can be monitored and controlled.

To move at a specified speed with steppers needs a train of pulses at the right intervals as long as it is moving.

To move at the same specified speed with servos, a command voltage from the computer via a D/A converter goes to the servo amp, which maintains the speed based on the tach feedback, and the computer can be busy doing other things, and only check every so often that the motion is correct. It does this by encoding scale which generate pulse trains with motion -- or with an encoder disc on the end of the motor. This is typically fed to a counter which can be read by the computer to verify that it is where it should be.

It is either 2-1/2 axis or 3-axis -- depending purely on the controller computer.

2-1/2 axis allows moving to a given Z axis position and then cutting normally in the other two, while 3 axis allows all three axes to be changing at the same time, resulting in very complex workpiece shapes.

You can also add other axes such as rotary tables for even more complex operations.

Check out

formatting link
for a download of a live CD of the most recent version, and lots of other information.

Good Luck, DoN.

Reply to
DoN. Nichols

Guys, what do you think about these controls

formatting link
specifically this

formatting link

Reply to
Ignoramus26960

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

formatting link
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

formatting link
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

Reply to
Jon Elson

Well, I was going from a picture of a "similar" machine, so yours could be different. But, yes, if the control all runs off single phase, then feed it 240 single phase, and rig appropriate relays to control a VFD. Might as well leave the VFD power on continuously, and switch the control inputs to the VFD (forward and reverse).

Jon

Reply to
Jon Elson

This is exactly what I would do wrt a VFD. Fortunately, I have a VFD handy in the shed. This is the smallest one of my problems.

I also do not need rigid tapping and will not put an encoder on the head.

i
Reply to
Ignoramus2215

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

Reply to
Jon Elson

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

I will be sure to post this.

i
Reply to
Ignoramus2215

formatting link

formatting link
Well ... the one thing which worries me about that one is the term "digital servo" -- which suggests that it really needs something which accepts a pulse train like a stepper drive does, rather than an analog voltage which says "move at this speed". There are Gecko drives which do this for brush type motors, which your machine appears to have, but I would personally prefer a true analog servo driver with the voltage inputs for speed command. (And your existing drivers probably expect an input range of +10V to -10V for full speed forward and reverse, with any intermediate value for any other speed.

I like the apparent mechanical design -- though the ones which I have seen in service did not have (or need) a keyboard.

The X15-250-5 looks like a better match for your needs, as it is designed to work with analog servos.

Note that they all are based on Windows to run Mach3, and *you* might prefer EMC2 (linux based) for various reasons. Also -- the prices scare me. :-)

Good Luck, DoN.

Reply to
DoN. Nichols

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.

Reply to
DoN. Nichols

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

Reply to
cncmillgil

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

Reply to
Jon Elson

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

#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. :-)

Thanks much, DoN.

Reply to
DoN. Nichols

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.

Just some stuff to consider

RogerN

Reply to
RogerN

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.

i
Reply to
Ignoramus27062

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.

Jon

Reply to
Jon Elson

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. ======================================================================

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.

Reply to
DoN. Nichols

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.