Advanced Search

I'm sorry, I forgot the ini file part:

[DISPLAY] section:

[HAL]

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)

Can you help me understand how Glade and Handler work? I've already created the switch and the LED. How do I now connect them so that pin 17 switches on and off? I'm completly stuck.

Note that you can use either a handler or the postgui halfile to make the connections.

That does not work because you have forgotten to give a signal name after the 'net' command.

I entered the command in postgui. This does not start linuxcnc. Do I have the correct command from Halshow for postgui.hal?

Not sure I understand this correctly but halshow does not make any distinction between postgui and regular hal files.
The regular hal files are read before the gui has loaded so if any gui related halpins are used in these files you will get a startup error because those pins are missing. The postgui halfile is read after the GUi and the custom panels have loaded.

I only became a Glade user today... so I don't have any experience yet. Please take a look at the attachments. I have the following questions:
Do I have to enter something in Glade -> Light Button -> Signals -> Handler? Do I enter this handler in postgui?
I entered the command in postgui. This does not start linuxcnc. Do I have the correct command from Halshow for postgui.hal?

You'll need to make the hal connections in the postgui_hal file. Have a look at the millturn sim confi, (uses an xml instead of a glade file but the setup is the same.
github.com/LinuxCNC/linuxcnc/tree/master...xis/vismach/millturn

Hello,
I would like to have a header on my Linuxcnc interface that switches Pin17=hm2_7i76e.0.7i76.0.0.output-00 on and off on my Mesa7i76e. So far, I have created an LED and a button in Glade. This already appears on the Linuxcnc interface, but no control content is stored. How do I proceed? I tried to do some preliminary work on the Glade page, but failed. What do I need to do and where?
Thank you

Erledigt
forum.linuxcnc.org/configuration-tools/5...yl-620a-speedvoltage

I found it at pncconf and unchecked "Require homing before MDI/Running". Now it works.
Thanks a lot!

Try setting the HOME_SEARCH_VEL and HOME_LATCH_VEL to 0

I did it at all Joints like this

[JOINT_0]
NO_FORCE_HOMING = 1

and restarted Linuxcnc but i still get the error not "homed"