|
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. |
|
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. |
|
Updated wiring diagram files to include changes made to ESTOP circuit. (date:062612) |
|
Updated wiring diagram files to include changes made to ESTOP circuit. (date:062612) |
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:
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.
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
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
We used the Cast CNC parts which we purchased, and the Joe's CNC plans with the rack-and-pinion configuration.
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.
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]
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]
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.
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 ;-)
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.
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.
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.
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.
The Granite devices documentation is pretty good, so I won’t repeat the process here. However, there are a few tips:
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.
The parts are:
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.
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.
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.
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.
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]
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.
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.
Below is an image of our Axis pane with the custom Gladevcp panel on the side:
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.
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:
If Side Entry is ENABLED, then the sequence is a little different.
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.
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.
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.
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:
![[Home]](/chips.gif)
![[25]](http://wiki.linuxcnc.org/uploads/IMG_3219.jpeg){kind=link}
![[26]](http://wiki.linuxcnc.org/uploads/IMG_3690.jpeg){kind=link}
![[27]](http://wiki.linuxcnc.org/uploads/IMG_3689.jpeg){kind=link}
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
These files must be located in the default nc-file directory (~/linuxcnc/nc_files, as set in the main .ini file)
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:
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.
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.
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.
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:
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.
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:
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)