Advanced Search

Searching for guidance gave me only a sensation that the parallel port might have the wrong address. Supergrok saved the day. It helped me find that the built-in parallel poets are at 0x3F8. This rang a bell from when I wrote a terminate-and-stay-resident PC-DOS (stop laughing) program that intercepted data going to the parallel port and converted Epson control codes to Postscript. It was wonderfully elegant in how it allowed programs with no Postscript support to use Apple LaserWriters

Changing one of the LinuxCNC setup files to talk to the parallel printer at 0xC010 and problem is solved.

Jerk-Aware Full-Stop Fallback (The "G64.1" Proposal) - is possible solution but what if ...

Path Tolerance Splining (Point Compression): Instead of treating the corner as a "sharp" mathematical point, use the G64 P tolerance to convert the corner into a tiny, high-order polynomial curve (spline). This gives the "train" a physical radius to turn on, spreading the Jerk over several segments even at high speed?.... it should plan for the re-parameterized spline. By doing this, the "junction" disappears, and the Jerk limit is satisfied over a distance (the spline radius) rather than a single 1ms step. - but comp-power consuption will be high

or look-ahead Acceleration Pre-Smoothing...Use the look-ahead buffer to start the direction change "rotation" slightly before the actual vertex. By "bleeding" the X-axis velocity into the Y-axis earlier, you reduce the magnitude of the step-change at the corner. "Bell-shaped acceleration" or "Jerk-limited FIR filtering." - but not actual timing 

or second much faster thread which will handle just calculation to fine result .. as Taylor Series expansion to "fill in the gaps" between those 1ms updates: P(t) = P_0 + V_0 \Delta t + \frac{1}{2} A_0 \Delta t^2 ... This should ensure that the drive receives a perfectly smooth 4kHz or 8kHz stream, effectively making the Jerk "infinite" at the digital level but "finite" and smooth at the physical level ?

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