Advanced Search

Happy to help, glad you got it sorted!!

Glad you got it sorted out! Enjoy!!

Good catch! Glad you figured it out!

I wanted a more modern version than 2.7.15, mostly because the builrtn browser was so ancient that many websites refused to work with it. 2.9.8 needed a 64-bit processor. Someone gave me a 64-bit desktop. I only needed to put a PCIe parallel port in it. Okay, 2.9.8 installed in a system with gobs of RAM and SSD storage. Everything is connected as it was before but no axes move. When I run latency test, I get max jitter of 30,381 on Servo thread. 60,354 on Base Thread.

I wonder if the parallel port card is defective. How would I test that?

Falls jemand das selbe Problem haben sollte- hier die Lösung:
sudo rm /etc/apt/sources.list.d/kcjengr.list`
sudo rm /etc/apt/sources.list.d/kcjengr.list3`

sudo apt-get update.

In der kcjengr.list und kcjengr.list3 ist wohl irgend ein Fehler drin der das get update blockiert....
Jedenfalls läuft der update Befehl nach entfernen der beiden files ohne Probleme durch und macht was er soll.

PCW wrote:

If you use a hall sensor as index mask, it will likely be wide enough as is,
but the wider (in degrees) , the easier to setup (because the
encoder index must happen within the 1 PPR signal)

If the 1PPR sensor is used for index directly, its width does not
matter.



 

I will use a hall sensor (printing mount now). 
Seems very likely the index pulse will be long enough because there will be 7200 quadrature pulses for every index pulse so every 1/20 of a degree.

Assuming I implement this, I assume I still need to do something else in HAL because just trying to read my 2 line .nc file Linux complains about "Chosen spindle(0) not turning in G76" and so I imagine I need to do something else in HAL to let it know that the index pulse is now available Yes/No

Your help is much appreciated.

If you use a hall sensor as index mask, it will likely be wide enough as is,
but the wider (in degrees) , the easier to setup (because the
encoder index must happen within the 1 PPR signal)

If the 1PPR sensor is used for index directly, its width does not
matter.


 

PCW wrote:

Its possible but awkward and complex

(because you need to hijack the index detection/enable hardware to count the (very short) index pulses)

Easiest thing  would be to add would be to add a 1PPR sensor on the spindle for index

Even better would be to add a 1 PPR sensor with a wide enough pulse that you could use
it as index mask (retaining the high precision of the encoder index)

 

Okay, I'm printing a mount for a 1PPR right at the spindle. Please elaborate on the length required for the masking you describe. I could possibly stretch the short pulse . 

Its possible but awkward and complex

(because you need to hijack the index detection/enable hardware to count the (very short) index pulses)

Easiest thing  would be to add would be to add a 1PPR sensor on the spindle for index

Even better would be to add a 1 PPR sensor with a wide enough pulse that you could use
it as index mask (retaining the high precision of the encoder index)
 

Hi everyone,Following the technical progress we've discussed regarding USB latency and UDEV permissions, I’ve assembled and tested a first batch of 5 complete kits (Main board + I/O expansions).To be clear on the project structure:

• The LinuxCNC HAL Component is fully Open Source on GitHub (GPLv2).
• The Firmware and PCB Schematics are proprietary and come pre-installed/ready-to-use in these hardware kits.

This is a 'ready-to-go' solution for those who want to implement this HMI/MPG interface without building the hardware or coding the firmware side themselves.eBay Link (5 units available): www.ebay.it/itm/277867309687 Looking forward to your feedback on these first units!

PCW wrote:

Is the encoder on the spindle?
if not, the encoder index is not directly usable.

A single proximity/Hall switch on the spindle
could be added if this is the situation

It may be possible to use the spindle position
and some hal logic to simulate index operation
but it would not work well at higher speeds.
 and would forget position between LinuxCNC
runs,

 

 
I'm swapping in my other encoder, that has a 1 pulse per rev signal. The encoder is linked to the spindle with a timing belt, however there is a 3:1 ratio in the timing gears. So I will get 3 pulses per rev, is there a way to divide the Z count by 3 in Hal?

If necessary, I can fit an additional sensor for actual 1PPR

Is the encoder on the spindle?
if not, the encoder index is not directly usable.

A single proximity/Hall switch on the spindle
could be added if this is the situation

It may be possible to use the spindle position
and some hal logic to simulate index operation
but it would not work well at higher speeds.
 and would forget position between LinuxCNC
runs,

 

PCW wrote:

For threading, you need a 1PPR signal (index) from the spindle.

 

Before I swap out my present encoder that only has A & B 600 PPR quadrature signals with another one I have that has the A & B, as well as a 1 PPR signal. Is there any trickery in HAL I can do to use spindle,0,revs, that presently counts up 1 every spindle revolution, noting that spindle,0,revs is a float type value, so it slowly ramps up incrementally each revolution before it flips it's integer type digit.

It sounds like you've got it figured out, but this page was helpful for wiring the Dahlander motor in my Deckel mill:

electronics.stackexchange.com/questions/...ings-troubleshooting

Essentially for low speed, 1U, 1V, 1W are powered while 2U, 2V, 2W are left unconnected. For high speed, 2U, 2V, 2W are powered while 1U, 1V, 1W are shorted together.

Apologies if this was covered earlier in the thread.

Hi,
I did manage to get the first chips today.

Tuning on the Z axis looks actually fine. On X I still have a bit more work to do, but for now it is fine.
I almost managed to kill my spindle motor. I’m still not fully understanding the function of these Dahlander motors. I had 1U, 1V, 1W and 2U, 2V, 2W switched around and thought that these would be equivalent, and still looking at the diagram on Wikipedia for example, it looks to me as if it should be. I assume it has to do with the winding direction of the separate phases.
The motor was slow and heated up significantly. I hope it has not permanently damaged the motor. Now, having it connected correctly, it sounds really nice and quieter than I would expect.

The picture of the part looks a little bit nicer in person, and the feed and speed were just by ear.Now I will try getting the variator to be used as well. Let’s see how that will go.