Debian buster installation with 32-bit RTAI Source

Hello,

After a 10 day period of failing to install Debian wheezy and Ubunto precise on a Dell Inspiron 8200 with RTAI i decided to download Debian buster i386 version. The problems with the other version was they would not boot with the Local APIC (lapic) enabled and lLinuxCNC would also hang. Debian buster cleared up all those issues. What is left is a fairly stable system running the preempt kernel 4.19.0-12-rt-686-pae without LinuxCNC running. LinuxCNC does start and accepts a machine selection of Sherline 4 axis mm Mill. The window for Latency Test takes a long time to appear and the interval numbers don't look right. The 25us timer is running at 10uS and the 1mS timer is close but the maximum jitter numbers are 184uS and 167uS. Is it possible that your units are off? The internal CPU precision timer is normally in 100pS intervals? . I have added the results of dmesg as boot.txt.

I've successfully installed, compiled and tested the source package from Git. Unfortunately I do not see the RTAI modules I was looking to install. I've must of missed something! Please point me in the right direction. I will try to debug them for 32 bit use.

In the 90's we were driving a film recorder that requires a constant stream of data at 500kB/sec from a 386 computer with 256kB of ram so I think that my experience may help. The film recorders had quite a few stepping motors that needed to be precisely driven.

Keep up the excellent work your doing.
Kind regards
Fred

PS. Found the rtapi ReadMe. Cannot find the scripts/load_rtapi in the scripts directory.

RT_PREEMPT & RTAI are 2 different implantations of real time for Linux.

Generally RTAI will generally give better latency. I know there has been some trouble in getting RTAI to work 100% reliably with 64 bit Buster, I can not recall which actual kernel version and whether this affects 32 bit kernels or whether 32 bits is even supported.
RT_PREEMPT's latency figures are fine when using an external motion control card such as a Mesa 7i76E or 7i92.

RT_PREEMPT looks like it may end up getting merged into the mainline kernel at some stage, so hopefully no more patching.

Was that film recorder running under a non-multitasking environment ?
Once you get into a multitasking environment things get a whole lot different.
There is DOS based cnc control software, TurboCNC springs to mind, that will run fine on old 486 DX machines, something that is not fun trying to run Linux & GUI with. Something I know well from experience in the late 90's.

What command did you use to build Linuxcnc ?

What CPU & MB combo are you using ?

Thank you very much for your response BeagleBrainz. Here are the answers to your questions.
1) Spent a lot of time installing all of the dependencies.
2) I am using a Dell Inspiron laptop with 512 MB of ram 2GHz Mobile Pentium 4 processor, NVidia GForce4Go 32MB VRam and a PCMCIA Wireless N card.

3) The OS used were Windows 98SE and Windows ME. The Windows XP development was never completed.
The original interface was a GPIB interface we manufactured and the final interface used was the standard parallel port running in ECP mode using DMA 3 and IRQ 5, not EPP. The DMA block size was 4 kB and 8 kB.

Please let me know if you have any other thoughts
Kind regards

That old laptop will likely never run Linuxcnc well if at all. Laptops in general are a very poor choice for a real-time application, because built in power saving features get in the was wrecking the real time performance. True there are a few exceptional examples of a particular laptop that may sort of work, but most are simply unusable. I'd suggest looking for another PC that can be dedicated to being "just a machine control". Now if you are simply wanting to run Linuxcnc to check it out or setup configurations or run simulations (not control actual hardware), a laptop (or any PC) can do that just fine and you don't need to install a real-time kernel for that, just install the sim version.

Thanks for the advice Todd. I can tell you that this same laptop would run my film recorder using the parallel port just fine and supply pixels every 2uS under Windows ME or Windows 98SE.

I do not believe its a matter of the hardware. Debian buster has done a good job of taking care of all of the quirky issues. I will use this only to drive my Sherline Mills and lathes and for nothing else. I have many other computers and certainly could even buy a new one or a "raspberry pi" to drive the machines.

I used to drive the Sherline Mills with a 1GHz desktop computer without a problem using the EMC software. Just want to save space..

Are you sure it was a 386, did you have a 387 along with the 386 ?
Hmm the min ram for WIndows 98 is 16MB, are you sure you have your specs right ?

Anyways, what Todd said is true about running Linuxcnc on a laptop. I have a Dual core Dell that is absolutely useless for Linuxcnc. Even the old T61 is kinda borderline.

You may have better luck with an RTAI kernel as opposed to the RT_PREEMPT, they are different animals.

There is a difference in using DMA to pump out data to the parallel port and needing the system to have low latency to twiddle hardware pins at regular intervals.

As much as may not want to hear it your choice of laptop & kernel is not going to work.

You maybe right on the Windows 98, but the first non DOS we used was Windows 3.1 on the original IBM PC. We did have a co-processor but it was not required for our application. My last specs are on imapro.com. The larger memory size required was for image rotation, postscript ripping and resampling.

Without modification I would agree that my laptop would not be able to drive my Sherline Mill. I have the old 1 GHZ desktop will old code that still can run it worst case.

Your right about having to twiddle pins. My thought was that all the pin twiddling could be a pre-process to make a Byte Queue that could be fed to the stepping motor drivers by DMA. Perhaps you are doing this already? Looking over the code would help me determine it.

If I remember correctly the Sherline driver box hardware chips handle the micro-stepping function of the motors and the parallel port just feeds the step and direction pins for the XYZA axis.

In the film recording application the the image size was 3 files of approximately 50MB, one each for red, green, blue. Does the amount of data you need to feed on a typical CNC run exceed these sort of numbers? If you need to feed the motors every 25uS a 50MB file would be equivalent to a 20 minute CNC run.
We would be "Ripping the G-code" just like we ripped images.

Thank you Tommy, I will check them out!

Linuxcnc is preforming the motion control. ie it is doing the timing. It is different to just sending out data.
Back in my Win 95 days I wrote a Vxd to handle parallel port interrupts that were generated by a PIC 16F84. The PIC then generated a bit stream that was based on the byte received, yes similar to a serial port but not quite.
Now if the OS had to generate the timing I would want a system that had lower & more regular latency.
I guess one way of thinking of what linuxcnc does is generating 6 streams of serial data (3 steppers, step & dir for each) that require to be synchronised. Now if you lose that synchronisation your part will not come out as expected. The thing is there is no hardware, as in an serial port, that does the conversion. Imagine having to write a driver for Windows, say pre NT, that does the same. 6 streams of synchronised serial data with all timing and hardware access done in software.
I don't believe generating the data stream & buffering it would work as Linuxcnc has to respond to various inputs, such as limit switches, spindle encoders in real time. How would you accomplish threading on a lathe or rigid tapping on a mill if there was no real time feedback of spindle data ?
It's not actually the absolute horsepower of your system that is important, it is how regular the system is that is important. A 1.2GHz that has low latency is better than a 4GHz that is all over the place.