Advanced Search

A picture or part number of the motor drives would help
determine what interface hardware was needed.

I checked the folder name again today; it was correct—without a date. I also have the latest Python3 version, 3.13.5-1. The error persists.

I am decently new to the building of CNC's. I successfully built a smaller 4x4 machine that I also had to retrofit, but that's for another time.

With this, I just picked up a Precix CNC machine from a local sign shop. I came across a forum that did something similar to what I am after, but mainly looking for more input on the wiring and new retro components. I will need. I have a photo showing the overall machine when I moved it (about a week ago from this post). With that, I started taking photos and removing the components I knew I needed replaced. Those would mainly be just the computer and components they had in there for the computer (motherboard of the PC, RAM, and various input items such as VGA plug-ins). All other components, such as the amplifier, power supplies, relays, and motion cards, are all still in the computer box if you will. 

I have various photos of the internals as well as the spindle and axis motors. I can share those once I get them uploaded.

With that, I have heard of the Mesa cards working with the DC servo motors and amplifier my machine has. Looking into pinouts, wiring diagrams and other items I may need to complete this. I have a spare PC I will be using LinuxCNC on to power it and bring it to the modern world. 

Any help to work through this would be greatly appreciated!

rodw wrote:

Linux-CNC is the Ethercat master. You just need ethercat slaves. Have a look at the Beckhoff EK1100 and the many various modules that attach to it. Many of these modules have native support in LinuxCNC. There may be other brands of modules available but you would need to write the driver and you'd need to be sure they have 500v or so over voltage protection in case something goes wrong. Beckhoff and Mesa have that.

I took a look at the EK1100 and various modules, thanks. I also checked the Isolation of TrioMotion FlexiSlice coupler P366 and they state it as 1 kV. So this should be ok.

tommylight wrote:

Yes you should leave them out, as noted above the only usable way for DMM drives is in Position mode as they have a delay in position signal outputs.
Also the encoder input will be used for THCAD if you want plasma.

By "leave them out" I meant to not connect them at all. But then how the linuxcnc will know where it is at certain point ? I will probably loose a part of precision with not connecting the encoders feedback.

tommylight wrote:

Yes there is, Mesa 7i85 or 7i85S should have 4 encoder inputs.

I see this card has a DB25 connector to connect it to the computer I suppose, or does it gets connected to the
7i96s ? Sorry for dumb questions.
Is the DMM Dyn4 encoder output supported by the Mesa 7i85 ?

tommylight wrote:

No, not per se, but LinuxCNC can be programmed as you need it, so a simple G04 P1800 will make the machine wait for 30 minutes at the first cut to preheat the material.
Same for outputs and solenoids, everything can be automated and even add a side panel with settings and buttons and stuff.

OK for this, I will take a look better on it once I install it in a virtual machine.

This version makes a log file in the /tmp directory (which gets erased upon reboot). Note the logfile entries look somewhat like g-code linear move with line length and tilt appended to its end.  the line origin and endpoint are listed for each line in the figure. Copy just the g-code entry into the system clipboard (after displaying or editing the log file in a linux window). Mouseover the MDI execution rectangle and  depress cntrl shift and h keys together, the clipboard will be deposited into the MDI history window just above. The g-code can be executed by mouseing it into the execution rectangle and then mousing its go box. This let you re-visit any line in the figure (perhaps to check for interference problems, I use this method to measure saw tooth rake angle) Edit the ngc file to make a logfile in another directory or for another part.   (  Manually select the layer you wish to view in MDI by setting depth)
portion of log file:
g1 f 100.000000 z -0.120000
 g0 x 2.000000 y 1.000000 len:0.521875 8.000000
 g1 f 100.000000 x 2.516796 y 1.072631 len:0.521875 8.000000
 g0 x 2.516796 y 1.072631 len:1.939508 105.731904
 g1 f 100.000000 x 1.990925 y 2.939487 len:1.939508 105.731904
 g0 x 1.990925 y 2.939487 len: 1.939508 270.268096 ....

Wer von Euch hat Infos zu ner neueren Version als die aktuelle von Stepperonline, die wirft bei mir bei manchen Sachen Fehler aus,allerdings mit chinesischer Schrift 
Autotuning ergibt bei mir keine Ergebnisse ,da steht schon beim Inertia Identifikation nur eine Null nach dem Testlauf 

I use the auto tool probe remap and it's very simple. I measure the distance of my tool setter from the machine bed, then put that value in for probe HT in the probe tab. Next I measure the distance of the stock top from the machine bed and put that value in for my g5x z offset. block HT is left at 0 no matter what, don't touch it. Now what happens when the auto tool probe remap runs is when you start your g-code, it brings spindle over to a defined change position, you change the tool manually to the one it's asking for, then it drives over to the tool setter location and creates a tool length offset. After it's done, your tool will be offset perfectly to where you programmed your wcs z0 in cam. I can explain more details about what's going on and why it's done like this if you want, but you're referencing everything off the machine bed which is absolute. Even if your on a router style machine and resurface your spoilboard, you just re-measure the probe HT value and you're back in action.

Final update: fully resolved. Turned out to be two separate issues layered on top of each other — the weak 5V supply (confirmed earlier), plus a ribbon cable causing intermittent SmartSerial comms errors (Timeout/Extra character/Serial Break, escalating to port shutdown after ~6 minutes of runtime). Replaced the ribbon cable with a direct DB25-to-DB25 connection between the 7I92 and 7I76 (board mounted directly on the 7I92's P2 socket) — 30+ minutes stable, zero faults. E-stop wired to TB6-1/input-00 and confirmed working through PathPilot's UI.

It's worth noting, the ribbon cable fault was probably the proximity of a switching power supply nearby with everything laying on a table.

Thanks again to all for the help throughout.

Hey Rod,
Beyond the YT link, where can I find a bit more info on MTconnect? Not sure if what I'm finding in google is the best resource.

I found the info I was looking for. Given how general a controller LinuxCNC is, it looks like every class of machine (router, mill, lathe, arm, etc) would need its own MTConnect Adapter type but you could probably generalize the agent.

Cheers

If you want to try it, I can give you the files to turn it on later tonight after work.

Confirmed — the weak 5V supply was the entire problem. With a proper 5V/7A supply in place, the exact same x2D bitfile that failed with EAGAIN yesterday now registers cleanly and shows full SSerial field I/O (input-00 through input-31, output-00 through output-15, spindle pins, all live). Thanks again for pointing at power — solved it completely.

Found it — the 5V logic supply was sagging to ~4.08V under load (was running off a 2A phone charger feeding both the 7I92 and 7I76 through the cable). Swapped to a proper 5V/7A supply, and GPIO pins now show a clean, full swing (5.09V/0V) where they were previously stuck flat regardless of software commands.Credit to tommylight and PCW — you both flagged marginal 5V power as a suspect early on, and that's exactly what this turned out to be.

Going to retest the SSerial/x2D setup with solid power now — will report back on whether that resolves the EAGAIN registration failure too.

Thanks both for the help.

You guys rock!

I wrote about Modbus, because Ethercat I/O is expensive.
Configuration Mesa+Ethercat is more expensive and you need two network ports (some mini computers are enough powerfull but you can't add any cards).
Modbus need only USB port.
You can find cheap Modbus I/O cards on Aliexpress (for example 4 analog and 4 digital inputs less than 10 US dollars).
Of course Modbus is slow so suitable for slow signals.

so, its now narrowed down to a random spike in lcec readalltime and writealltime

BUT, curiously the individual slave read/write-alltime pins show no spikes. so something outside is randomly hogging time which when it exceeds 1ms or so, tops the drive (sometimes its less, sometimes it can go more and not trip)

The leadshines don't seem to mind. the omrons are not tolerant unless i push sync0shift waaay up. its at 750k now and has not errored in an hour or more. at 100k it errors many times per second. at 300 then 500k it reduce, but it can still error several times in a few minutes.

Coupled with my filter on the encoder values, it seems basically "worked around" for now. even with the filter I was getting occasional joint errors when time spikes hit 1ms or more.

We did also remove things from sharing irqs. I'm not sure that did anything. Thats the trouble with random errors... they are so random.