The printer port isn’t dead! (linuxcnc is cool and powerful)

[sam sokolikParticipant @samsokolik60334]

I grabbed the last Emco that needs a little work… I wanted to show that the printer port is still a cheap way to get into a industrial grade machine controller. Yes – linuxcnc will output step/direction just fine – but I wanted to show that you can also run closed loop setups also. The printer port is reading the encoder and outputting pwm to the drives. Linuxcnc closes the loop and does the PID.

Here is how the control loop will work..

The motion will be speed limited – the encoder + gearing will have a resolution of .0005mm… That means a max of around 50ipm no head room. (still faster than the original steppers at 27ipm…)

Here is it running at 35ipm…

[sam sokolikParticipant @samsokolik60334]

[sam sokolikParticipant @samsokolik60334]

I also re-balled the z axis ball nut.. It was pretty cruddy.. The ball recirculation path was swaged in and then hardened.. I had to break the swaged metal to pull the recirculator out.

[mike TParticipant @miket56243]

Hello Sam

Nice work on the lathe and also on re-balling that tiny Emco ball nut.

I also have an Emco Compact 3 CNC running on LinuxCNC, but stepper motors only. I have three questions for you regarding the ball nut.

1 What is the correct number of balls installed in the Emco ball nut?

2 Did you redo the ball nut and replace the two loose balls. Did they make any difference?

3 How did you retain the circulation tube after the rebuid; I understand it was originally swagged to the body

Thanks for your help

Mike

[sam sokolikParticipant @samsokolik60334]

Posted by mike T on 24/08/2022 17:44:55:

Hello Sam

Nice work on the lathe and also on re-balling that tiny Emco ball nut.

I also have an Emco Compact 3 CNC running on LinuxCNC, but stepper motors only. I have three questions for you regarding the ball nut.

1 What is the correct number of balls installed in the Emco ball nut?

2 Did you redo the ball nut and replace the two loose balls. Did they make any difference?

3 How did you retain the circulation tube after the rebuid; I understand it was originally swagged to the body

Thanks for your help

Mike

1) the few times I have counted them – I get 52..

2) Yes – I re-balled it with new ones I had at the shop. I think 1 might have snuck out – I just went with it. I don't think a couple short is going to be a problem.

3) Currently I just have a piece of plastic jammed between the ball nut and the housing.. Seems to be working ok. I was thinking maybe a small amount of epoxy on each end might keep them in. Just would have to make sure that the epoxy doesn't flow into the channels..

[sam sokolikParticipant @samsokolik60334]

Edit – It was better but still was a bit crunchy. I think moisture got into the nut and pitted it slightly. I might replace them with 12mm ball screws. (these are 8mm)

[sam sokolikParticipant @samsokolik60334]

Going to replace the existing ball screws with some 12mm diameter 4mm pitch ball screws. The ones on there are just a bit too damaged..

[sam sokolikParticipant @samsokolik60334]

replaced these

with these…

[Michael GilliganParticipant @michaelgilligan61133]

Posted by sam sokolik on 24/08/2022 16:30:47:

… I wanted to show that the printer port is still a cheap way to get into a industrial grade machine controller. Yes – linuxcnc will output step/direction just fine – but I wanted to show that you can also run closed loop setups …

.

A noble ambition, Sam … and it seems that you have achieved it

Well-done, Sir !!

MichaelG.

[sam sokolikParticipant @samsokolik60334]

Looking at the parallel port – it looks like I have a pci version that runs what is called x mode. This balances in's and out's better..

Pin
1 in Estop
2 out x pwm
3 out x dir
4 out z pwm
5 out z dir
6 out spindle pwm
7 out spindle dir
8 out drives enable
9 out
10 in x encoder a
11 in x encoder b
12 in z encoder a
13 in z encoder b
14 in spindle encoder a
15 in spindle encoder z
16 in x home
17 in z home

I am sure I forgot something.. I could share home switches to get an extra input.

sam

[Joseph Noci 1Participant @josephnoci1]

Sam, you have always done something interesting with CNC – I would enjoy a rundown of all the CNC machines in your shop that you have home-brewed.

That printer port allocation is certainly full!

The drive you are using says 'brushless motor drive' – shows 3 motor drive outputs which makes sense for a 3ph brushless motor, but you have only ph A&B connected to the motor, so I presume it is a brushed DC motor. How does that drive handle the brushed motor? Could not see a part number on the drive to google its spec sheet.

I presume what you called PWM output from Lcnc to the drive is the 'step' signal, so it makes the DC motor look like a stepper with resolution = to the number of encoder lines?

In the video there is a green breakout block – the printer port cable plugs into it and then there are screw blocks to take the port signals to the rest – where did you get that block? Very neat device…

Do show more!

Joe

[sam sokolikParticipant @samsokolik60334]

Posted by Joseph Noci 1 on 31/08/2022 07:09:16:

Sam, you have always done something interesting with CNC – I would enjoy a rundown of all the CNC machines in your shop that you have home-brewed.

That printer port allocation is certainly full!

The drive you are using says 'brushless motor drive' – shows 3 motor drive outputs which makes sense for a 3ph brushless motor, but you have only ph A&B connected to the motor, so I presume it is a brushed DC motor. How does that drive handle the brushed motor? Could not see a part number on the drive to google its spec sheet.

I presume what you called PWM output from Lcnc to the drive is the 'step' signal, so it makes the DC motor look like a stepper with resolution = to the number of encoder lines?

In the video there is a green breakout block – the printer port cable plugs into it and then there are screw blocks to take the port signals to the rest – where did you get that block? Very neat device…

Do show more!

Joe

the drive is an BD15A8. It is an brushless DC AMC drive that will also run brushed servos. (most all of the AMC 'B' drives will also work with brushed servos also). It is a 15A peak 7.5A continuous 80v max. Most of these series of amc drives take +/-10 volt input signal. These drives take PWM and Dir. It can be considered an analog signal. (but works well with computer control)

AMC Data sheet

It isn't a step signal. You are in effect sending the drive an analog signal based on the pid output. The encoder is read back and the control loop is constantly adjusting the pwm signal to control the servo. 2000 times a second.

The terninal block is something we got off of ebay years ago.. I am sure you can get them for mouse or digikey? I have not looked.

sam

[sam sokolikParticipant @samsokolik60334]

more mansplaining..

[SillyOldDufferModerator @sillyoldduffer]

Excellent!!!

If anyone had asked I'd have bet money Parallel Printer ports had gone the way of the Parish Pump! Useful to know they still exist because parallel pins were by far the easiest way of connecting a multi-user/multi-tasking computer to external electronics.

Any idea how a parallel port's performance compares with twiddling pins on a Raspberry Pi 4? What's the highest frequency a parallel pin can output, and what's the highest frequency that can be put on an input that a program can reliably work with?

I've experimented with a Pi4 in various real-time modes to see how fast it's IO pins can be made to go and results are both good and bad. Output is quick except for awkward pauses due to the scheduler. High-speed input is erratic because there's no way I know of directly handling an IO interrupt in Linux or Windows. Thus inputs are either delayed by the operating system or a CPU has to be dedicated to reading a pin continually in a loop, which is hot, messy and not expandable. And still misses some inputs due to the scheduler taking the CPU out every so often.

Does a Parallel Port on a PCI-card overcome these problems, or is a PCI parallel port's performance similar to the original – designed to work a relatively slow printer?

My concern isn't CNC specific, it's more a general interest in interfacing computers to fast real-world events without extra hardware.

Dave

[sam sokolikParticipant @samsokolik60334]

Posted by SillyOldDuffer on 01/09/2022 18:03:00:

Excellent!!!

If anyone had asked I'd have bet money Parallel Printer ports had gone the way of the Parish Pump! Useful to know they still exist because parallel pins were by far the easiest way of connecting a multi-user/multi-tasking computer to external electronics.

Any idea how a parallel port's performance compares with twiddling pins on a Raspberry Pi 4? What's the highest frequency a parallel pin can output, and what's the highest frequency that can be put on an input that a program can reliably work with?

I've experimented with a Pi4 in various real-time modes to see how fast it's IO pins can be made to go and results are both good and bad. Output is quick except for awkward pauses due to the scheduler. High-speed input is erratic because there's no way I know of directly handling an IO interrupt in Linux or Windows. Thus inputs are either delayed by the operating system or a CPU has to be dedicated to reading a pin continually in a loop, which is hot, messy and not expandable. And still misses some inputs due to the scheduler taking the CPU out every so often.

Does a Parallel Port on a PCI-card overcome these problems, or is a PCI parallel port's performance similar to the original – designed to work a relatively slow printer?

My concern isn't CNC specific, it's more a general interest in interfacing computers to fast real-world events without extra hardware.

Dave

Hello!

SO – Linuxcnc runs a real time kernel. You test the real time latency of the computer. How fast you can read/twiddle the bits is based on that. So – if you use the printer port you are relying on the computer to do the high speed stuff (PWM, Step generation, encoder reading and so on) So you normally have 2 real time threads when doing it all in the computer.

Base thread (fast thread that does the high speed reading and pulse generation)

servo thread (usually 1 to 5khz that does the trajectory planning and pid calcs and such)

(side note – when you have external interface hardware – like Mesa – the high speed stuff gets moved to the external hardware – so you don't have the base thread anymore. You still have a 1-5khz real time thread in the computer)

The base thread speed really depends on how well the computer can run the realtime kernel. The computer I am using in the video is a 3rd gen i5 HP. It has pretty decent latency and allows for a base thread of around 40-50 khz. I have not seen computer hardware get much higher than that with linux/linuxcnc.

I have not seen much of a difference between onboard, pci and pci-e printer port cards. (other than some features are there or not depending on how it was made)

I have have tested linuxcnc with gpio on the rpi 4 – the base thread I got was 20khz – but because some functionality is missing in the linuxcnc gpio driver – you can only get 10khz step pulses. (the printer port driver for linuxcnc has a reset function which allows you to output steps at the base period frequency.) The rpi4 does play nice with Mesa hardware – I use an ethernet to run the below machines.. Spi is an option to.

Here is the same machine running off the printer port.. (audio even sucks worse than my normal sucky audio)

[sam sokolikParticipant @samsokolik60334]

as far as real time threads go.. Say you have a 25us base thread. (40khz)

Every 25us (+/- latency) code runs (outputting steps, pwm, setting i/o, reading encoders, whatever)

this happens every 25us. (otherwise it isn't real time)

Same goes for the servo thread say – 1khz

every 1ms

• Read all inputs from external hardware including position feedback (sense)
• Trajectory planner, ladder logic, pid, etc (model, plan)
• Write all outputs on external hardware, including torque/velocity commands (act)

sam

[Frances IoMParticipant @francesiom58905]

I used a similar approach with an old 8086 computer running Dos in the 80’s – one interrupt – the RTC jacked up to better than 1 ms which code merely read status bits, in my case of several serial lines which if were ready then read or transmitted into or out of a buffer and exited – probably used less than 30% of the extremely limited processor time in this tight code – processing of the data was done by a simple scheduler running a task until it gave up control – obviously buffer lengths needed to be correctly chosen.

[Michael GilliganParticipant @michaelgilligan61133]

Useful link, here: **LINK**

http://wearcam.org/seatsale/programs/www.beyondlogic.org/index.html#PARALLEL

MichaelG.

[sam sokolikParticipant @samsokolik60334]

When the ball nut doesn't fit.. Grind it. Don't look too close. Don't know if it fits yet – the lathe is at the shop.

sam

[sam sokolikParticipant @samsokolik60334]

Test fitting.. One of the main reasons for a 3d printer…

[sam sokolikParticipant @samsokolik60334]

Little update.. Made some 3d printed parts to mock up the new ball screw.. Looks good. I think all I have to do is move the ball screw out about .050" or so.

With the courser ball screw (2.5mm -> 4mm pitch) the input scale went down (50800 -> 31750 pulses per inch ) This and using a pci-e printer port which seems to allow for a slightly faster realtime thread – I can get easy 90ipm.

The base thread is running 18us or 55.5khz. 55,5555/31750 = 1.75 in/sec (if the quadrature of the encoder is perfect and counts every base period) giving a little headroom – 1.5in/sec or 90ipm.

Edited By sam sokolik on 09/09/2022 15:42:33

[Michael GilliganParticipant @michaelgilligan61133]

Great stuff, Sam … that all looks very encouraging

MichaelG.

[SillyOldDufferModerator @sillyoldduffer]

Posted by sam sokolik on 01/09/2022 18:38:22:

Posted by SillyOldDuffer on 01/09/2022 18:03:00:

…

Any idea how a parallel port's performance compares with twiddling pins on a Raspberry Pi 4? What's the highest frequency a parallel pin can output…

I've experimented with a Pi4 in various real-time modes to see how fast it's IO pins can be made to go and results are both good and bad. Output is quick except for awkward pauses due to the scheduler…

Dave

…

…

The base thread speed really depends on how well the computer can run the realtime kernel. The computer I am using in the video is a 3rd gen i5 HP. It has pretty decent latency and allows for a base thread of around 40-50 khz. I have not seen computer hardware get much higher than that with linux/linuxcnc.

I have not seen much of a difference between onboard, pci and pci-e printer port cards. (other than some features are there or not depending on how it was made)

I have have tested linuxcnc with gpio on the rpi 4 – the base thread I got was 20khz – but because some functionality is missing in the linuxcnc gpio driver – you can only get 10khz step pulses

Sorry about the delay replying – having a busy week. I wrote this user-space code to test rPi output speed:

Assuming the library is efficient, I believe the program gets close to the maximum General Purpose IO output achievable from a Pi4. About 4.0MHz, two hundred times faster than linuxCNC's 20kHz, but unlike linuxCNC my code does absolutely nothing useful!

I think the scheduler and memory lock settings used have the effect of dedicating one of the 4 CPUs to my process, maximising the time between scheduler interruptions, and forbidding swapping (admittedly unlikely on a lightly loaded computer).

Next oscilloscope screen shot shows the scheduler to be working in blocks of 1 second, in which my program runs for 956mS, and is paused for 44mS in every second:

44mS is too long for my taste – needs investigation. Reading is more difficult I haven't found a quick way of responding to incoming bits in user-space yet.

Whilst busy flat out pin flipping the pi4 supports other activity more or less normally – the other 3 CPU cores handle business as usual and seem unaware that the 4th core is running flat out. Pretty sure the chip has ways and means of generating faster output in hardware, but that's cheating.

I looked at the linuxCNC source to see how it manages real-time IO and couldn't find it. There's a lot of code!

Dave

[sam sokolikParticipant @samsokolik60334]

Very cool! Yes – the hard part is making it deterministic… I can't say I fully understand how linuxcnc does it. It uses the rt_preempt kernel (which is now part of the Debian repository)

They use the real time api to create the threads.

You can isolate cores for real time – it helps but you won't get mhz thread. (at least in my experience)

For machine control – most of the 'control' can be done in a relatively slow thread. (1 – 10khz) calculating the PID, Trajectory and stuff.. The faster stuff can be moved to hardware. (but again – still doable in the computer as long as 50khz works..)

sam

There is also an RTAI patched kernel which is still available – but requires a bit more work. It used to be that it performed better than the rt_preempt kernel but in my experience they usually have similar latency now.

sam

[sam sokolikParticipant @samsokolik60334]

Saving a pin on the printer port using missing tooth functionality.. (to create an index pulse)

[Author]

Posts