xyzx configuration trouble

I'm sorry to ask what seems to be an often asked question once again but I am having trouble configuring a xyzx machine (specifically the CRP 4848). I cannot seem to control the secondary x axis at the same time as the primary. I am sure that this is a simple problem that I just can't see the answer to but I am really struggling with this. I don't, currently, want to home each axis independently, I just want to slave the axes. Here are my hal file and config files. I have tried changing things around in the AXIS3 definition in the hal file but I seem to only get errors. Any help would be greatly appreciated.

Thanks,
Nathan

###################### HAL ######################

# Generated by stepconf at Sun Aug 10 01:03:29 2014
# If you make changes to this file, they will be
# overwritten when you run stepconf again
loadrt trivkins
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
loadrt probe_parport
loadrt hal_parport cfg="0xbc00 out "
setp parport.0.reset-time 1000
loadrt stepgen step_type=0,0,0,0
loadrt charge_pump
net estop-out charge-pump.enable iocontrol.0.user-enable-out
net charge-pump <= charge-pump.out

addf parport.0.read base-thread
addf stepgen.make-pulses base-thread
addf charge-pump base-thread
addf parport.0.write base-thread
addf parport.0.reset base-thread

addf stepgen.capture-position servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf stepgen.update-freq servo-thread
net spindle-cmd <= motion.spindle-speed-out
net spindle-at-speed => motion.spindle-at-speed
net spindle-cw <= motion.spindle-forward

net xstep => parport.0.pin-02-out
setp parport.0.pin-02-out-reset 1
net xdir => parport.0.pin-03-out
net ystep => parport.0.pin-04-out
setp parport.0.pin-04-out-reset 1
setp parport.0.pin-05-out-invert 1
net ydir => parport.0.pin-05-out
net zstep => parport.0.pin-06-out
setp parport.0.pin-06-out-reset 1
net zdir => parport.0.pin-07-out
net xstep => parport.0.pin-08-out
setp parport.0.pin-08-out-reset 1
setp parport.0.pin-09-out-invert 1
net xdir => parport.0.pin-09-out
net spindle-cw => parport.0.pin-14-out
net charge-pump => parport.0.pin-16-out




setp stepgen.0.position-scale [AXIS_0]SCALE
setp stepgen.0.steplen 1
setp stepgen.0.stepspace 0
setp stepgen.0.dirhold 15200
setp stepgen.0.dirsetup 15200
setp stepgen.0.maxaccel [AXIS_0]STEPGEN_MAXACCEL
net xpos-cmd axis.0.motor-pos-cmd => stepgen.0.position-cmd
net xpos-fb stepgen.0.position-fb => axis.0.motor-pos-fb
net xstep <= stepgen.0.step
net xdir <= stepgen.0.dir
net xenable axis.0.amp-enable-out => stepgen.0.enable

setp stepgen.1.position-scale [AXIS_1]SCALE
setp stepgen.1.steplen 1
setp stepgen.1.stepspace 0
setp stepgen.1.dirhold 15200
setp stepgen.1.dirsetup 15200
setp stepgen.1.maxaccel [AXIS_1]STEPGEN_MAXACCEL
net ypos-cmd axis.1.motor-pos-cmd => stepgen.1.position-cmd
net ypos-fb stepgen.1.position-fb => axis.1.motor-pos-fb
net ystep <= stepgen.1.step
net ydir <= stepgen.1.dir
net yenable axis.1.amp-enable-out => stepgen.1.enable

setp stepgen.2.position-scale [AXIS_2]SCALE
setp stepgen.2.steplen 1
setp stepgen.2.stepspace 0
setp stepgen.2.dirhold 15200
setp stepgen.2.dirsetup 15200
setp stepgen.2.maxaccel [AXIS_2]STEPGEN_MAXACCEL
net zpos-cmd axis.2.motor-pos-cmd => stepgen.2.position-cmd
net zpos-fb stepgen.2.position-fb => axis.2.motor-pos-fb
net zstep <= stepgen.2.step
net zdir <= stepgen.2.dir
net zenable axis.2.amp-enable-out => stepgen.2.enable

setp stepgen.3.position-scale [AXIS_3]SCALE
setp stepgen.3.steplen 1
setp stepgen.3.stepspace 0
setp stepgen.3.dirhold 15200
setp stepgen.3.dirsetup 15200
setp stepgen.3.maxaccel [AXIS_3]STEPGEN_MAXACCEL
net apos-cmd axis.3.motor-pos-cmd => stepgen.3.position-cmd
net apos-fb stepgen.3.position-fb => axis.3.motor-pos-fb
net astep <= stepgen.3.step
net adir <= stepgen.3.dir
net aenable axis.3.amp-enable-out => stepgen.3.enable

net estop-out <= iocontrol.0.user-enable-out
net estop-out => iocontrol.0.emc-enable-in

loadusr -W hal_manualtoolchange
net tool-change iocontrol.0.tool-change => hal_manualtoolchange.change
net tool-changed iocontrol.0.tool-changed <= hal_manualtoolchange.changed
net tool-number iocontrol.0.tool-prep-number => hal_manualtoolchange.number
net tool-prepare-loopback iocontrol.0.tool-prepare => iocontrol.0.tool-prepared



#################### CONFIG ########################

# Generated by stepconf at Sun Aug 10 01:03:29 2014
# If you make changes to this file, they will be
# overwritten when you run stepconf again

[EMC]
MACHINE = bender-rodriguez
DEBUG = 0

[DISPLAY]
DISPLAY = axis
EDITOR = gedit
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
MAX_FEED_OVERRIDE = 1.2
INTRO_GRAPHIC = linuxcnc.gif
INTRO_TIME = 5
PROGRAM_PREFIX = /home/nathan/linuxcnc/nc_files
INCREMENTS = .1in .05in .01in .005in .001in .0005in .0001in

[FILTER]
PROGRAM_EXTENSION = .png,.gif,.jpg Greyscale Depth Image
PROGRAM_EXTENSION = .py Python Script
png = image-to-gcode
gif = image-to-gcode
jpg = image-to-gcode
py = python

[TASK]
TASK = milltask
CYCLE_TIME = 0.010

[RS274NGC]
PARAMETER_FILE = linuxcnc.var

[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
COMM_WAIT = 0.010
BASE_PERIOD = 100000
SERVO_PERIOD = 1000000

[HAL]
HALFILE = bender-rodriguez.hal
HALFILE = custom.hal
POSTGUI_HALFILE = custom_postgui.hal

[TRAJ]
AXES = 4
COORDINATES = X Y Z A
MAX_ANGULAR_VELOCITY = 1.00
DEFAULT_ANGULAR_VELOCITY = 0.10
LINEAR_UNITS = inch
ANGULAR_UNITS = degree
CYCLE_TIME = 0.010
DEFAULT_VELOCITY = 0.10
MAX_LINEAR_VELOCITY = 1.00

[EMCIO]
EMCIO = io
CYCLE_TIME = 0.100
TOOL_TABLE = tool.tbl

[AXIS_0]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 1.0
MAX_ACCELERATION = 30.0
STEPGEN_MAXACCEL = 37.5
SCALE = 1909.86093
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = -0.01
MAX_LIMIT = 4.0
HOME_OFFSET = 0.0

[AXIS_1]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 1.0
MAX_ACCELERATION = 30.0
STEPGEN_MAXACCEL = 37.5
SCALE = 1909.86093
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = -0.01
MAX_LIMIT = 4.0
HOME_OFFSET = 0.0

[AXIS_2]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 1.0
MAX_ACCELERATION = 30.0
STEPGEN_MAXACCEL = 37.5
SCALE = 4000.0
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = -4.0
MAX_LIMIT = 0.01
HOME_OFFSET = 0.0

[AXIS_3]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 1.0
MAX_ACCELERATION = 30.0
STEPGEN_MAXACCEL = 37.5
SCALE = 1909.86093
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = -0.01
MAX_LIMIT = 4.0
HOME_OFFSET = 0.0

Hi

This thread gives the basic links
www.linuxcnc.org/index.php/english/forum...x-motors-in-stepconf

It is often easier just to slave the second X axis and not tell Linuxcnc anything about it, then you just use a XYZ config as Rick mentions in the thread.

The alternative is gantrykins

regards

Okay, that makes sense. I had actually seen that thread before but I wasn't sure how to implement it. From what you said, I should remove the following from my .hal:

#### EDITS TO .HAL ###

### EDITS TO CONFIG ###

#### END EDITS ####

Which I had tried before. What else do I need to add to make the second x axis move at the same time? Using this method I found that the second x axis continued to provide holding torque and wouldn't move at all. What do I need to add to the .hal to achieve this?

Thanks for your help!

Hi

From what you said, I should remove the following from my .hal:

There are a few more things beside, I should just go back into the stepconf config and choose XYZ config on the first page and all the unnecessary stuff will be removed

What else do I need to add to make the second x axis move at the same time? Using this method I found that the second x axis continued to provide holding torque and wouldn't move at all. What do I need to add to the .hal to achieve this?

As Rick said in his post, you can define a second XStep and XDir in stepconf.
That will probably cause problems however, because you will be trying to connect 2 OUT pins to the same signal.

All you need to do is wire the STEP and DIR wires from both X stepper drivers into the same pin on the BOB.
That should get both moving at the same time, receiving the same pulses.
So long as you don't have long cable runs, it should work.
If that is OK, it is by far the simplest solution.

regards

I'm sure the experts who have already replied to your post are more correct and more knowledgeable. I'm a noob to LinuxCNC myself.

But I built my own gantry router too and it works fine except I call it an XXYZ machine as opposed to an XYZX machine. Using stepconf I assume you are using stepping motors. I have not done anything with Hal files (yet). I wanted to run as an XYZ as simple as possible (at least to start with until maybe someday I'll learn more about it). I read the replies and the other thread they pointed to. You may 'get it' but some other readers may not. I'm not using gantrykins or any other nnn_kins.

If you want to simply run as an XYZ machine with 2 X-axes joints running a single "X" machining axis, like me, then here's what worked for me. I have a plain 17 I/O parallel port card with 5_Inputs & 12_Outputs. I use all 5 inputs for: 10, 11, 12 = X,Y,Z home switches; 13 = all_combined_limit switches; 15 = EStop. And my 12 outputs are: X1_pls, X1_dir, X2_pls, X2_dir, Y_pls, Y_dir, Z_pls, Z_dir, A_pls, A_dir, Ena, Spn. Okay I have added a 4th "A-axis" too, but that doesn't effect anything else. My Ena output feeds a relay on P17 and SPN also feeds a relay on P1 (my spindle is a Bosch router and I don't PWM its speed, just on/off)(I use the EVS speed regulator on the router to control rpm). The order of the inputs makes no difference on those 5 pins so long as you tell stepconf which signals are on which of those 5 pins. Also, on the outputs you tell stepconf which signals are on which pins. If there is any pin not used (for example you may not have A_pls or A_dir) then make sure those pins are 'unused' in stepconf.

Then get rid of any non-stock HAL files, customs or whatever. I didn't need any of them. I used my machine as a pure XXYZ gantry router for hundreds of gcodes files over 3 months with no troubles at all and I haven't touched a HAL file. I like simple. The two X_axes run synchronized. There is only 1 caveat to this scheme: Do NOT run the TEST this axis within stepconf on your X axis !!! That program (stepconf) will only "test" one axis (what they call a "joint")! That could cause racking and damage or bend something. Just ASSUME it will work, use sensible parameters for acceleration and max speed; complete stepconf; then run the "AXIS" program and try jogging to test your XX axes. AXIS (on my system) runs both my XX axes simultaneously. With the motor power off I can manually 'square up' my ball screws so that my gantry is as 90_degrees to it's travel (ball_ways) as I can measure. Then I'm careful not to turn a single X_ballscrew thereafter (not a problem because mine are hidden underneath) and it stays at 90 day after day.

---

As an aside:
It seems to be common (at least if you look at driver manufacturers wiring diagrams and some of the user stuff posted online) that people "daisy-chain" the "Amplifier Enable" signals on their drivers (the box wired to your steppers). These are also just called "Enable" or "ENA" or any such pseudonym. And most/many of those are optoisolated inputs inside of those drivers. If you do NOT drive the Enable signal with your parport; if you wire it "always enabled" by tying it to the appropriate power this 'aside' does not apply. But if you do drive it from your parport card this does apply.

I have 5 drivers in my router, XXYZA. I'm all for optocouplers for those 5 inputs on the parport card because they do provide isolation to protect your computer. But since the drivers almost always have optocouplers on their inputs, optocouplers on the outputs of a parport card seem redundant. They would only add some delay to the signals and not really do anything too horrible, but it could be argued that those optocouplers (on the parport card) are not needed. I'd say their only merit is to protect the computer against faults in the wiring on the I/O pins/screw_terminals side of the card. If your wiring is good that is highly unlikely. And besides, if you use cheap parport cards then blowing that card MAY also limit or obviate damage to you computer at the cost of that card. Nevertheless, many parport cards are fully optocoupled, even the outputs.

Most of the optocoupler input drivers that I've seen use a pullup resistor to their positive logic supply. That supply is usually +5v (but sometimes higher***). That pullup resistor is sized so that the optocoupler input (usually an LED) is in a known state internally to the driver when the input is disconnected or connected to a VERY weak external source or sink. For a 5v logic supply that internal pullup is usually between 200 and 900 ohms. That means that each opto input to a driver (under these assumed conditions) will flow between 5.5 ma and 25 ma. If you daisy-chain 5 amplifiers multiply by 5 for 27.5ma to 125ma.
You would not likely daisy-chain step or directions (pls or pul or ck or clk or dir or cw or ccw) inputs but daisy-chaining the "Enable" signal seems to be commonly shown in wiring. When your system is running normally, your parport card is trying to provide a STRONG external signal to control your driver, either sourcing current when driving active_high towards +5v or sinking current when driving active_low towards zero volts.

The "Enable" signal (and most others) are usually labeled something+ and something- (e.g. Ena+, Ena-, Dir+, Dir-). It is usual to tie all of the same polarity together and to the correct power level, then drive the remaining signal from the parport card(s). In "the old days" [I've been an electrical engineer for a few decades, retired now], we usually relied on the nature of bipolar logic integrated circuit chips' non-symetrical output driving capabilities to drive "active low" outputs with more current sinking than "active high" outputs with weaker current sourcing capabilities. In other words, bipolar logic chips, e.g. a 74XXyyy, might sink 20, 30 even 50ma when its output drove low. But that same chip would only source 1.6, 4, perhaps 8 ma when it drove its output high. But since the 1990's we have many CMOS families of IC chips. Without getting into any physics, rest assured that CMOS outputs tend to be very symetrical, i.e. they can sink or source about the same amount of current. That is, when outputting a low (near zero) they can "sink" NN ma. and when they output a high they can "source" about that same NN ma. Different CMOS logic has different NN. Some CMOS logic IC's have NN=8ma and others have NN=50ma. The only way to know NN is to from the manufactures data sheet.

Okay, back to the point. Many parport cards now use CMOS logic with something like 74HCyyy. The "Absolute Maximum Rating" for any single output might be as high as 40 or 50 ma. But the "Normal" rating is usually closer to about 8ma. And you need to watch the overall power dissipation limit of the chip too, perhaps it is 200mw (milliwatts). That means that not all 8 (assuming its an octal IC) outputs can be continuously driven to their current limits 100% of the time. That would be unusual but not impossible (hmmm, I don't think) in LinuxCNC. So... the common (especially cheap Chinese) parport cards "get away with it" and run okay.

For those cards that drive their parport output pins/screw_terminals directly from a logic IC, the last paragraph is the end of that story. If the parport card has optocouplers on its outputs then that logic IC only drives the LED inputs to the optocouplers. The optocoupler's outputs then drive the output pins. Optocouplers are NOT standard! There are a jillion differences. Some manufacturers make a zillion different devices. Even more-so than with IC's, the only way to know is to read the manufactures data sheet. Get out your magnifying glass and read the writing on the opto chip and Google it for a data sheet. Simple optos (not darlington or FET output types) such as the EL817 can drive from under 10ma to over 50ma depending on how hard its input LED is driven (forward transfer characteristic [If]) and the robustness of it's output transistor (internal to the opto IC). Some optos can drive 100, 200 even 1000ma, but don't assume that, those are special. Also beware that usually the more current you flow through an opto's output (either direction, source or sink) the more delay there is through it and the lower its limiting frequency of operation. Nevertheless, there is a finite limit on how much current YOUR parport card opto (or directly driven from an IC) output can provide to your drivers.

Clearly, if you have a stack of drivers with all of their Enable signals daisy-chained together then a simple parport output cannot drive them, active low or otherwise. The likely case is that you'll blow the IC or opto. You cannot haul 2 tons of fertilizer on a 1 ton truck (not for very long without damage). So, what do you do?

You have several choices of varying levels of "okayness". 1) wire those Enables "on" all the time and deal with EStop some other way (this is not okay by me, but for a very simple and well monitored machine it could be viable), 2) get a parport card that has enough guts to drive all those daisy-chained (paralleled) Enable signals (this would be sorta okay by me but where the heck are you going to get such a card and will it be fast enough?), 3) don't daisy-chain all the enables , but drive each one with it's own output signal from the parport card. You may need more parports to have enough pins for all those driver inputs (this is fine by me, but adds hardware to your system, and may be more expensive depending on which hardware you use and may go beyond a simple stepconf setup). Or 4) many cheap parport cards have 1 or 2 or more mechanical relays on them for such things as spindle ON/OFF, coolant pump ON/OFF, etc.so you can use a relay to drive those daisy-chained Enable signals because most relays have at least 5 amps, typically 10a of current limits. This allows use of a simple stepconf setup. Warning: never use a relay output for any step or direction output or anything that needs to be fast since a relay can take many milliseconds to actuate. Since the Enable signal stays in one state for long periods and drivers are generally only disabled when Estop happened or you click them off in AXIS or by codes or hitting limits, the few milliseconds that the relay needs to actuate is acceptable.

The point is: be aware of the limitations and capabilities of your parport card. They can work well if not misunderstood or pushed too hard.

---

*** if the driver's opto inputs use a pullup resistor to some power supply higher than +5 (for example to +12 or +48 or such), then you are limited in how you feed those inputs. Most commonly you would drive them with open-collector/drain outputs from your system and those would be active_low signals. There may also be current limiting resistors and possibly diodes involved between your system and the driver's inputs. But that is beyond the scope here.

Okay, it seems that the problem that I was running into is that stepconfig did not drive both motors at the same time even though I had configured it correctly just like skyrider said. When I actually ran LinuxCNC everything worked just fine. I didn't know that was a limitation of stepconfig. Thank you for your help ArcEye and skyrider!

skyrider: Thank you for the detailed post! As I continue working with my CNC I will be mindful of what you have mentioned. I'm quite excited to learn more about all of this!

Thank you again!

Nathan