Advanced Search

I suppose I hit some different circumstances since I'm trying to do something with a touchscreen rather than something like Axis, couple of things I ran across.....

I don't even bother adding a MenuBar, but I would like to use a pushbutton to open halshow, etc....Any way to do that?

I also noticed there's no good binary indicators in qt5's standard set of widgets, like LEDs or even a button that changes appearance on input. The only thing I've found is hal labels, but even then I think they are only actually good for displaying numeric values. If set to "bit" type input, they just display true or false. I don't see any way to make a text string appear or disappear at least. Looking for something that can just indicate a fault.

If something like this is already there just point it out, I'm good at missing things.

Sure, I have many of them.......but that's not the point.

There are very few "open-source" things that actually wind up being cheaper than the cheaper thing it's replacing.....but I can't run a DMM off of Smart Serial. The 2 options on a standard drive are (not really) RS232, step+direction, and analog.....but the analog input has issues on these.  Modbus/rs485 is a custom drive.

There you go: github.com/jstjst
But after looking at the prices for the DMM servo drives, I think they are in the same price range (if not cheaper) then a stmbl

Yeah, a shorted analog output is going to drag the (relatively weak) local
power supply down.

If you did not cause more extensive damage, you (or someone local with the right equipment)
should be able to replace the ISL32174 that's fried...

You can look at the associated GPIO pin:

IO Connections for TB1/TB2 -> 7I96_1
Pin#                  I/O   Pri. func    Sec. func        Chan     Sec. Pin func   Sec. Pin Dir

TB1-2,3                17   IOPort       StepGen          0        Step/Table1     (Out)
TB1-4,5                18   IOPort       StepGen          0        Dir/Table2      (Out)
TB1-8,9                19   IOPort       StepGen          1        Step/Table1     (Out)
TB1-10,11              20   IOPort       StepGen          1        Dir/Table2      (Out)
TB1-14,15              21   IOPort       StepGen          2        Step/Table1     (Out)
TB1-16,17              22   IOPort       StepGen          2        Dir/Table2      (Out)
TB1-20,21              23   IOPort       StepGen          3        Step/Table1     (Out)
TB1-22,23              24   IOPort       StepGen          3        Dir/Table2      (Out)
TB2-2,3                25   IOPort       StepGen          4        Step/Table1     (Out)
TB2-4,5                26   IOPort       StepGen          4        Dir/Table2      (Out)
TB2-7,8                27   IOPort       QCount           0        Quad-A          (In)
TB2-10,11              28   IOPort       QCount           0        Quad-B          (In)
TB2-13,14              29   IOPort       QCount           0        Quad-IDX        (In)
TB2-16,17              30   IOPort       SSerial          0        RXData0         (In)
TB2-18,19              31   IOPort       SSerial          0        TXData0         (Out)
Internal-TXEn          32   IOPort       SSerial          0        TXEn0           (Out)
Internal               33   IOPort       SSR              0        AC Ref          (Out)


So GPIO 20 for stepgen 1's direction pin

This should now be fixed:
github.com/LinuxCNC/linuxcnc/commit/5928...ae29d5ddb741c6456856

Although if you are using Bookworm and relying on buildbot2 then you will need to wait until it begins build again, the latest there is 24 Oct.
buildbot2.highlab.com/debian/dists/bookw...inary-amd64/?C=M;O=D
 

Zeroed machine and did part zero.  Started program and saw that my x was off before tool reached the part.  (path is a ramp around the part so I could see the part outline before the tool started cutting.  Stopped the program and adjusted x part zero.  Now the program gives immediate error even if I reset x zero to original location.  The travel display shows the previous moves even when I reload the file.  It seems like LinuxCNC still has the movement captured somehow.  I could shut it all down and start over but would rather not zero the machine and relocate the part.  Is there a way to clear this without loosing my positioning?  The display shows Axis 2.7.4.  Maybe a newer version has fixed this if it's a bug?
 
 

I just accidentally swapped the 24v output port on one of my RTelligent Drivers for the drive-stepper input ports and blew up at least one of the 6 stepper outputs (likely two) on my 7i95T.

Once I get past suicidal thoughts I will shift all my joints over to check the possibly that I may have only blown two step-gens. Each pair of two step-gens share the IC that smoked so I'm betting 0 and 1 are gone but if 2-5 are still viable I might be able to limp along and continue to make some progress on the router which is XYYZ configuration.

Ironically, I was just going back through all the wiring straightening it all out and zip-tying everything. I just happened to swap two identically looking plugs and poof 'magic smoke'.

Bit of trivia... the digital aspects of the 7i95 seem to have remain unharmed. Led's report no errors on start and LinuxCNC connects right up and thinks nothings wrong.

Worse than the cost, it took me six weeks to get that board from Mesa, so I Guess I had better order a new one before Trump's Tariff plans kick in.

Email isn't in your profile, didn't see it in your github bio either

D'oh!  Figured it out.  In case anyone else is as slow as I am...

In the ini file, my comm "MDI_COMMAND=0 <z_touch> CALL" was the 15th item in the HALUI list (starting with 0).  So my custom_postgui.hal file should have been:
net ztouch halui.mdi-command-15 <= pyvcp.ztouch

All good now.  Just need to measure offsets and we're running!