Emco PC Turn 55 retrofit

yep saw you mention that on your you tube channel, some people don't understand that if they help you this time the next time someone says what should I buy , your going to favor the people that are helpful
.

I am thinking of reusing the front plate of the AC95 card, and building some Wisemuller optimate connectors onto a new pcb board behind it , that way I wont have to alter any of the original wiring , just build the control card onto the back of the AC95 face place.

I always wish people lived close to me so I could go and help them with stuff :lol:

DB wrote: I am thinking of reusing the front plate of the AC95 card, and building some Wisemuller optimate connectors onto a new pcb board behind it , that way I wont have to alter any of the original wiring , just build the control card onto the back of the AC95 face place.

Not a bad idea if that's how you want to do it, but honestly, the 7i76ed interfacing was easy. I had full functionality of my machine in roughly the course of 4 or so days. The tough part is just gonna be the turret logic, but I'm going to work on that later today.

yep , still reading up on Lynuxcnc, its not clear if you have to write a post processor, or if they are available, I am not a programmer , I have butchered some code for a friend with a cnc router, but that about it , from his point of view , and I know its blasphemy here mach is the way, I figure what ever card I use can be mounted to the rear of the AC95 face plate and I may even get a mini pc in there along side it

Mach sucks - I used to suffer through that junk crashing on me all the flippin' time.

LinuxCNC takes standard G and M codes, same as a Fanuc, Mitsubishi, Centroid and yes, Mach would take. If you want to get technical, LinuxCNC and Mach share the same ancestral history.

As far as your code is concerned, there's nothing special to it:
G1 straight line
G2 clockwise arc
G3 counterclockwise arc
G4 Dwell
etc.

Any standard Fanuc style post will work for your application. I have multiple CAM systems and have no major issues with getting any of them to output what I need. The things that do tend to vary are M codes, but that's builder specific in my line of work (Applications Engineer for a global machine tool company). The standards are always the same:
M3 clockwise spindle
M4 counterclockwise spindle
M5 spindle stop
M8 flood coolant on
M9 coolant off
M30 program end and rewind
etc.

You won't have any issues with finding posts. If you use FreeCAD, they actually have a post called LinuxCNC that is pretty clean from what I saw in their CAM module (I used it for about 8 seconds, so I'm no pro at it).

As far as computers go, I tried a U700 micropc with horrid results. I'm talking 400k servo-thread latency. My laptop is 65000 without running isolcpus in Linux, turning it on nets me about 15000, which is flying for Mesa hardware. Running isolcpus on the micropc resulted in 50k at best, which wasn't good enough for my taste, so I sent it back. I'm running my Emco from a Raspberry Pi, but I'm still in the tinkering phases with it, so I can't really give the gold star with it yet. It seems promising, but the touch screen drivers are flaky, so I'm a little perturbed over that. If you manage to find a good mini-pc board, clue me in as to what you're using.

I started uploading my retrofit videos, if you want to check them out.

Note that with Ethernet cards, what's important is that you can meet the servo thread timing.
The actual latency is not really important as long as the servo thread deadline is met.
Even 400 usec latency would be OK if you can run the servo thread at a sufficient rate.
1 ms (1 KHz rate) is the normal period but 2 ms (500 Hz) is OK for many applications.

The reason that the latency is not terribly important (and you don't really gain anything by reducing it)
is that Mesa Ethernet cards (and PCI/PCIE cards if the DPLL module is present) re-time timing critical
operations to eliminate the effects of host jitter. This re-timing reduces the sampling time uncertainty
to the 200 ns region.

Peter, a very timely reminder that there is no need to chase latency down to the nth degree. Without a base thread, latency can be far higher than what many people are striving for. I think a lot of people get far to carried away reducing it.

rodw wrote: Peter, a very timely reminder that there is no need to chase latency down to the nth degree. Without a base thread, latency can be far higher than what many people are striving for. I think a lot of people get far to carried away reducing it.

Agreed. I had good results on my laptop with 65000, but the pi@200 with 50800 step per inch settings didn't care much for 75ipm rapids. The gearing on this lathe is wacky. 2.5:1 motor reduction, 2.5mm ball screws, 200 steps with 10 micro... Started getting flaky, so I dropped it to 130 and it's been better

Those issues are not likely to be latency related, even 100s of usec of latency
have negligible effect on the step generation and the maximum step rate is
complete unrelated to latency with Mesa cards.

If you have poor latency (but good enough to avoid real time errors)
You do need to have the DPLL setup and enabled to be able to generate
clean step signals.