Advanced Search

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.

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/
 

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

Servus,
Ich hab folgendes Problem: ich benötige wohl ein HAL Modul das nicht installiert ist, einen Konverter "conv_u32_s32 ".  Nun sollte ich dazu das uspace Datei Paket installieren, gegeben wurde mir folgender Befehl:
sudo dpkg -i linuxcnc-uspace_2.9.8 deb
sudo apt-get install -f
Damit erhalte ich diese Rückmeldung:
cnc@debian:~$ sudo dpkg -i linuxcnc-uspace_2.9.8.deb
sudo apt-get install -f
[sudo] Passwort für cnc:
dpkg: Fehler: Auf das Archiv »linuxcnc-uspace_2.9.8.deb« kann nicht zugegriffen werden: Datei oder Verzeichnis nicht gefunden
N: Datei »kcjengr.list3« in Verzeichnis »/etc/apt/sources.list.d/« wird ignoriert, da sie eine ungültige Dateinamen-Erweiterung hat.
E: Typ »’deb« in Zeile 1 der Quellliste /etc/apt/sources.list.d/kcjengr.list ist unbekannt.
E: Die Liste der Quellen konnte nicht gelesen werden.
cnc@debian:~$

Das Paket wird also nicht geladen und installiert
In der Datei kcjengr.list3 steht auch tatsächlich der Eintrag ’deb [arch=amd64] repository.qtpyvcp.com/apt stable main’  kann ich ja nicht einfach ändern...

Nun die eigentliche Frage- wie ist der richtige Befehl um das uspace Paket nachinstallieren zu können.
System: Debian 12, Linuxcnc 2.9

Ich bin leider kein Computer Genie...

Danke
Sigi

 

endian wrote:

 
I saw at my own eyes synchronization of 120 seconds with beckhoff SoE AX5125 driver with older firmware ... its not odd behaviour 

beckhoff IPCs have sometime very similar behaviour with their own hardware from my close experiences...

The more i read here about ethercat = the less i like it.
Thank you for pointing out the quirks, not only the good stuff.
 

ethercat is the best from the best ... everything has some + / - ... finally synchronization issues and these childhood illnesses are not fault of the ethercat protocol itselft which is very robust... Its issue of HW at side of master, slave or connection itself ... 

If we use native bckhff driver at native stuff around these issues are suppressed limiting to zero ...