Advanced Search

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.

In the words of a technician for a commercial press brake control, nobody draws the bends, its a wank factor for the sales staff to add a wow factor. Everybody just creates bend lists.
Zero the axes so x0 (back gauge) is centred on the V and Y0 at the top of the V 
You need to be able to select the knife tool, the v tool, the material (eg mild steel) and the thickness. Your GUI will know the K factor for the material, then you just need a bend list with bend number, back gauge distance and bend angle with a fine adjustment angle as each sheet of  the same material may be different, Your control needs to calculate the distance to move the knife down past the top of the material to get the desired bend eg.
Y move = material_top - bend_distance (bend_angle + adjust_angle).
If its a bit out, tweak the fine adjustment angle for that bend on the first bend of the job.

If you want graphics, create a simulation of the tools, run the bend list through the sim and report any errors if something will foul etc.

I just noticed that the file I attached had a date appended 'remap_2026-07-11.py', this date needs to be removed.

So make sure you go to your 'python' folder inside your config and rename that file to 'remap.py'.

I got the Ursviken press brake I've been struggling with awhile, making basic bends finally.

Now I'm into building a reusable gui. My biggest problem doing this, is I have not spent much time operating press brakes. But I have seen a few in use. I will see what I can come up with. I want the press operator to be able to draw the profile and view and bend it. And, save and recall project files. I learned a lot by studying the press component which I think andypugh wrote.

@Brad91 I wonder if my Y1, Y2 control logic might perhaps work on a press like you describe, running two glass scales. I had a big struggle coming up with control logic that operated this, but it seems to work now. The press I'm working on has two servo valves tee'd off the pump output with no hydraulic flow divider, so whichever side went the easiest got all the flow. I finally landed on making it slow down the side that is going faster, to keep sync, that seems to work.