Advanced Search

Hello all, I am trying to configure `output_sink` and `output_source` pins for my Mesa 7i76eu and I am running into some surprising behavior. My goal is to put `hm2_7i76e.0.7i76.0.0.output-11` into sink mode. 

Long story short, putting `setp hm2_7i76e.0.7i76.0.0.output_source 0x0000F7FF` and `setp hm2_7i76e.0.7i76.0.0.output_sink   0x00000800` in my HAL file after loading `hm2_eth` does not seem to have any effect, output-11 remains in sourcing mode. I spent some time debugging this and found some surprising results.

The first thing I did was attempt to setup the pins manually without changing anything in my HAL file. For this test, my HAL file did not set `output_sink` or `output_source` at all. On a fresh power cycle of both my computer and the mesa card, the following works correctly (causes output-11 to sink when TRUE).

```
halcmd setp hm2_7i76e.0.7i76.0.0.output_source 0x0000F7FF
halcmd setp hm2_7i76e.0.7i76.0.0.output_sink   0x00000800
halcmd setp hm2_7i76e.0.7i76.0.0.output-11     TRUE
```

I can toggle output-11 back and forth between TRUE and FALSE and it appears to work just fine. The strange part is that if I set output_source = 0x0000FFFF output_sink   = 0x00000000 (going back to the default value), `output-11` remains in sinking mode, it does not switch back to sourcing mode. The only way I can get it to switch back is if I power cycle the Mesa card.

The second thing I tried was setting `hm2_7i76e.0.7i76.0.0.output_source 0x0000F7FF` and `setp hm2_7i76e.0.7i76.0.0.output_sink   0x00000800` as part of my postgui HAL, the thinking being that maybe there is some timing issue for when you configure the output pin modes. This does seem to work as long as I do a power cycle of the Mesa card and computer, but it feels like a bit of a hack.

I'm using this setup to control activation of a wireless probe receiver which needs `output-11` to sink to ground in order to activate the probe, so my main worry is that I'm just hiding a timing related issue by doing this in postgui and will end up running into a crash down the line. If anyone has some insight into how `output_source` and `output_sink` are supposed to work, that would be appreciated!

Thanks!

neat. this is the current state of the robot. xyz (and call be point to point one axis at a time). a drawbar (air) and a pivot for the arm (air?) and the door opener (air?).

grr. how do i NOT embed the video? its stripping out the time index. 2:41.

tivoi wrote:

helo, give me your contact. 

regards

join the discord
discord.gg/PRkQbQ2wmZ

Hi!Will upload! but photos not very good ! so hard to extract from case box.

helo, give me your contact. 

regards

Please see attached file

Can i just use one Mesa output for all three driver or do i have to use three outputs? One for each driver. In the LinuxCNC configuration i can set enable for x, y and z axis.

Tried that same results as with rufus

Thanks for the response — this is helpful context.

I understand retrofit is a valid path and the point about ending up with a tank-built machine is well taken. My hesitation is mainly about the time investment: I'd rather spend that energy on the application layer (custom probe-driven post-processing workflow) than on commissioning the machine itself.

That said, I'm open to both paths if the retrofit is well-documented for a specific platform.

So to refine my question:

1. For **new machines**: I've been told some smaller European builders sell gantry routers either pre-configured with LinuxCNC or as bare mechanics without a controller. Can anyone confirm this and point to specific manufacturers with real-world experience?

2. For **retrofit**: which specific platforms (Biesse, SCM, other) have the best-documented LinuxCNC retrofit in this community? Ideally something where ATC and vacuum zone management via MESA I/O are already solved problems with existing examples.

I’ll switch to your PR and test it on my hardware the next time I’m working with my mill.

How would Rufus be the problem? If the liveCD version runs, then the ISO has been written properly, and it's easy enough to run the verification check before using it as bootable media.

Hi Eugenius,

As far as I know with AXIS (the default LinuxCNC GUI) those things aren’t easily configurable from settings.

Bigger axis jog buttons: AXIS uses a Tk/Tcl interface, so the button sizes are basically defined in the GUI script. If you want them bigger you would need to edit the AXIS UI files (usually in something like linuxcnc/share/axis/). It’s possible, but it means modifying the Tk layout manually.

Secondary spindle control: AXIS is quite limited for multi-spindle setups. You can control additional spindles through HAL and M-codes, but the GUI usually won’t show extra spindle controls unless you customize the interface.

If you need more flexible controls, many people switch to QtVCP or gmoccapy, which are easier to customize than AXIS.

So yes, it’s possible, but it usually means editing the AXIS UI scripts or moving to a different GUI in wheelie life .

elisilva wrote:

I trying ramake PCB of the BCL-AMP Friendess Preamplifier,

That sounds interesting! Can you share photos of the PCB?

Sorted, cheers.

And the PC MUST be set to 10.10.10.nnn where nnn is anything from 1 to 254 but NOT 10.
So yes, the PC set at 10.10.10.11 will work.

Hi all,
I am a newbie to cnc and to linux so please be patient with me. I have seen some posts where using the 7i76eu board can be set to using ip address of 10.10.10.10 I see some guys say changing w2 and w3 manual says w13 and w14 default is 192.168.1.121 with both down. and both up 192.168.1.121+ use fallback configuration. Some guys say w3 and w3 off to set ip to 10.10.10.10. I am confused many say i should be using 10.10.10.10 and hve pc to 10.10.10.11. Does the 7i76eu magically change the ip with w13 and w14 in the default down and the w2 and w3 in down position, or do you have to do something else in progaming also.
This my seem stupid to some of you more experienced users but I am confused!
Thanks for any help