Advanced Search

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 now have a 1PPR spindle index signal connected and working (using a Hall sensor). 
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.

Next up figure out what I need to do in HAL to use the index pulse, so I stop getting  "Chosen spindle(0) not turning in G76"

Any 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.

grandixximo wrote:

@ruediger123
For your exact parameters: 1ms cycle, 50 m/s³ jerk, 5 m/s² acceleration, P0.01 on a 45° corner, the only cornering speed that mathematically fits within the jerk limit on a 1ms grid is zero. 

I don't think it's actually zero, but it's pretty close. 
Centripetal acceleration is v^2/r and centripetal jerk is v^3/r^2.

My back of the envelope math says the maximum velocity at a 45 degree junction with .01mm deviation would be .0056 m/s or .336 m/min to keep centripetal acceleration at 5 m/s^2. That would produce a centripetal jerk of 4568 m/s^3, which is an order of magnitude over the limit. 

To keep the jerk within the limit, the maximum velocity at the junction would be .001243 m/s or .0745 m/min. At that velocity it would take 8ish servo cycles to traverse the radius. 

But, for all intents and purposes, it's basically a full stop. 

Wouldn't it be pretty simple to find the maximum junction velocity to keep both jerk and acceleration within the limits of each axis? We have everything we need to make that calculation. Interestingly, since corner tolerance, max accel, and max jerk are constants, this velocity limit is only dependent on the angle. That would make it pretty easy to use a look up table generated by the tolerance setting. 

onehossshay.wordpress.com/2011/09/24/imp...cornering_algorithm/