Advanced Search

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.

NWE wrote:

For slow cheap I/O I used to not like modbus, but tried it some more recently and am pleased how it is performing. This would not do for limit or homing switches, for those you'll want ethercat or Mesa for sure.
 

Thats interesting. I never thought of this either. If you look at this diagram in the docs. it clearly shows what can be run in non-real time mode
linuxcnc.org/docs/stable/html/code/code-...rchitecture_overview

So spindle, coolant and auxillary devices could be modbus and I can see modbus I/O modules locally for < AUD $50 for 16 inputs and 16 outputs. I'm might also play with some now there is good modbus support in hal
 

saxa wrote:

Can you share more details on what are you looking for to use for the retrofit ?
 

I have not yet started shopping for servos for my machine, but I plan to use ethercat servo drives. I'm thinking likely Stepperonline or Lichuan or Delta brand. For I/O I expect to use Mesa or Beckhoff EK1100 with EL1809 and EL2409. I've used both in multiple projects without any problems that I can remember.
If connecting multiple encoders I nearly always use Mesa because Beckhoff encoder counters are so much more expensive.

For slow cheap I/O I used to not like modbus, but tried it some more recently and am pleased how it is performing. This would not do for limit or homing switches, for those you'll want ethercat or Mesa for sure.

Not quite the same but I did a component that had 2 belts and several positions except it was manual selection. It may help
belts 1-4 one group, 5-8 another.
I used a laser tachometer to read the rpm and then calculate the ratios 
github.com/rodw-au/vmnmillqt/blob/main/scalebelts.comp

I did a GUI to go with this for QTdragon and its now part of QTdragon! Look for it in the docs.