Advanced Search

Unlike sserial pins, you can only "setp"  sserial parameters (like the source and sink masks) in LinuxCNCs hal file,
they cannot be  changed dynamically. This is true of all sserial parameters, that is, they are only updated on driver startup.

The output modes are something typically set to match the interfaced hardware, so do not need to be changed dynamically.

 

Installed the latter. So far so good, didnt do any major tests but multiple power cycles. Also, with the ClockSyncCycles set to 5 and syncToRefClock=true, my servos are now instantly OP. no waiting for them to be ready which caused some amplifier errors when i was too quick with the power button recently.

no idea if thats because of the new linuxcnc-ethercat version or because of those parameters.

one thing to note though, the dc-phased pin never went high for me.

Hallo zusammen,

hatte jemand von euch schon mal dieses Problem?

Ich bin noch recht neu im CNC-Bereich und kenne LinuxCNC (MiniMill 2.9) noch nicht so lange. Ich brauchte eine Aufwärmroutine für meine Maschine und habe daher mithilfe von AI eine Datei generiert.
Ich habe den Code in meinen Windows-Editor importiert und die Datei als <Name>.ngc gespeichert.
Ich hatte zuvor selbst kürzere G-Code-Dateien geschrieben, gespeichert, auf die Maschine übertragen und geöffnet: Sie funktionierten sofort.

Als ich jedoch versuchte, den G-Code mit den von AI generierten Teilen zu öffnen, waren die Zeichen im Code völlig verstümmelt – der gesamte Code war unlesbar!

Als ich die Datei mit dem „gedit“-Editor unter Linux öffnete, sah alles einwandfrei aus.

Hat jemand Ideen, Tipps oder Lösungen?

Viele Grüße

Freddie

Gotcha. i will try to get this (github.com/linuxcnc-ethercat/linuxcnc-et...84ef36b53f0b734eaedf) installed first, with syncToRefClock=true and ClockSyncCycles set to 5 to see if my jitter issues go away. they are very random as of right now.

Or should i use this patch with the settings above?
github.com/grandixximo/linuxcnc-ethercat
 

Perfect, thanks

thank you,

I have custom PyVCP on right side of Axis. Will I need rewrite this panel is the case I will move to QtVCP or gmoccary?

Yes you can use just one output

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.