[Home]GantryPlasmaMachine

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

Showing revision 247

A2 MechShop Gantry Plasma Machine (Now a tool available at [Maker Works in Ann Arbor])

1. Overview
1.1. Design Goals
1.2. Performance
1.3. Cost
2. Hardware
2.1. Vendor List
2.2. Mechanical
2.2.1. Electronics Enclosure
2.2.2. Table
2.2.3. Joe’s CNC and Cast CNC
2.2.3.1. Customizations to Joe’s / Cast CNC Plans
2.2.4. Z Axis
2.2.5. Water Table Construction
2.2.6. Cutting in Water
2.2.7. Torch Holder
2.3. Electrical
2.3.1. Wiring Diagram
2.3.2. Power Supply
2.3.3. Motors
2.3.4. Servo Drivers
2.3.4.1. Granites Vs. Gecko
2.3.4.2. Tuning the Granite Drive PID
2.3.5. Encoders
2.3.5.1. Differential to Single Ended
2.3.5.2. Optical vs. Capacitive Encoders
2.3.6. Pulse Generator (Mesa)
2.3.6.1. Mesa card Theory of Operation
2.3.6.2. Tuning The Mesa Card PID
2.3.7. Connectors and Misc.
2.3.8. Torch Height Controller Hardware
3. Software
3.1. GUI
3.1.1. PyVCP
3.1.2. Glade
3.2. Torch Height Controller
3.2.1. THC Design Goals
3.2.2. THC Theory of Operation
3.2.3. THC HAL Control
3.2.4. THC Python State Machine
3.2.5. Limit3step.comp Realtime Module
3.2.6. Custom M Codes for THC
3.3. Homing Controller
3.3.1. Homing Design Goals
3.3.2. Homing Theory of Operation
3.3.3. Homing HAL Control
3.3.4. Homing Python State Machine
4. Files
5. Videos

1. Overview

Hello from the [Ann Arbor Mech Shop]!

This page documents an example of a working servo motor based gantry plasma machine with a torch height controller (THC). Linuxcnc version 2.5.0pre2 is used as control software and Gladevcp is used for the THC controls and other user interface buttons in Axis. All configuration files are included in this document, and are the actual, working files. The goal is to share information and lessons learned in the hope that it will save other users time and tribulation.

There are several defining aspects to this machine setup:

  1. Has dual motors on the Y axis (not uncommon for a gantry).
  2. Uses servo motors with encoders - many gantry style machines of this type are built with steppers.
  3. Uses step/dir signals to drive servo motor drivers.
  4. Uses stepgen in velocity mode rather than position mode.
  5. Essentially wraps a pid control loop (from Linuxcnc) around a pid control loop (within Granite drive servo hardware).
  6. Interfaces with a hardware torch height controller for plasma cutting.
  7. Uses Gladevcp for user interface controls within Axis.

1.1. Design Goals

The machine is designed as a 3-axis, 4-joint (motor), gantry-style table that carries a plasma torch or a router. It is currently configured for a plasma torch. It has at least 4 feet of travel in both X and Y, and about nine inches of travel in Z though it is about 6 inches from the top of the workpiece to the bottom of the gantry. We used servos for motors to assure position feedback, and have plenty of torque for when the machine is used as a router. Speed of movement is a priority over thousandth-of-an-inch accuracy, so a rack-and-pinion drive was used for X and Y. A surplus ball screw and linear rails were available for the Z axis, and speed didn’t need to be quite so high for that axis, so we used a ball-screw drive for the Z.

Here is a picture of the completed machine: [1]. Videos of the machine cutting can be seen here [2] and here [3].

The basic plans were based on [Cast CNC] design, which we purchased. The CastCNC plans are, in turn, based on the [Joe’s CNC] design. These designs are for stepper motor setups, and we ended up making significant changes to the motor mounts to get the servos to work properly.

1.2. Performance

The machine is currently configured to move 1250 inches per minute on all axes. Accuracy hasn’t been measured yet, but is believed to be at least within +/- 1/32” over the full travel, if not better.

1.3. Cost

All told, we ended up putting in about $8k into the project. That includes absolutely everything except the cost of our time and the building rent. This also includes things we over-bought like 3 Geckos 320X, screws in packs of 100, wire in rolls, etc. Probably $2k of the cost was adding higher end servo drivers and gearboxes when it became apparent that the initial design did not have enough speed reduction for servos (the plans assumed stepper motors). If I were to do this again, I would design the motor mounts differently from the start, and save quite a bit of money.

upload:IMG_2624.jpeg

2. Hardware

2.1. Vendor List

2.2. Mechanical

2.2.1. Electronics Enclosure

The electronics enclosure is actually two enclosures that were purchased from a scrap yard joined with several conduit spacers to provide wiring paths between the boxes. As much as practical we tried to keep the high power components in the larger cabinet and the pc and low-voltage hardware/signals in the smaller cabinet. We had originally reserved space for a second linear power supply in case we needed it but the space was soon consumed by the Granite servo drivers.

Some photos of the electronics cabinet are here: OuterCabinet, InnerPowerCab, InnerPCCab, InnerBothCab

2.2.2. Table

We used 8020-like aluminum extrusions (with t-slots) from the scrap yard to build the base table. Not nearly as rigid as a welded table, but good enough and we had it in the shop. Also, it will be possible to take things apart if we need to move the machine out of the room it's in.

When we had gotten the motors moving we noticed that the table flexed quite a bit. Quick movements of the machine would cause fairly severe oscillation of the table. We reinforced the 8020 frame with a few pieces of sheet metal as well as 1-1/2 X 1/8" steel bars. This helped immensely, the table is now quite rigid. It is sitting on casters that have rubber pads that can be lowered in order to level the table. There is still a small amount of movement that we think is due to the rubber pads flexing. But it is not enough to cause a problem. If we move the table at some point we may decide to put some screw-in type metal leveling feet that won't move.

EarlyTable ReinforcedTable1 ReinforcedTable2 ReinforcedTable3

2.2.3. Joe’s CNC and Cast CNC

We used the Cast CNC parts which we purchased, and the Joe's CNC plans with the rack-and-pinion configuration.

2.2.3.1. Customizations to Joe’s / Cast CNC Plans

We didn't like the Z axis from the Cast CNC parts kit, so we made a custom one ourselves. Cast CNC no longer sells the original Z axis we had, so this change shouldn't affect anybody considering a new build. I think they now sell it with a pre-built Z axis very similar to the one we built.

With the ability to machine parts (we have a CNC mill in the shop) and all I've learned, I don't think I'd use these plans again. The plans do work as advertized and make a good machine -- I just think I could do better now ;-) Also, we ended up making custom motor mounts for X and Y due to the servo drives needing more speed reduction (these plans are for stepper motors), and we re-did the Z from scratch.

2.2.4. Z Axis

We custom designed and machined mounting blocks, plates, and such on the CNC mill we have in the shop. The ball-screw and linear rails were all from the scrap yard!

We designed the Z Axis mechanism in Alibre Design [5] and produced gcode from .dxf files in Sheetcam [6] to cut the various parts. 3D PDFs are a nice way to share 3D cad drawings since Adobe Reader is cross-platform. I am not sure if there are other PDF viewers that support 3D PDF, I know Preview on MacOSX does not. Here is a 3D PDF file of the mechanism. Right-click on this link and download the file, then view it in Adobe Reader: [7]

2.2.5. Water Table Construction

The top of the table is 58" wide by 72" long. We wanted a water pan to cover this whole surface and not be too heavy so that it could be moved on and off the table if we wanted to remove it for using a router. We drew up a pan in Alibre Design using it's sheet metal design function. The pan was nicely folded over the sides and would just require welding the corners closed. It could be made out of 20-22 gauge steel and would weigh about 70-80 lbs. However, the sheet metal would need to be just under 6' wide even without folding the edges over. It turns out it is difficult to get a piece of steel sheet metal wider than 5'. One fabricator we talked to suggested welding two pieces together but warned us that it would probably be somewhat warped at the seam.

After some deliberation we decided to use a somewhat unique approach to building the water pan. We purchased a sheet of 6061 Aluminum sheet which was 5' X 12' X 1/16" from Alro Metals [8]. They have a 72" wide shear and cut the sheet to 57.5" X 71.5" (bottom piece) and with the left over, cut pieces 57.75" X 4" (ends) and 71.75" X 5.5" (sides). We also purchased 1/8" aluminum "L" channel. We mitered the "L" channel on a metal cutting chop saw to form a frame that was 57.875" X 71.875" inside dimension. Using 3M VHB 4956 tape [9] we taped the bottom piece and the sides to the "L" channel. We taped a small piece of "L" channel vertically in each corner as well to join the side pieces and seal the corner. Then we caulked around all the seams with 100% silicone caulk. The result is an amazingly strong and rigid pan that weighs only 45 lbs.

Pictures: WaterPanFrame, WaterPanBottom, WaterPanSides, WaterPanSide, WaterPanComplete

Don't weld it, tape it! [10]

2.2.6. Cutting in Water

People have asked if the water really helps with the mess (dust and debris). The answer is a big YES! You don't even need to partially submerge. Just having the part above the water helps immensely. Before we had the water pan we were limiting cuts because the fine dust that is created spreads throughout the room. A few cuts and everything in the room was covered in a fine black powder. My Macbook has magnetic latches in the screen and had small piles of filings stuck to the those magnets. With the water table, even with the part above the water, as far as I can tell nearly all of the dust is eliminated. There is still some, I am sure, that comes from the top of the part, sparks will fly off the top to a minor extent, but the fine dust does not appear that I have been able to tell. And if the part is just below the surface (even just on the edge of above and below) you have very few sparks from the top.

The water is about 2 inches deep. The aluminum water pan does not get damaged -- two inches of water is enough to prevent excessive heat from reaching it. We are using a 45 amp (Hypertherm PowerMax 45) cutter. I don't know if a more powerful plasma cutter would need more water. We've tried cutting parts anywhere from just in the water to 1/2" above the water, and in all cases the smoke and dust is greatly reduced.

Why is that water so green? We had some Green Cut [11] in the shop. It was left over when it didn't work out for use on a mill. For the few weeks we have been using it, it seems to work fine, no rust has appeared. It claims to be non-toxic and biodegradable. They claim you don't have to change it, you can just keep adding to it. They also claim you can drink it but that it tastes horrible. I'll take their word for it, thank you.

We have drain fittings on the water pan and at some point will buy a pump to be able to drain and re-fill the table in order to clean the scraps out. We will also be able to use the pump (and gravity) to lower and/or raise the water level to accommodate whatever we are cutting.

2.2.7. Torch Holder

The torch holder was generously donated by a friend that was upgrading his Plasma Cam table [ http://www.plasmacam.com]. It is made to hold a handheld style torch and has built in limit switches. It is quite easy to attach the torch and square it up to the holder using the thumbscrews that hold the handle and the nozzle. I don't know if Plasma Cam sells the holder by itself. It was a timely gift, thanks! (You know who you are ;-)

upload:torchholder1.jpg

2.3. Electrical

2.3.1. Wiring Diagram

A full system wiring diagram in both PDF [upload:Gantry-Plasma-Wiring.pdf] and Eagle (version 6.20) .sch [upload:Gantry-Plasma-Wiring.sch.zip] file formats is attached. Note that the .sch file will not open in Eagle 5, only in 6.2.X.

2.3.2. Power Supply

We have 3 independent power supplies in the electronics cabinet. The linear supply with the large toroidal transformer supplies 72V DC @ 20A and was purchased with the servo motors from Keling but are also available here [12]. We have a small 5V DC supply, a Meanwell RS-15-5 [13] to provide power to the Mesa cards, the LCTHC, our Charge Pump circuit [14] and other low voltage electronics. After we decided to go with the Granite Devices servo drivers we needed a 12V supply. So a Meanwell RS-15-12 [13] was also added.

2.3.3. Motors

The motors driving the X and two Y joints are Nema 34 servo motors from Keling [15]. The specs are here: [upload:KL34-180-90-Motor.pdf]. The motor on the Z axis is a smaller Nema 23 servo also from Keling, specs: [upload:KL23-130-60-Motor.pdf].

We wanted to use servos for a list of reasons, including to gain more experience with using them. One of the biggest lessons is that proper speed reduction is absolutely critical with servos.

There needs to be a fair amount of isolation between what is happening on the table, and the motor. Our initial design had a 2:1 belt reduction, and then a 1-inch pitch diameter pinion. So, every turn of the motor resulted in about 1.5” of linear movement (pi/2 inches, to be exact). This is simply not enough reduction, and it was very difficult to tune the motors.

When using servos, you want isolation between the motor output and the table motion. It should be hard to grab the truck and move it when the power is off. With our initial setup, this was not at all the case; you could grab the truck and slide it along the table. Any little bump or vibration on the table would be felt directly by the motor, and the servo PID loop would tend to over-react, and growl or oscillate. Tuning was difficult.

We switched from the Gecko servo drives to the Granite servo drives, which have much more sophisticated tuning capabilities. The results improved, but the motors were still noisy when running. We added a 10:1 gearbox speed reducer, eliminated the 2:1 belt drive, and switched the pinion to one with a 2 inch pitch diameter. The result of all this was that 1 revolution of the motor now moved the truck 0.6283” instead of 1.5707”. The truck is now still possible to move when the power is off, but you have to really push it – this is what you want.

With the gearboxes in place, the motors run smooth and quiet, and have tons of torque to spare. The cost is that we have a max speed of 1250 inch-per-minute instead of about 2800 inches per minute or more, but the improved quiet/smooth performance is well worth it.

The Z axis was designed from the beginning to use a 0.2” pitch ball screw, directly coupled to the motor. This means the truck moves 0.2” per revolution. It is extremely difficult to move the truck by hand with the power off. As expected, this works fine with the servo driver, and we are still using the original Gecko drive on the Z.

2.3.4. Servo Drivers

2.3.4.1. Granites Vs. Gecko
I mentioned in the “Motors” section above, we are using [Granite Devices] VSD-E drives for the X and Y axes, and a [Gecko] 320X for the Z. The Granite drives are about 3 times more expensive than the Geckos.

The Gecko drives were impossible to tune on the X and Y in our initial design, so we upgraded to the Granites. We were able to tune them with the Granites, although still with some difficulty. We made the various changes to the mechanical setup, and then the Granites worked wonderfully. Although we could switch back to the Geckos with the mechanical changes, the Granites do have a much more sophisticated controller that results in better performance. In addition the Granites have a very nice home-to-hard-stop feature that we wanted to use, so we decided to keep them. Also, the Granites were already installed and working!

For the Z axis, the Gecko 320X worked great out of the box.

These are both good drives. The Granites cost a lot more, but do have a much more sophisticated controller that does improve performance (i.e., you can get faster acceleration times from the motors). They both also have some rough edges. I don’t care for the analog trim-pot tuning for the Geckos. There are a couple of settings on the Granites that need to be set properly or you will get weird results (see tuning section below), and the required power-off cycle to put the Granites in programming mode is annoying. However, once they are setup and tuned, either drive will perform its job as advertised.

2.3.4.2. Tuning the Granite Drive PID

The Granite devices documentation is pretty good, so I won’t repeat the process here. However, there are a few tips:

  1. Turn OFF the input smoothing filter. The filter introduces a delay, which causes havoc in combination with linuxcnc’s PID loop.
  2. Some of the Granite documentation suggests that you first tune the torque controller, then the position mode controller. If you do this, do not over tune the toque controller. You will see that you can get good results, but you can keep setting the P/I terms higher and higher and get very small increases in performance on the torque response curve. Don’t do this. Just shoot for the lower settings that get ok results. Otherwise, you will get occasional over-current faults on the drive. You can tweak the PID or PIV settings in position mode all you want, but leave the torque settings as not-very-aggressive.

2.3.5. Encoders

2.3.5.1. Differential to Single Ended

We made a circuit board to convert the differential output of the encoders to single ended for the Gecko drive and also the Mesa card (both these cards use single ended inputs). It also isolates the signal for the PC (the geckos already have isolated inputs). The Eagle schematic files are in [16]

For this small prototype PCB run, [Silver Circuits] did well for us. There are many other PCB houses out there, so feel free to look around.

[PDF view of schematic.]

The parts are:

2.3.5.2. Optical vs. Capacitive Encoders

We initially chose the CUI AMT-102 capacitive encoders [17] to put on all axes. These encoders are inexpensive (< $25 each) and are easy to install. You can buy a cable that provides a differential driver (shrink wrapped into the cable) for about $8. We had used these encoders on a small mill with stepper motors to be able to fault if we had a position error and we found them satisfactory. They can be purchased from Digi-Key [18] as well as other suppliers.

During our tuning of the servo system we observed a small position error at beginning and end of acceleration while jogging (an error of about 0.003"). Jon Elson posted on the emc-users@lists.sourceforge.net mailing list that he had observed this behavior with the CUI AMT-102 encoders and that it was due to their interpolation of the data not being as robust as other encoders. [19]

However, if you run into this problem CUI claims you can improve the time constant by removing a jumper (at the risk of increased signal noise). See [ http://www.amtencoder.com/Resources/Frequently-Asked-Questions#3]. We removed this jumper and did see a small improvement in the error on initial acceleration and the blip mostly went away on deceleration. But we still had a very small position error (less than 0.002") so we decided to buy a US Digital Optical Encoder [20] and try it on our X axis. It turns out that US Digital makes a version of this encoder that is pin compatible with the CUI encoder so it was a very easy thing to swap out. If the US Digital Encoder improved things at all it was barely perceptible (certainly less than 0.001). We still have a very tiny blip at the start of acceleration even with the US Digital device. The USD encoder was almost 3 times the price of the AMT encoder. While we kept the US Digital one on the X axis, if we had to make a choice we would go with the CUI encoders due to their price.

There is one thing about the CUI encoders that leaves a bit to be desired. They attach to a motor shaft using a plastic collar. You get a bunch of different sizes and pick the one for your motor shaft size. While these work ok, they aren't always the tightest fit. We had some tuning issues early on with the servo machine and Mariss at Gecko suggested that we put a drop of super glue on the collar (at the shaft) in the little channels there. We did that, and on one axis it made a large improvement. We think during quick acceleration it was slipping a bit. The collar was stuck well on there with the glue, but it didn't take a whole lot of prying to get it off when we wanted to try the US Digital encoder - the super glue works up to a point on smooth metal.

2.3.6. Pulse Generator (Mesa)

This machine uses servo drivers that take step/direction pulses as input, and have an internal PID loop for controlling the motor. The information in this section does not apply to systems that use linuxcnc to directly control an analog or PWM controlled servo amplifier with no internal PID controller.

General Purpose I/O (GPIO), encoder and step/direction signals are to/from a Mesa 7I43-U-4 Anything I/O USB/parallel 400K FPGA card. [Mesa card] with two Mesa 7i42TA protection cards attache. The 7i43 is connected via the parallel port of the Intel D510MO motherboard which runs a special firmware load from Mesa. See Mesa firmware .pin (text info) and .bit (firmware binary) files in the Files section at the bottom of the page.

The Mesa card is responsible for actually generating the step/direction pulses that the servo drives use as input.

2.3.6.1. Mesa card Theory of Operation

This was a point of some confusion for us. The Mesa cards do NOT generate pulses on command. The card generates a pulse frequency. In other words, linuxcnc controls the velocity of the Mesa cards output, not the position.

So, looking at the PID loop setup in the main a2gantry.hal [upload:a2gantry.hal] file, we see something like (taking the X axis as an example):

 net X.pos-cmd axis.0.motor-pos-cmd => pid.0.command
 net X.pos-out pid.0.output => hm2_7i43.0.stepgen.00.velocity-cmd

X.pos-cmd is a position command that goes into the PID, but X.pos-out is not really a position out, it is a velocity out. We should rename that someday…

The reason this works is how the PID is set up. In linuxcnc, a PID has some extra feed-forward parameters that it can use in addition to the normal P, I and D terms. The important one here is FF1, which is the velocity feed-forward term (FF1 refers to feed-forward the 1st derivative of the input, which is velocity). From the hal file, this looks like this:

 setp pid.0.FF1 [AXIS_0]FF1

Where [AXIS_0]FF1 comes from the a2gantry.ini [upload:a2gantry.ini] file:

 #********************
 # Axis X
 #********************
 [AXIS_0]

 #Encoder/PID
 P=15
 I=0.000
 D=0
 FF0=0.0
 FF1=1
 FF2=0.00105
 BIAS=0.0
 DEADBAND=0.0001
 MAX_OUTPUT=0

Notice that FF1 term is set to “1”, which means that the velocity of the input position command is fed directly to the output. This is what we want, because the output needs to be the velocity of the input, because the Mesa cards take a velocity command.

As a first pass, setting the FF1 parameter to 1 and all other parameters to 0 will work OK.

The next parameter that can be tweaked is the FF2. This is the acceleration (2nd derivative) of the input position command. Since there is a bit of delay between the time the motion controller commands a position change and the time the Mesa card gets the message and makes the change, a small error accumulates during times of acceleration. To compensate, a small feed-forward of acceleration will help. See the next section for the method to tweak this parameter.

Finally, if for some reason there is a constant error the position (i.e., a difference between what the encoders read and what the motion controller has commanded), the feed-forward terms will never correct for it. The feed-forward terms don’t actually use the error term (feed-forward terms are open-loop). To close the loop, the P (proportional) term can be set. This will cause the velocity of the motor to increase such that it will decrease any observed error.

As an extra step, if the servo drives are dithering (humming a little as they move back and forth between one or two encoder counts), this may be a feedback loop between linuxcnc and the hardware driver. If this is the problem, it can be fixed by setting the DEADBAND parameter to a small value corresponding to one or two encoder counts.

2.3.6.2. Tuning The Mesa Card PID

First off, the FF1 term should be set to 1, and all others set to 0.

In the HAL file, create a signal that monitors the error of the drive, like this:

 #****************
 # utility/debug - plot the x position error for viewing on the halscope
 #****************
 setp sum2.5.gain0 -1.0
 setp sum2.5.offset 0.0
 net X.pos-fb sum2.5.in0
 net X.pos-cmd sum2.5.in1
 net xposerror sum2.5.out

(don’t forget to add “loadrt sum2 count=xxx” and “addf sum2.5 servo-thread” commands at the top of the HAL file)

Now you can use the HAL scope in Axis to watch the error on the X axis as you move around. Set the jog speed to something reasonably fast, and move the axis back and forth while watching the error on the scope. You should see the error spike at the beginning of the move, level off after the initial acceleration, and return to zero at the end of the move during deceleration. Use the HAL Configuration tool in axis to change the FF2 term until the error no longer jumps up much during the start of the move. Finally, increase the P term to eliminate the remaining following error during the constant velocity part of the move.

If the drives hum or buzz while not moving, you might try increasing the DEADBAND parameter to 1 or 2 encoder counts worth of movement.

2.3.7. Connectors and Misc.

Neutrik [21] has a nice line of cable, pass thru, and panel mount connectors that are reasonably priced. The connectors are locking, provide water sealing gaskets, and seem to be well made. We used their Powercon line [22] 20A connectors for the motor wiring, their Etherncon line [23] ethernet connectors for the encoder wiring and their XLR line [24] for limit switch wiring. We bought ours from Mouser but there are other suppliers as well.

Here is a photo where you can see the Powercon connectors going into the electronics cabinet. The Ethercon and XLR connectors are hidden below the big blue connectors. [25]

I like these [switches] from [Automation Direct]. They allow you stack up contactors as needed and you can get normally open or normally closed as needed. Here are a couple photos of them in our electronics cabinet. [26], In this one you can see 4 sets of contactors on our EPO switch. They are for breaking power to the linear supply, the two external outlets for future router and dust collection, as well as a signal to the Mesa card that the EPO has been tripped. [27]

2.3.8. Torch Height Controller Hardware

3. Software

3.1. GUI

The configuration files for running this with Axis are included. To extend the Axis GUI with custom features, we first used PyVCP. The files for this are included below. Then we did it again using Glade, as we wanted some of the new features available from Glade. The Glade files are also included, and this is what we are using now. We have implemented a few more features in the Glade version than the PyVCP version. At this point the PyVCP files are not being developed, and are put here just as a (working) example for others.

3.1.1. PyVCP

We have included files below for this configuration running a PYVCP panel for the THC control. The files a2gantry-pyvcp.hal, a2gantry-pyvcp.ini, and custom_postgui_pyvcp.hal replace the a2gantry.hal, a2gantry.ini, custom_postgui.hal files respectively. The additional file custom_pyvcp.xml file is the description of the panel itself and needs to be placed in your ./config directory along with the others.

The PYVCP panel is slightly different in that it doesn't include the Touch Off functions that are in Glade.

3.1.2. Glade

Why Gladevcp? Gladevcp is new in the Linuxcnc 2.5 release and is intended to be a more flexible replacement for PYVCP. The reason we used Glade originally was because when you change a setting in a PYVCP panel (say, one of the THC spinbuttons) focus in Axis is lost. This is potentially hazardous as well as slightly annoying. Even the escape key doesn't function until you click on a tab or other menu in Axis to allow it regain focus, so you can't estop the machine from the keyboard without first clicking somewhere. The issue of focus is fixed in Gladevcp. We learned later there are other nice features in Glade. One is flashing LEDs. Seems trivial but a flashing LED is much more obvious than a non-flashing one to indicate, for example, you are in e-stop or in a homing sequence. Also, you can easily create buttons to execute MDI commands. The Touch Off buttons, for example, simply send a gcode command to perform their function. Need multi-line gcode commands? Create a subroutine and call that. This is what our "Go Home" and "Machine Zero" buttons do. You can easily add tooltips to your buttons and displays when you hover over them with the mouse. Glade, the editor for the widget layout, allows much more flexibility in layout than was possible with PYVCP.

Below is an image of our Axis pane with the custom Gladevcp panel on the side: upload:Glade-Panel.png

3.2. Torch Height Controller

Incorporated into the electronics cabinet is a Low Cost Torch Height Controller (LCTHC) from candcnc.com [28]. The THC controls the plasma cutter torch height by monitoring the voltage at the tip, and giving a command to move up or move down if the voltage varies from the set point (set on with a knob on the front of the LCTHC hardware). Linuxcnc must take the two GPIO signals (Move UP and Move DOWN) and move the torch accordingly.

The LCTHC also takes as a GPIO input a signal to fire the torch, and reports a GPIO output signal if the arc is OK. Candcnc.com has documentation on how to wire the LCTHC into the plasma cutter itself to make all these signals work.

We are using a Hypertherm Powermax 45 handheld torch. To use this torch with a THC requires the use of unshielded (vs shielded) consumables on the torch. When using shielded consumables, this type of torch is intended to be dragged across the surface of the material. With unshielded consumables it can ride above the material at a distance determined by the thickness of material and voltage setting on the THC.

3.2.1. THC Design Goals

The THC in Linuxcnc must use the Move Up, Move Down, Arc OK GPIO, and float-switch input signals, the Fire Arc output signal, and use them appropriately.

First of all, we don’t always want to use THC (such as when there is a router mounted instead of a plasma torch). So to do this, there should be a master-disable. Second, sometimes the plasma torch can’t pierce through the material because it is too thick. To accommodate this, a side-entry mode is supported.

In THC Mode, with Side Entry DISABLED, the Z axis should:

  1. If a program is not running, then the THC should not affect the Z position. Otherwise, obey the following rules.
  2. Before the first cut, Z should move to a safe Z position, as specified in a2gantry.ini as [PLASMA] SAFE_Z_IN_MACHINE_COORDS = -0.1
  3. When a “spindle on” command is issued (M03):
    1. issue a feedhold to prevent X and Y movement.
    2. Lower the Z axis until the float switch is triggered
    3. then move up until the float switch is released
    4. then move up by the “Gap Distance” specified in the GUI
    5. Trigger the Arc to fire (set the GPIO pin)
    6. wait for the Arc OK GPIO pin to turn on, or time-out after “Arc OK Timeout” as specified in the GUI
    7. if the Arc OK Timeout has expired before an ARC OK signal, then restart this firing sequence
    8. while Arc OK is set, turn off the feedhold so X and Y can move as normal
    9. if the Move Up GPIO is set, Z move up at the VEL_LIMIT_THC_ACTIVE speed (specified in a2gantry.ini [PLASMA] section)
    10. if the Move Down GPIO is set, Z move down at the VEL_LIMIT_THC_ACTIVE speed (specified in a2gantry.ini [PLASMA] section) but stop if the float switch triggers
    11. if CHL (Corner Height Lock) mode is enabled, ignore the Move Up and Move Down pins when the X, Y velocity is below a threshold. The idea is that the X and Y velocity will go down when going around a tight corner. In this instance, we don’t want the torch tip to dive, as we assume the X, Y velocity will increase in just a moment, after the corner is done.
  4. After the M05 command to turn off the plasma arc (“spindle”) move up by the Travel Offset as specified in the GUI. This is the safe-z height to move after the material has been located once by a arc firing sequence with the float switch.
  5. When the program exits, return to the last commanded Z height. This is either the Z height that was set before the program started, or the last G00 or G01 commanded Z height from within the program. Note that “G00 Z??” in a program will not do anything right away while THC is active, but it will set the Z height the axis will move to after the program ends.

If Side Entry is ENABLED, then the sequence is a little different.

  1. For the machine to find the location of the top of the material, the program must issue a M130 command to probe the material location. This will cause the THC controller to move down until the float switch triggers, then move up to the safe-Z travel distance.
  2. The program can then move to the cut start position, which is not actually over any material (it is expecting to fire the arc over air, then move in from the side).
  3. A M03 can now be issued as normal. Instead of probing, the THC controller will move the Z axis to the last probed height (from the M130), and fire the arc.
  4. Instead of waiting for an arc ok, the controller will immediately allow X and Y movement. Move UP and Move Down commands will be ignored until the Arc OK becomes true (presumably because the torch moved over some material and started cutting).

3.2.2. THC Theory of Operation

We originally got a THC config example files from James Cizek who had managed to adapt previous config files to work with the LCTHC. However the logic in those configs was difficult to follow since it was all HAL configuration and there were a couple bugs that we could not track down. We decided to redesign the THC logic, but used a bit and pieces of the original design, in particular the “Corner Height Lock” HAL code.

The new code now splits out some of the work into a python user module, which greatly simplifies the HAL portion of the logic.

The file A2THC.hal [upload:A2THC.hal] contains the HAL code that monitors the various pins (Move UP, Move Down, Arc OK, Float Switch, etc..). The state of the system is tracked by a user module in [THCStateController.py].

The state controller python code monitors the various inputs, and determines the current state. Based on the current state, a different position command is passed to the Z motor controller. As the state of the system changes, different Z positions will be selected.

To limit the acceleration, velocity and position of the movement when the commanded Z position changes abruptly (due to a state change) the limit3step realtime component is used. The file limit3step.comp contains the source for a real-time component based on the standard distribution component named limit3.comp. The standard limit3 component serves the same function, but it exhibits some problems (such as moving in the wrong direction) when the input commanded position changes too abruptly (i.e., when it “steps” from one value to another). Limit3 assumes the input is changing continuously, not in jumps. So, limit3step is a different version with a different assumption about the input.

3.2.3. THC HAL Control

The logic diagram of the LCTHC we have implemented was drawn up in Eagle (the circuit board design software). The pdf version is here: [upload:THC_System.pdf]. It is easier to follow if you have a large display to view it on. The original Eagle (.sch) file of this is here: [upload:THC_System.sch] if you would want to modify it.

The first thing to notice is the “State Machine Module” at the top center. This is a user-mode block of python code. It is monitoring various inputs (on the left of the box) and outputting appropriate commands based on the current state of the system. The python code handles all the where-should-I-be-going thinking, while the HAL code follows these commands.

The next thing to notice about the HAL logic is the 8-way MUX in the “Position Command Section.” This MUX takes the current motion source (as determined by the python code state controller) as input, and selects the correct Z position command based on the motion source.

There are 8 motion sources:

Moving out of the “Position Command Section,” most of the other blocks are related to determining the actual position to use for one of these 8 motion sources. For example, if the motion source is “Probe Down” then the “Probe position” block figures out where to go. In this case, if the float switch is not hit, then the commanded position is the minimum Z limit. When the float switch triggers, the position then locks on the last position before the float switch was hit.

The “Running Torch Height Controller” block is more complicated, but it is essentially doing the same thing. It is either outputting the current position, or commanding the Z axis UP if the Move UP pin is set, or commanding it down if the Move Down pin is set. It is also disabling movement if the Corner Height Lock bit becomes set because the X, Y velocity has decreased.

The final block of note is the Limit3Step block. This is a modified version of the limit3 block that comes with the default linuxcnc distribution. It limits the acceleration and velocity of the output movement commanded position to within an acceptable range. The default limit3 that ships with linuxcnc was having problems handling inputs that had large step changes (which sometimes caused incorrect movements), so I rewrote it.

3.2.4. THC Python State Machine

The state machine is implemented in THCStateController.py and tied into hal in custom_postgui.hal both of which you will find in the files below.

The python codes main job is to figure out where the Z axis should be moving, and output MotionSourceSelX bits (3 bits, for a number from 0 to 7, corresponding to the 8 motion sources). The python code is also responsible for setting the TorchOnCmd bit, which tells the HAL code to fire the torch.

The code is implemented as an infinite while loop. Within the loop, the current state is checked. Based on the state, the output bits are set. Then, the input status bits are checked and, if appropriate, the state is changed to a new state for the next iteration of the while loop. At the end of each while loop iteration, the code sleeps for a short duration to save CPU cycles.

3.2.5. Limit3step.comp Realtime Module

This module has the same specification as the limit3 realtime module that comes with the default linuxcnc distribution. It simply fixes some problems the limit3 module had with handling large changes in input values.

In order to install this module
1) Install the linuxcnc-dev version (either from buildbot or source) to get the "comp" executable which installs realtime components. We are currently using the 2.5 branch pre-release from the buildbot [29].

If you type "man comp" on the system and get:

	NAME
       		comp - Build, compile and install Linuxcnc HAL components
Then you have the right thing. Otherwise, install -dev

2) Put the file needed to build and install the component in a directory. The component is included below in the Files section: limit3step.comp

3) In a terminal window enter: sudo comp --install limit3step.comp

3.2.6. Custom M Codes for THC

These files must be located in the default nc-file directory (~/linuxcnc/nc_files, as set in the main .ini file)

3.3. Homing Controller

Homing in linuxcnc is a built-in process… unless you want to do things a little differently. We home Z axis using a switch, but the X and Y are a little unusual.

3.3.1. Homing Design Goals

We didn’t want to wire limit switches to the X and Y axes. Also, we wanted to use the encoder index pulse as the home signal, as this is guaranteed to be as accurate as possible. This method eliminates the possibility of switch failure, reduces wiring, and has maximum possible accuracy (since it’s as accurate as the encoders themselves, the system can’t do better than that).

In general, in order to home to a hard stop, you need some way of limiting the torque of the motors, so they don’t push will all their force on the stop and let out smoke. The Granite Devices servo drives have a built-in homing controller that automatically perform steps 1 and 2 in the list below when a digital input bit is set.

The homing sequence is:

  1. Home to a hard-stop (literally, we screwed heavy-duty metal and rubber door stops to the end of the X and Y travels).
  2. Have the homing controller back off the hard stops until the index pulse on the encoder is found.
  3. For the Y axis, one side of the axis is moved a specified offset (set in the .ini file) to eliminate racking. This offset is needed because the location of the encoder index pulse is not typically in the right position for both Y axis motors to be square (unless it happens by luck).

So, from linuxcncs point of view, it just sets a GPIO output bit, waits for some GPIO input bits to go high (indicating the Granite drives have finished homing), and then proceeds with step 3 (adding an offset to the one Y axis motor).

The Z axis is homed normally, using a limit switch.

3.3.2. Homing Theory of Operation

Like with the torch height controller, a python user module is used to monitor the state of homing, and give signals that the HAL uses to perform the homing sequence.

The python file [ A2GantryController.py] contains the user module that monitors and controls the homing sequence.

Like the torch height controller, the code is an infinite while loop, which repeatedly checks the current state, sets output bits based on the state, and then checks if the state needs to be updated to a new state, then starts over.

3.3.3. Homing HAL Control

The HAL portion of the homing controller is simple – pins are simply routed directly to the python module’s inputs and outputs to give it access to the various GPIOs and system state settings. See custom.hal [upload:custom.hal] and custom_postgui.hal [upload:custom_postgui.hal] for most of the connections.

3.3.4. Homing Python State Machine

The Internal states are:

The system is normally powered on, taken out of e-stop using the normal hardware and software (Axis) controls, and then the “Home” button is pressed on the Glade GUI. This triggers the python module to enter the “Homing Ex” state.

The homing sequence begins:

  1. Enable the Granite drives. Normally, in machine-off state, the Granite drives are disabled. We force them to be enabled so they can do the homing sequence.
  2. Turn the Axis mode to “machine off.” Since the Granite drives will be moving the X and Y axes independent of linuxcnc control, we put linuxcnc into the “off” state so it will not generate a following error fault or try to send corrective step/direction pulses to the drives.
  3. Toggle the GPIO that tells the Granite drives to do the homing sequence (hardware controlled).
  4. Wait for the GPIO signal from the Granite drives that the homing sequence is complete
  5. Reset the X and Y axes encoders –this eliminates the following error from the drives moving without linuxcnc control.
  6. Turn the linuxcnc state to “machine on”
  7. Do the normal linuxcnc homing sequence, including the Z axis homing to limit switch.
  8. return to the “ready on” state

In this system, the drives have power as soon as e-stop is cleared, but the servo drives are forced into “disable” mode. The normal usage of the “Home” button is to press it even before the machine-on button is pressed (but after leaving e-stop, and with power to the drives). The Homing sequence handles all the homing, including forcing the granite drives to not be disabled, and then turns on the machine (at least, as far as linuxcnc software is concerned) automatically.

upload:IMG_3650.jpeg

4. Files

The config files that drive this (which live in ~/linuxcnc/config/a2gantry/) are:

Also needed for THC and Glade button operation are these files (which live in ~/linuxcnc/nc_files):

In addition you need the custom hal module:

These files are for the PYVCP version of the configuration and needed only if you want to use PYVCP rather than Glade:

This file is the zip archive of the Eagle files needed to produce the custom board which provides differential to single ended conversion and signal isolation:

These files are the firmware that is loaded into the Mesa 7i43 (400k version) fpga card:

5. Videos

A few other videos: [Sparks1], [Sparks2], and [Sparks3]

This page was originally written by TomE and PeterJ on 021012. Edited 062612.

Last edits: Updated files: gantry-panel.ui, custom_postgui.hal, THCStateController.py, and A2THC.hal to add Pierce Time Delay and also fixed bug where Pierce Height was not taking into account the float switch travel. (date:021712) Added system wiring diagram and Mesa firmware files. Added EncoderDtoSEV4.zip to files section. Added info on switches. (date:022112) Updated files to include changes made to control panel which include Arc Loss Delay and MDI window. (date:040212) Updated wiring diagram files to include changes made to ESTOP circuit. (date:062612)


LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions | View current revision
Edited May 9, 2015 8:56 pm by Tome (diff)
Search:
Published under a Creative Commons License