Debian buster installation with 32-bit RTAI Source

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.

Thats not correct. A parallel port does not use serial data. A port at a specific memory address contains a bit map corresponding to each data pin in the parallel port. So internally, a series of bitwise operators set the data bits and writes it out (as an integer) in one operation. Its a long time ago but I did once write software to control a parallel port as a breakout board before CNC BOB's ever existed. If only I knew what I could have done with this method well before Linuxcnc and Mach existed.

What you say is 100% correct. That is why I was looking on how to route one of the counter timers to the parallel port to act as the strobe to out put the data or input the status at a constant frequency of 40KHz. This would give you the Realtime response you require at a very low jitter rate. Unfortunately the IRQ response time of the Intel product is not good. Too many clock cycles. A z80 processor running at 8MHz had more reliable interrupt response time.

It is the difference between running a "Synchronous State Machine" and an "Asynchronous State Machine".

Do you conclude that even if we can get a constant frequency output the scheme of pre-ripping the stepping sequence would NOT work for stepping motors?

I do agree that if you are running a DC servo motor system with encoders feedback pre-ripping is not practical.

Spindle speed control and tapping remain issues.

Are the ARM processors any better?

I'd disagree.
No I wasn't suggesting a parallel uses serial data. Or each bit was handled & written individually. Maybe 6 parallel streams of serial data would have been more apt.
I guess when you say "A port at a specific memory address" you actually mean a location, generally a port is considered to be a physical connection to the outside world, unless of course we are talking networking.
I guess it could be described as a temporary holding area ?
But if take each bit in isolation, say the bit that is driving the step signal for the X axis and view it on a scope it will be seen as serial data, not any identifiable protocol but a stream of serial data.
Now look at X-Step, X-Dir, Y-Step, Y-Dir, Z-Step & Z-Dir on a logic analyser and you will see 6 streams of serial data.
It was more of a broad description of what is happening. Just to drive home the need for everything to be in sync. We lose that sync (regularity) and parts end up as scrap.

A good platform, unfortunately a little underpowered and only supported by Machine Kit is the Beagle Bone Black, as it has 2 separate microcontrollers that run independent of the OS that can be used to generate the hardware signals for the steppers. I used one for about a year, but for various reasons I changed to Linuxcnc & Mesa connected Ethernet solution.
But we still get back to the need for regular latency/low jitter.

I think the best solution we have, that allows a broader scope of machines is the solution we have with the Mesa FPGA cards. Linuxcnc still generates the timing data but the "bit twiddling" is handled by an FPGA.........A very broad and basic understanding of what happens. Rather than having a base thread of 25us and a Servo thread of 1ms we just need the servo thread. And the system can tolerate a greater latency..up to a point.
Whilst it may be a more expensive option initially, I believe that (especially the ethernet solution) has some "future proof" as I can't see the humble Ethernet port disappearing too soon....tho B Gates did say that 640k RAM was more than enough.

Looks like old mate is running an old 32 bit P4.

Hello Andy,
That is the very first thing I tried. The live CD would not even load. I did manage to get wheezy and and precise to load but they both hung as soon as I enabled "lapic" whilst buster 32 bit worked perfectly. BTW I had to change the latency base-period to great than 60uS in order for it to not load 10uS into the counter.

@Beagle
It must be age that is making me not want to discard this laptop. Maybe I do not want the same end result?

PS.
I've just ran a latency test using your LinuxCNC 2.8 Live ISO on my Acer 8943G laptop that has
Intel I7-740MQM Processor
8GB of DDR3 DRAM
ATI HD5850 Video
SSD 1TB

The numbers appears to be much worst Max 1mS timer 1.969mS Max 25uS timer 141uS. All my tests are with wi-fi disabled. and no other activity.

Same test on 32-bit system except base-time set to 66.666uS for it to run
1.154mS
190uS

There is awesome similarity between film recording and CNC machining. If your timing is off, in one you have a piece of scrap film in the other you have a piece of scrap..

Here's a sample quick test of my T530 with wifi on with a 35000 base thread. With Firefox open whilst reading this thread.
Not really a full test but it goes to show that a lesser spec machine can give better results.
This is with the same kernel that I supply on the Mint 19.2 Linuxcnc ISO the 19.3 ISO has a slightly later version on the RT_PREEMPT patch. Just for completeness the BIOS options have been set to the lowest power saving options.



Same machine with CPU #1 isolated

When the CPU is isolated , the ISR is entered more reliably because the time to swap CPU does not have to be added? You obtained 1/2 sdev with a shorter base period and 1/4 sdev for the servo period. It makes sense. The Max Min numbers you are getting with a single cpu are quite acceptable in my view. What is your opinion?

Do you know if the interrupt to the ISR is routed through the APCI or is it direct? Depending on the hardware design irq3 and irq4 may get you into the ISR more quickly.

The processor can be disabled in the Live LinuxCNC 2.8 buster ISO by editing the Grub at boot and adding "isolcpus=1,2,3,4,5,6,7" where quiet and splash are shown from the in the menu.

This image is running on the I7-740 with wireless disabled and 1 processor enabled


This image is running on the I7-740 with wireless disabled and all 8 processor enabled

At a pinch even the non isolated cpu boot could be used.

I'm not a kernel dev, and to be honest haven't looked at IRQ routing under Linux.

Minds much much greater than mine have decided that the current way Linuxcnc is the way to go. Other minds have forked Linuxcnc to the MachineKit project.

Basically what I was trying to illustrate is that CPU speed is not a great indicator of Jitter & Latency figures. Many users have had good results with mini ITX boards with J33xx series celerons.
Currently I was using ( hmm that sound strange) a Asrock J3345B board but am now moving towards an Odroid H2 plus.......which as happens has led me to make other improvements.....everything at the moment is on a "slow bost form China" on it's Down Under.

For a more thorough discussion the dev mailing list on sourceforge might be the best option for a more thorough discussion.

If you want a low foot print system Grbl might be the go for a simple mill. The sender will run on almost anything. At it's basically level you may even be able to send a file via the serial port like on was possible with an old HP HPGL plotter.