Geckodrive G540 won't come out of fault. Charge Pump issue?
20 Sep 2017 07:15 #99152
by Evan
Geckodrive G540 won't come out of fault. Charge Pump issue? was created by Evan
The config below works as long as I have the charge pump switch turned off on the G540. The motors have holding torque & I can jog around no problems. But when I flip the switch back it just sits with the fault light on. But I'd very much like to have it work properly.
I'm new to both LinuxCNC & using the G540. Here's my HAL file:
I was thinking it may be the way I have the estop configured, but I've tried a couple different combinations so far based on what I've seen in other solutions on this forum, including both inverting pin 15 & just unsetting it entirely. The only physical e-stop is connected to the power supply, and doesn't communicate with the G540. The terminal-block pins #10 & #12 on the bottom of the G540 are shorted to have the "input disabled" state kept at 0v.
Now I'm assuming it's an issue with the charge pump signal. I read that the G540 pulls too much current on this pin? Here's a photograph of my oscilloscope probing pin #16 (ground is on pin #25):
So it's putting out the required signal of over >10kHz that the G540 requires, but since this isn't probing in-line, I'm not sure what it's like when the drive is pulling it. Also, I'm not sure why the voltage is shown so high at max=51.2v & min=10v. Seems weird.
Here are my PCI Parallel port details:
One last thing, but when I cut power to the G540, it very briefly will exit the fault state where I'll hear the motors engage & the green light comes on, just before power completely fades. This only happens when the parallel port cable is plugged in!
Anyone have some ideas?
I'm new to both LinuxCNC & using the G540. Here's my HAL file:
# Generated by stepconf 1.1 at Tue Sep 19 22:40:25 2017
# 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 hal_parport cfg="0xcc00 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-rpm <= motion.spindle-speed-out
net spindle-cmd-rpm-abs <= motion.spindle-speed-out-abs
net spindle-cmd-rps <= motion.spindle-speed-out-rps
net spindle-cmd-rps-abs <= motion.spindle-speed-out-rps-abs
net spindle-at-speed => motion.spindle-at-speed
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
setp parport.0.pin-07-out-invert 1
net zdir => parport.0.pin-07-out
net astep => parport.0.pin-08-out
setp parport.0.pin-08-out-reset 1
net adir => parport.0.pin-09-out
net charge-pump => parport.0.pin-16-out
net estop-ext <= parport.0.pin-15-in-not
setp stepgen.0.position-scale [AXIS_0]SCALE
setp stepgen.0.steplen 1
setp stepgen.0.stepspace 0
setp stepgen.0.dirhold 25200
setp stepgen.0.dirsetup 25200
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 25200
setp stepgen.1.dirsetup 25200
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 25200
setp stepgen.2.dirsetup 25200
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 25200
setp stepgen.3.dirsetup 25200
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-ext => 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-preparedI was thinking it may be the way I have the estop configured, but I've tried a couple different combinations so far based on what I've seen in other solutions on this forum, including both inverting pin 15 & just unsetting it entirely. The only physical e-stop is connected to the power supply, and doesn't communicate with the G540. The terminal-block pins #10 & #12 on the bottom of the G540 are shorted to have the "input disabled" state kept at 0v.
Now I'm assuming it's an issue with the charge pump signal. I read that the G540 pulls too much current on this pin? Here's a photograph of my oscilloscope probing pin #16 (ground is on pin #25):
So it's putting out the required signal of over >10kHz that the G540 requires, but since this isn't probing in-line, I'm not sure what it's like when the drive is pulling it. Also, I'm not sure why the voltage is shown so high at max=51.2v & min=10v. Seems weird.
Here are my PCI Parallel port details:
$ lspci -v
01:0a.0 Communication controller: MosChip Semiconductor Technology Ltd. PCI 1 port parallel adapter (rev 01)
Subsystem: LSI Logic / Symbios Logic PCI 1 port parallel adapter
Flags: medium devsel, IRQ 18
I/O ports at cc00 [size=8]
I/O ports at c800 [size=8]
I/O ports at c400 [size=8]
I/O ports at c000 [size=8]
I/O ports at bc00 [size=8]
I/O ports at b800 [size=16]
Kernel driver in use: parport_pc
Kernel modules: parport_pc
$ dmesg | grep parport
[ 10.631746] parport0: PC-style at 0xcc00 (0xc800), irq 18 [PCSPP,TRISTATE,EPP]
[ 10.728182] lp0: using parport0 (interrupt-driven).One last thing, but when I cut power to the G540, it very briefly will exit the fault state where I'll hear the motors engage & the green light comes on, just before power completely fades. This only happens when the parallel port cable is plugged in!
Anyone have some ideas?
Please Log in or Create an account to join the conversation.
Time to create page: 0.113 seconds