Advanced Search

There is a qt version of vismach in 2.9+. In theory you should be able to add it into any qt5 based screen.
I don't know much about qtpyvcp, maybe asked their devs if it's possible, or maybe they can port a version specifically for their screen.

linuxcnc.org/docs/stable/html/gui/qtvcp-vismach.html

Question about  Connect Mesa 6i25 HDR26 with 7I52S HDR50 moved to
forum.linuxcnc.org/49-basic-configuratio...h-7i52s-hdr50#333411

tommylight wrote:

Drive alarms should be wired to joint.n.amp-fault in hal, not to e-stop,

Yes as I said. Much cleaner to maintain

Todd wrote:

What was the doc pertaining to? Maybe the information can be found elsewhere?
 

Its really the only complete guide to installing and optimising Debian Trixie to get a reliable machine with Mesa cards and ethercat.
Because we never had an ISO for Bullseye, nobody had any idea of the kernel changes that impacted on reliable machine operation from about kernel 5.10 and on until Bookworm came along. I did get this into the getting linuxcnc docs but it was discarded with the release of 2.9 by people who had no idea. I'm not redoing it. When I looked at how I could host the info today, making it a downloadable ptoduct on my home network seemed to be the best option. But there is a cost. Feel free to gather the info and make your own version and or add it to linuxcnc docs (which don't cover Trixie). Somebody offered to donate USD $300 for this info so it has value to some people. Surely $1.30 USD is not to much to ask me and almost half will go in fees.

Drive alarms should be wired to joint.n.amp-fault in hal, not to e-stop,

You can use logic components such as and2 to connect multiple signals to one. But I'm not sure I see the advantage of doing so with an e-stop. Generally an e-stop loop is all in hardware, and the e-stop input to Linuxcnc is merely to inform it of the loop's state.

I could use this PDF manual too - if it even exists, of course.

What was the doc pertaining to? Maybe the information can be found elsewhere?

Linuxcnc allows you to create a Python filter that processes the Gcode when the file is opened, Not sure how qtplasmac does it.

Yes, sorry its gone. I'm working on a similar document for Trixie. Its still a draft but its here
erpx.au/shop/trixie-linuxcnc-debian-trix...tion-pdf-download-48
There is a small charge for it AUD $2 to cover costs. That really only covers the payment processing costs. I will send final versions once its complete to anybody that buys it while its in draft.
Its hot off the presses as I just wrote it today. Any feedback will be appreciated.

i have an Old Abb irb2000 thats just sitting there, that i want to revieve.
it seems that this could be a way forward.
What kind of setup are you using for the rest of the control chain ?

estop-latch is the right way to go  with these but a better way is to use joint.N.amp-fault-in IN BIT   Should be driven TRUE if an external fault is detected with the amplifier for this joint.
ref: linuxcnc.org/docs/stable/html/man/man9/motion.9.html
This will halt motion.
Your drives may also have a estop input which disables the drive on an estop.

Perhaps the information in this post would be helpful for you.
forum.linuxcnc.org/qtpyvcp/44047-where-a...bounds-stored#224522

There's a couple of ways, you could use the Mesa Configuration Tool or you can add the estop_latch component yourself.

JT

I'm not with the machine right now, so cannot run any tests (perhaps later today) but looking at the various hal state dumps I posted previously, spindle-at-speed seems to be showing false all the time, whether the next move works or not.
It does look like I need to check spindle-at-speed, but it doesn't seem like it is the deciding variable (at least not on its own)