MESA files attached for previous message

I hope this is not a double post - tried earlier, reported only 8 files attached so I cancelled, will try here and then follow with the other files


Below tells what I have and have done - what I could use some help with.What I am trying to do is simply hook the 7i92T to my mx3660 without moving anything - just wish to replace my parallel port with the MESA, so keep all my parallel stuff - limits and other as is just need to get the 7i92T to be the faux parallel port and work in LinuxCNC.

1. Had a working 2.9.8 with an MX3660 controlling steppers VIA parallel port
2. Have new install of LinuxCNC 2.9.8, a MESA 7i92tm with P2 being a parallel DB25.
3. I did learn that the 7i92tm and 7i92T are both named in configs as 7i92T with no M or other.
4. Have everything wired, network works, network can see the MESA and a parallel cable out of P2 on the card to my MX3660.
5. Finally flashed the 7i92 with the bin file:  7i92t_mx3660d.bin
6. 7i92 reported successful flash.
7. Shut everything down and rebooted all.
8. The 7i92 gets red and green lights then the red goes out and the green is on like I understand it should be.
9. Proceeded to Pncconfig figuring this will be easy.
10. When I go into pncconfig I do not see in the "hardware" select able anything like "mx3660" but I do see such as "7i92 internal" and "Geckoxxxxxx" [x where I do not remember] and so on, tried several. Wondering if the flash did not give me the mx3660 - thought it would just show up as mx3660d in the list.
11. Also, after reading the manual, the forum search, everything including youtube videos the pages do not look like the ones in those shown. I can get to the card setup and after accepting the changes - including 10.10.10.10 for the card I do get the P1 and P2 pages for the card.Anyway, stumped. Tried several manual configs of the card, tried setting the X axis and testing - when I actually do "test axis" for calibrate the red light on the 7i92 lights. I have to power cycle to get it off, as soon as I test the axis it red lights. So I am attaching what I see others have - the output of the card from a terminal, along with my old ini and hal files - whatever may be of use. Please note the name of my ini and hal files reference 2.8.4 but that's just the names I gave the last working configs I did update but left the bookworm file name in the configs.I appreciate anything to get on track I can get. FYI - the 7i92 is connected to the MX3660, what I really could use is what the pins or setup should be. Why I went to the 7i95 is to offload some from the computer port since I would get occasional errors if trying to run faster than 180ipm. I do not mind 180ipm it's just that the computer port appeared to choke on the data stream once in a while.If I can get this to work I intend to write it all up and post it for others as a complete - including that the bin file needs to be in the home usr directory to flash. Instructions were to put the file in the same directory as "mesaflash" but that isn't true, unless I am seriously missing something and I may be.Thanks
    
    

    File Attachment:

    File Name: 2-8v4-Book...2-16.hal
    File Size:3.96 KB

    File Attachment:

    File Name: 2-8v4-Book...2-16.ini
    File Size:4.72 KB

    File Attachment:

    File Name: custom_2026-02-16.hal
    File Size:429 B

Yes, the output stops for some 10 seconds after operating the pendant (I think any action, not only the wheel). If you press a button during that time, it still comes through. But the regular updates resumes only after about 10 seconds.

At first I thought this 10 second delay was because I somehow polled the dongle in a wrong way. But I later tried it with the Mach3 driver, and found it to exhibit the same behavior. So I would say this is again pointing to not so high quality dongle firmware.

The idea was the program was partly to investigate the issue, partly to maybe create a new driver for LinuxCNC. Like I have mentioned, I'm not fully happy with xhc-whb04b-6 component functionality nor with how its coded (too many layers of abstraction for my liking/understanding). And the "blocking calls" are basically a fundamental issue with it. But don't get me wrong. I do appreciate and praise all the work done by the guys/gals who has made and updated the component. Evidently it works fine in many situations, just not (all the time) for me.

I was just thinking that I was able to work with the pendant for hours, despite disconnects.
You are of course right, it's not correct. The component seems to try to adapt to the situation
and succeeds to 99.5%.

Tried your code. Had to replace libusb_init_context with libusb_init, after that it ran.
You have some skills there for sure.
Yeah, it kept the pendant busy. There were no disconnects while running.
The polling stopped, or maybe the output stopped, for some ten seconds
after turning the wheel, then it started again. I guess that was intentional.

What's your idea with the code? Just for test or should it replace the usb code
in the whb04b component or ?

I should be able to downgrade my usb to usb 2.0 on wednesday.

 

Here are a few photos of my pendant that I took in the summer. Sorry, but I do not currently have any photos with the cards inside the housing. And just for info... I tried to read out the firmware from the STM32, but unfortunately it is read-out protected.
 
 
 
 

Attached is the "test driver" I made, which repeatedly polls the pendant and displays the data received. It can also update the display if you uncomment the last line in usb_interrupt_callback(). Just unzip the file into a folder and running from the terminal you should get something like: You need to have libusb-1.0-0-dev installed for this to compile it. But if you already compiled LinuxCNC from source, I think you should already have it.

And regarding repeated disconnects... It may be normal behavior in as far as that is what happens. But it is for sure not correct behavior.

I would also prefer a wired pendant over this wireless one. But when I bought it this seemed like the best option for me for a relatively low cost. And I do not think that the issues we see are caused by the RF link failing.

I'm using the hardwired version for years without any problems - no disconnects.
Can you open your pendant and take some photos of the PCBs so I can compare it with mine?

To clear an "amplifier fault" (drive error) I can do it using the halshow and then via cia402.0.fault-reset but I read somewhere that the fault should also be cleareable when clicking the enable/power on button. It works but only sometimes if I keep pressing the button it will clear the error and the time after that allow to power on. Should the enable button clear the error reliably? Maybe there is something wrong with my setup. Probably latency issues as I'm using a RPI4...

Also, with ethercat there is no way to use the UI emergency button, correct?

You're missing a G40. 

First run the installdeps script.

Then run:
This all works fine.

However, when I try to run gmake or remake (which is apparently just gmake with better debug output), it fails with an error partway.

Does anyone know why?

Does anyone know how to fix it and get it to compile?

Hello,
i need some buttons in Probe basic which activates outputs from my Mesa 7i76e. The attached photo show what i need. 
I found /user_buttons/template_user_buttons/template_user_buttons.ui (attached). Would that a nice place add the buttons. But so far i don´t know how to start the ui ind Probe Basic GUI.

Best regards
 

Hi all,
At 19:55 in this video...

 

I was making a set of lathe tool height adjusters, and used a loop with G55 to repeat my tool paths along a piece of stock. This worked great for engraving and drilling such as this code...
o100 Sub
 G0 X0 Y0
 G0 Z5
 G01 Z-2 F100
 G01 Y-14.5 F1000
 G01 X10.5 Y-20 
 G01 X21
 G01 X30 Y-14.5
 G01 Y0
 G01 X0
 G0 Z50
o100 endsub

#50 = 0
G17 G21 G54 G90
; OP 1 engraver outline
M6 T16 G43; Drag engraver

o110 while [#50 LE 5]
    G10 L2 P2 X[#5221]  Y[#5222 -23* #50] Z[#5223]
    G55
    o100 call
    #50 = [#50 + 1]
o110 endwhile
M2

However, my last tool path was a 10mm endmill to cut the contour, and I just reused the engraved path and added G42 to cutter comp it. This errored out with Linuxcnc throwing this message.
 

Here is the code...
o100 Sub
 G0 X-10 Y0
 G0 Z5
 G01 Z-2.5 F100
 G01 X0 Y0
 G01 Y-14.5 F1000
 G01 X10.5 Y-20 
 G01 X21
 G01 X30 Y-14.5
 G01 Y0
 G01 X0
  G01 Z-5.5 F100
 G01 X0 Y0
 G01 Y-14.5 F1000
 G01 X10.5 Y-20 
 G01 X21
 G01 X30 Y-14.5
 G01 Y0
 G01 X0
  G01 Z-7.75 F100
 G01 X0 Y0
 G01 Y-14.5 F1000
 G01 X10.5 Y-20 
 G01 X21
 G01 X30 Y-14.5
 G01 Y0
 G01 X0
  G01 Z-10.5 F100
 G01 X0 Y0
 G01 Y-14.5 F1000
 G01 X10.5 Y-20 
 G01 X21
 G01 X30 Y-14.5
 G01 Y0
 G01 X0
 G0 Z50
o100 endsub

G17 G21 G40 G54 G90
M6 T10 G43; 10mm end mill
G42
G0 X-10 Y0
G0 Z50
M1
S3000 M3
G4 P4
#50 = 0
o110 while [#50 LE 5]
    G10 L2 P2 X[#5221]  Y[#5222 -23* #50] Z[#5223]
    G55
    o100 call
    #50 = [#50 + 1]
o110 endwhile
M5 M9 G40
M2

Is this just a simple error on my side? I didn't find anything in the reference doc's on cutter comp and work offsets not working together.
Cheers,
Mark
 

It could be the radio version that have the crash issues I guess.

MRx, you don't see these disconnects/reconnects for your wired pendant?

MRx wrote:

I only have the wired versions of it (3 of them) and they are solid.

A hard wired pendant with no USB is only $30 to $50

I only have the wired versions of it (3 of them) and they are solid.