Is the Ecoca EL4610e a good candidate for a retrofit?

Okay that sounds indeed like something that I should try once the card arrives. Am I correct in assuming that any board which can be programmed in C and is capable of half-duplex RS-485 should work with your firmware with perhaps a few minor mods, or should I stick to stm32 architecture? I'm asking because I have a whole bunch of esp32 and STM32F103C8T6 boards lying around.

any MCU will do as far as its UART can handle 5Mbaud. a quick google search suggests that the esp32 can.

not really. my card only implements the "SV1" part of the CF10 connector

yeah but sv2 isn't hooked up, the encoders are reached trough to linuxcnc by your board directly from the drives if I understand correctly, RIO2 isn't hooked up, and the way I see it, RIO1 is reached trough directly to the RIO Board.

attached is the base i/o board diagram. sure, everything servo/spindle drive related coming thru SV1 (MC link A) bus. the spindle position feedback can come from either of 3 different sources:
1. spindle motor build-in encoder/PLG, via SV1
2. external spindle encoder connected to the spindle drive, via SV1
3. external encoder connector directly to the NC, via ENC
SKIP are fast(ish) optoisolated inputs used for touch probes and the like.

the second CF61 connector has 3 x 5VTTL MPG inputs (HANDLE), second encoder (ENC#2), EMG and a couple of RS-232s.

discrete IO is connected to the MM64 NC with a couple of serial buses RIO1, RIO2 (MC link b). 2 stations (32in/32out each) are present on the base I/O board, accessible via RIO1 and terminated at CF31..34 IDC40 connectors. additional I/O, if any, can be added to RIO1,RIO2 buses as stand-alone DXnnn units with similar IDC40 connectors.

so, with some rewiring and a bit of external circuitry almost all functionality can be duplicated with my YMDS2P card. in addition to the SV1 bus equivalent, 12ins/8outs the firmware has 2 quadrature decoders with index (ABZ), 4 MPG inputs (AB). the only missing thing currently is that RIO bus... though RIO uses a common RS-485, the protocol is kinda odd HDLC-based. no problem implementing it in a FPGA, but not with cheap MCUs. so i can't use my YIOs as slaves on the RIO bus unless i add some kind h/w doing the protocol translation...

sorry, it's mostly me convincing myself that i should implement that RIO thing and re-route my card to a MDR50 connector with CF10-compatible pinout so it will be mostly a plug and play retrofit...

No i totally get that. Plug and play would actually be a pretty great solution, there are still quite a few
machines with mm64 controllers out there, and not everyone has the time/knowledge/motivation/help to do a custom retrofit.

I bought my machine for ridiculously cheap from a small production shop. In hindsight it was probably for that exact reason, because it actually didn't have that many hours on it and they bought a newer machine of similar size as a replacement. I'm assuming they couldn't afford to have the machine unexpectedly fail on them and having no way of fixing the problem.

Used MM64 cards currently go for about 1300$ on ebay if you can even find them. Add to that the fact that you'd also need some pretty old hardware and the correct drivers, which seem to be impossible to find if you don't already have them, and it becomes pretty obvious that there should be quite a market for available hardware that has the same/superior functionality and can be configured easily.

Tough I think if you want to build a true drop-in solution, you also need to account for the relay board on the cf61
connector.

You seem to have most things figured out it seems, but if it helps, I can try to get a logic analyzer and do some investigating for you if you tell me what you need to know.

A pretty cheap solution for the RIO protocol problem would perhaps be a CPLD?

Have a look at Max II EPM240 CPLD development boards. They only have 240 logic elements and are only tolerant up to 3.3V, so I'm not sure if they're up for the task at hand, but they can be had for ~7$ from the usual suspects. I bought a couple of them about a year ago to try and teach myself VHDL someday.

just scored a full working meldas 65s nc set. so implementing the CF10 connection to the base I/O board looks pretty doable now. also have the FCUA-DX121 RIO unit with an analog output - can support that too.

Very nice.
Excuse the absence, I had a few things to take care of.

Should I hold back on configuring alternate solutions and wait for your modification of the firmware then, or do you think this is going to take too long to wait for it?

So, the card arrived today. It is properly set up on a fresh linuxCNC install and all necessary packages are installed.

I will begin trying to communicate with the drives in the following days. I'll probably start by setting up the parameter file. Since the .bin and .lad files I recovered from the original pc habe proven to be human-unreadable with any program that I know of, it very much looks like I am stuck manually retyping everything from the parameter list I got with the lathe.

Just to clarify- since the lathe uses only two drives for x and z I can delete the third column in mds.par without causing any configuration issues, right?

Also: my parameter list only goes up to sv064 and sp0384 respectively while the mds.par files go up to sv080 and sp0400.

Is it better to remove the excess lines, to fill them with zeroes, or to leave the standard values in there?

I'm wondering if the drive's memory will perhaps give an error if nyx is trying to load parameters into memory adresses which don't exist, or if they will throw errors if certain parameters aren't loaded.

Is there some thread here on the forums where setting up YMDS2P is discussed and which goes beyond the initial setup that is provided on the yurtaev.com website? I know I still have quite a bit of reading to do on different hal components and the halui, but I'd be curious to see just about how much configuring I can expect to be doing.
I also couldn't find any explicit references to configuring Estop loops in the tutorial, but I'm assuming you just forward a generic I/O pin signal to the hal and connect it to the appropriate pins.

This however leads me to another question: what voltages and currents are the I/O pins designed for?


This has originally been discussed in the mails between dm17ry and me, but I currently don't have access to the electrical cabinet on the back of the machine, as the pandemic has once again thrown a wrench into some of my plans, such as getting the equipment to move the machine away from the wall which it is currently backed up against.

However, anticipating dm17ry's decision to go all out on this projet and adapting the IO Units into his firmware, I already bought all the necessary male and female mdr plugs to splice custom bridge cables between the new control PC and the original cf10 and cf61 plugs that are currently connected to the M64 control card.

Since the drives don't have an EEPROM where they store values anyway and need to be reinitialized on each startup, this should allow me to seamlessly switch between the new setup and the original control station until I got everything working reliably on the new system.

I will do a bit of research myself, but currently the two questions that I have are these:

1.Are the signals from CF10 simply reached trough the BaseIO unit to the SV1 connector, actually allowing me to splice the wiring accordingly, or is there some transformation of the signal happening in between which makes such a thing impossible with the current firmware?
I honestly doubt there should be any problems, but given the schematics that I provided, and that I really don't want to break anything, I figured I get a second opinion before I go and release the magic smoke.

2. @dm17ry: could you post the SV1 pinout that you used when programming your card? Last thing I want is to use an outdated/incorrect pinout diagram and fry everything because of such a stupid mistake.

rodw wrote:

Hi, guys, I've seen this machine with a broken Mitsubishi controller for a good price.
I was thinking it might make pretty good retrofit project

The listing says it has a 75mm spindle and D1-8 chuck

It would be nice to know if I could reuse the servos with LinucCNC. I have no idea what they would be.
Any background on Ecoca's would be appreciated.

I Bought this machine and put an Adtech 4620 controller on it.
Its in my garage at home, and it works pretty good!

I have just purchased one of these lathes and I'm looking to retrofit/upgrade the control system. And I found myself here. I was wondering how did this conversion work out? Did you manage to retain the apron handwheel operation?

Thanks for the speedy reply. I will have the lathe home by the end of this week, then I can have a better look at what I am dealing with. At the moment it has a communication to NC unit issue. Trying to decide if I look into that first so I can assess the rest of the machine or just jump straight into the retrofit. Don't want to waste too much time/money fixing a problem that may well be redundant.