Advanced Search

I have removed and disassembled the Fanuc encoders, retaining the central shaft that mounts to the tapered encoder mount on the motor's shaft. I turned down a section of this shaft to 15mm which is the bore size of the clamping collar of the new encoders. The encoders are hollow all the way through so I can still tighten the screw that mounts the encoder shaft to the motor. 

 

Turns out that the new encoder mount flanges happen to line up with some holes on the old Fanuc encoder bearing housing, so I repurposed those to serve as the encoder mounts. All mounted on the machine now, everything fits under the original red caps, with one tight fit under the smaller turret motor.

 

Unfortunately I have been unsuccessful in configuring the drives (AB Ultra3000) to engage in self-sensing commutation. I have tried everything I can think of including: 

-swapping motor phases (every possible combination) to ensure motor direction phase relationship and encoder direction match
-adjusting self-sensing current
-swapping A / B encoder phases to see if they were backwards with relation to the motor while also trying the various motor phase connections in this A / B swapped configuration
-double checking and experimenting with Pulses Per Revolution and the corresponding Lines Per Revolution data at the drive. Encoder is listed as PPR while drive data input is LPR as it counts the rising and falling edges therefore PPR*4=LPR

Now I'm wondering if my motor configuration settings have something to do with it (within the Ultraware configurator, some numbers such as Inductance had to be guessed as I do not know how to measure that and havent found info on that yet), but it seems like an unlikely cause. 

No matter what I do I get E39 (self-sensing startup error) a short period of self-sensing testing upon enabling the drive. 

The motor in question is free to spin for the self-sensing routine. 

Which brings me to another problem: the X-axis is HEAVILY loaded as it is a slant bed without counter spring. Currently a brake is on, so if I were to figure out this self-sensing and make it work, or even generate commutation pulses from the incremental encoder data, any startup sensing would have to take place with the X-Axis brake released and have the motor engaged in holding torque so that the whole thing doesnt come crashing down. 

I think I should have bought encoders with commutation outputs   I assumed that the self-sensing commutation would work as perscribed but for some reason I cant get it to work. 

Now I'm starting to wonder if I should run the the buffered encoder outs (that the Ultra3000 provides) into LinuxCNC via the extra Mesa cards I got and use BLDC to generate commutation pulses, send them out to the drives. The only issue is the startup sensing: how would BLDC command the Step/Dir drives to move in order to find the index pulse if the step/dir drives need the commutation signals to run in the first place? 

If anyone has any ideas, even half-baked, I'd love to hear them. 

The Conquest continues. 



 

When i start linuxcnc with just setp gladevcp.table1" in the postgui i receive this error message



Any ideas how to fix it?

I found this  github.com/LinuxCNC/linuxcnc/blob/2.9/configs/sim/hitcounter.py
I created a file hitcounter.py in /home/cnc/linuxcnc/configs/Fräse/ with the contend from the link

A little different error

You don't need a handler for what you want.

Here is an example that creates a led connected to 'halui.machine.is-on' and a button connected to 'halui.machine.on'  

 

 

If your Glade UI element is of type "Hal button" then the HAL pin will be created automatically and no handler file is needed.

(This is stated with 93% confidence, I don't have easy access to a LinuxCNC machine at the moment to test this assertion)