Advanced Search

Tommy thanks. So Yaskawa would be preferred correct ? What kind of latency issues are there with EtherCAT ? Is it on the LinuxCNC side or due to network ?

1) yes

2) If you have a simple switch probe you simply connect a wire from the input on your board to one side of the probe, and run the other wire to the ground on that board. There are some basic instructions here for the Hal programming.
wiki.linuxcnc.org/cgi-bin/wiki.pl?Touch_Probe

There is not any real programming needed in Linuxcnc, it is ready to go once the Hal lines for the probe are added to your configuration. You might want to make some G-code probing routines to automate your probing process.

3) Most any probe will work. If you have access to a 3d printer you can even make your own probe like this one.
www.thingiverse.com/thing:4672365
Obviously the better the probe quality, the better your results can be.

Depends on budget, good ones are from Yaskawa and Delta, all the way down to cheap china ones that do work, but getting there might be very hard as usually they are not tested or tuned to the motor you get.
I am still skipping EtherCAT due to feedback latency issues.

Hello, good afternoon. I came across your post and wanted to ask you for some advice because I’m dealing with a very similar situation.

At the company I work for, we have an old Arburg 220-75.250 injection molding machine from the late 1980s. The floppy disk drive is no longer working, and I have been asked to find a way to get the machine back into operation.

I’ve been researching the machine, its control system and possible solutions, and from what I’ve seen so far, I’m starting to think that instead of trying to repair the original control, the better option might be to replace the control system and modernize the machine, potentially using something like LinuxCNC or another modern industrial control platform.

However, I have quite a few questions about how to approach a project like this.

First of all, how would you approach the retrofit from a technical point of view? What information would you consider essential to identify before starting?

I’m particularly unsure about the electrical side. How do you determine what the existing connections and signals are supposed to do? Is there normally an electrical schematic or I/O documentation that can be used to map the original controller’s inputs and outputs? If the original documentation is missing, how would you go about identifying and tracing the signals?

Could the existing sensors and switches on the machine be reused with a modern controller, or would they normally need to be replaced? For example, can the original position sensors, pressure sensors, limit switches, temperature sensors, etc. be connected directly to a modern I/O system, or does it depend on their signal type and voltage?

I’m also wondering about the hydraulic system. Would the original hydraulic valves and proportional valves normally be controllable by a modern system, or would these components also have to be replaced? How would you determine what type of signals the original valves require?

The same question applies to the injection and screw-position control. How would you interface a modern controller with the existing servo motors, drives, encoders or position feedback systems, if the machine has them?

Another important point is safety. How would you normally integrate the existing safety circuits, emergency stops, door switches, safety relays, etc. into a modern control system? Would you keep the original safety architecture wherever possible, or would you recommend replacing the safety system as part of the retrofit?

I’d also like to understand how you determine the required I/O. Is there a standard procedure for creating an I/O list for an old injection molding machine before designing the new control system?

Finally, if you have done a similar retrofit, I’d really appreciate any advice about the practical side of the project: what components you would keep, what you would replace, what information you would try to obtain from Arburg, and what mistakes or problems you would specifically look out for before starting.

If you don’t mind, I’d also be very interested in seeing any wiring diagrams, I/O lists, documentation, examples or photos from a similar retrofit that you could share.

Thanks a lot for your time. Any advice would be greatly appreciated.

Moved, thank you Chris.

Thank you for your detailed answers; i have ordered RS422-TTL converters to try everything out as soon as possible.

I checked the stepdir generator again in Verilog/GTKWave and tested a few edge cases.
I noticed that a pulse can be strtched if the velocity drops to 0 at the wrong moment, so I fixed that.
But that shouldn't have anything to do with your problem; it's more of a cosmetic change than a bug fix.
(in the dev branch)

can you post your json config please, i will check it.
you can also try to invert the step pulse in rio, maybe thats the problem.

Another possible cause could be that the deadband value is too high. Does the zero position drift, or does it remain stable with the same offset? How large is the deviation from the actual zero point (approximately 1, 10, 100, or 1,000 steps)?

My tests on both the ICEBreakerV1.0e and Tana Nano9k yielded the same results, not due to the FPGA brand, noise, or settings.
I noticed that the Dir PIN output returns to its original position after the step action is completed. This may be because the DIR operation is not yet complete, but the STEP operation occurs prematurely, causing an error.

No, but I can make one tomorrow.

7I92 or 7I92T?

 

Another possibility is marginal timing.

Either too narrow step pulse widths,
or insufficient setup times from DIR change to
STEP or insufficient hold times from STEP
to DIR change.

Hi, PCW
Is there available firmware, for the configuration: 7i92 + 7i76U_pktv3d.bin  ?
I need to use the modbus characteristics of 7i76U 
Thanks, in advance.

You are in the wrong topic. Probe basic is a QtPyVCP project not QtVCP.

You'll get better response there.

1. interference due to bad/not shielded/grounded cabling
2. marginal output signals for the drive optocouplers
3. Tango skipping steps, although LinuxCNC is very good at avoiding this, tango might not be, or LinuxCNC might not be aware that is happening.
Does this also happen at very low feeds/speeds?

I'm using the DM542 Microstep Driver shown in the photo, with a Tango Nano 9k FPGA. After executing a set of gcode in Linux CNC, there's an error in returning to the zero-point position. However, I can correctly return to the zero-point position using a Mesa7i92.