Advanced Search

Hi,
Sorry, just saw your reply. I'm happy to send it just for whatever it costs to ship. If you could get me an address I'll try to figure out a shipping cost.

I’ve been following this thread with interest all along. What surprises me, though, is that I haven’t experienced the jitter issues described so far. I’d be interested to know what hardware you’re using. Perhaps there’s a correlations 

First, show us what you’ve got and where you’re at. Your XML and ini files. If you’ve got any errors, include the dmesg output as well.I’m sure we can help you

Don't know where to start.
Here is an example of setup of a cia402 drive, your servo drive is a cia402 drive.
This is a starting point. Change vid and pid and this might work right away.

github.com/dbraun1981/hal-cia402/tree/main/example

You could first check if your parallel port is properly installed.

The commandshould list a device with LPC Controller or LPT Controller or similar.

I am converting my machine to Linuxcnc and currently use Gibbscam. Does anyone else here use Gibbscam and is there a current post processer for Gibbscam for use with Linuxcnc.

Thank You,
Steve

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)