Retrofitting lathe equipped with AMK Pumasyn servo drives

Hi,
I would like to retrofit a lathe that was made in 1990 and fitted with AMK Pumasyn drives. Originally the display/control unit was a Visulesta 4 unit but that does not work any more.
The original setup is as follows: The AMK drive system is modular, there is only one power supply module. There is two smaller drive module for X and Z axes and then there is a bigger module for the spindle. The motors are induction AC motors and each equipped with internal encoder (wired to the drive module it belongs. There is a fourth, 2500ppr encoder driven by the spindle via toothed belt. This encoder is wired parallel to the primary inputs of the three drives.
There are also two hand wheels with 100ppr encoders wired to a secondary inputs of the X and Z axes respectively. There is also a spindle index sensor.
The Visulesta unit talks to the drive modules by three independent RS422 lines with 9600bps (i guess). There are also speed and feed override knobs with 4 wires each and a hand wheel sensitivity switch with 3 wires. There are buttons for cycle start/stop, a 4 way joystick with fast speed override (5 wires) and there is a spindle start/stop lever with CW and CCW positions (3 wires). These are wired to the Visulesta unit.
What I know for sure is the Visulesta has 32 inputs, 8 outputs and 3 independent RS422 interfaces.

The AMK drives accept telegrams in an AMK specific format, and a subset of DIN 66025 G code format.
The hand wheels wired to the drives are enabled/disabled by the Visulesta unit through RS422.
If I understand correctly the actual G code processing is partly done by the drive modules (although I don't know what the Visulesta unit does exactly). This machine was called to cycle controlled as there was no possibility to upload G-code from outside.

My question is: How could I retrofit this lathe with LinuxCNC while keeping the original drive modules?
- Is it possible to setup the LinuxCNC to be able to communicate with the drives via RS422 like the old controller did?
- Or (If I understand correctly, the drive modules can be reconfigured to accept signals similar like step/dir) theoretically would it be possible to configure for example a MESA 7I90 card to 3*step/dir output and GPIOs for all the other things? Or possibly use a free parallel port for additinal input/outputs?

Sound like fun

You might be able to retain RS422 control, if you know the format of the datagrams.
It's certainly worth a try, just using a USB to RS422 converter and a terminal emulator program.

How long is a datagram? Bear in mind that the most practical form of a LinuxCNC HAL driver would simply send a new position command every 1mS. So the data packet needs to be short enough to be sent in that time at 9600b.

Is there any particular reason that you are looking at the 7i90? Are you looking to control via the parallel port? Or is the plan SPI control with a Raspberry Pi or similar?

If you feel that RS422 control is the way forward, then the HD50 cards (like the 7i90) are the right choice as ypu would want to be using the 7i44 serial interface rather than the 7i74 one. This is because the 7i74 only has one RS422-capable channel.

Actually, if the drives are daisy-chained, 1 channel might be enough.

I think that step 1 is to check if the drives can be reconfigured for step/dir, quadrature or +/-10V drive. All three are well-supported by LinuxCNC.

Maybe take a look here for a driver which uses the Mesa UARTs for serial control: github.com/LinuxCNC/linuxcnc/blob/2.9/sr...sa_pktgyro_test.comp though that particualar driver is recieve-only.
The point is that it is probably easily done with a custom HAL component:
linuxcnc.org/docs/stable/html/hal/comp.html

Thank you for your message.

There is only one reason why my first try would be the 7I90 and that is purely the price.
I am sorry, I am not good at social interaction so feel free to ignore the second half of this paragraph. The short description is that due to the continous poor choice of the people here the overall situation is quite sad.

The original manufacturer of drive unit was kind and sent me the user manual for the drives so theoretically I know the the format of the telegram/datagram.
The drive - among others - support a "fast direct processing" setpoint value transfer mode where setpoint value *increments* can be transferred by sending 3 ASCII characters, so 3 bytes. I don't know the processing speed though. The manual claims that the sampling time in position control mode is 1 ms but it does not specify what parameter or value is sampled exactly. In this mode the first character is the control mode identifier (position, speed or torque) then 2 bytes of data of 14 bits in resolution distributed to 2*7 bits with a padding bit of a constant 1 in the MSB positions.
Datagrams sent in other modes first go to a buffer from where the processing time is approx. 150 ms. The buffer is 256 bytes and can hold maximum of 2 datagrams, but based on the manual the average datagram lenght is 5-20 characters long.

The drives are addressable so theoretically can be daisy chained.

The actual ports on the drives are RS232C and the physical connectors are 25 pin d-sub. They are converted to RS422 for signal integrity reasons by a plugin board supplied by the manufacturer. There are + 5 and +/- 12 V supply voltages present on the connector for these kind of purposes.

My first choice would be a PC rather than a rPI.

Dummy question: For RS422 (RS232) communication could one or more RS232 com port(s) be used instead of a Mesa daughter board? I can solve the signaling conversion between RS232 and RS422.

The drive theoretically can accept pulses as setpoint value but these pulses are not exactly step/dir nor quadrature pulses (please find the attached image). For these pulses there are two sets of differential inputs (one set for each direction). The step/dir pulses can be easily converted to the pulses the drives expect.

Theoretically it is possible to input setpoint values via +/- 10 V analog inputs or via some kind of a digital parallel input but for these optional cards would be necessary and I don't think I ever could acquire those.

Thank you for the links for the literature. I will try to understand it.

kisslaci10 wrote:

Dummy question: For RS422 (RS232) communication could one or more RS232 com port(s) be used instead of a Mesa daughter board? I can solve the signaling conversion between RS232 and RS422.

Possibly. The issue here is accessing the port in realtime. 
The parallel port is accessed in realtime by direct port writes. I don't know if you can do that with a com port. 

The serial ports on the Mesa cards are definitely addressable in realtime. 

A bit of Google does suggest that kernel mode access via inb and outb is possible:
www.linuxquestions.org/questions/program...kernel-185959-print/

 

This will be a tough ride.
The only things I wrote "software" to are some PIC microcontrollers. And those "software" were also written only in assembly.
So understanding a complex software running on a complex OS is no less than quite a challenge.

Another dummy question: Do I understand correctly that the 7I44 is "only" a breakout / signal conditioner / level shifter / protection board and the actual com port is not realised by that but by the fpga board?
What I mean, if I manage to purchase and *correctly setup* an fpga board, the "only" (?) remaining task is to realize is to correctly interfacing the fpga inputs/outputs to the machine?

Another dummy question: Do I understand correctly that the 7I44 is "only" a breakout / signal conditioner / level shifter / protection board and the actual com port is not realised by that but by the fpga board?
What I mean, if I manage to purchase and *correctly setup* an fpga board, the "only" (?) remaining task is to realize is to correctly interfacing the fpga inputs/outputs to the machine?

Yes, the 7I44 is just interface hardware, all the logic in in the FPGA.