Advanced Search

LinuxCNC 2.9.6 has been released.

This is a bug-fix release. Shortly after the release of 2.9.5 it was
noticed that a fix for a graphics bug in Gmoccapy had resulted in the
Axis touch-off dialog box no-longer working for non-zero entries.

This update is for all users, but especially users of the Axis GUI.

Packages for 2.9-uspace for amd64 (PC) for Debian Buster, Bullseye,
Bookworm and Trixie and for arm64 (Raspberry Pi 4/5) for Buster and
Bookworm have been added to the linuxcnc repository. If you installed
from one of our live images or Pi SD-card images then the update
should be available immediately.

If you installed into a normally-installed Debian from the Debian
repositories then hopefully the new version can be queued up for the
next point release. If you can’t wait then it is possible to add the
LinuxCNC repositories to the apt sources. One way to do this and
install the security keys is via the shell script here:
linuxcnc.org/docs/stable/html/getting-st...th_preempt_rt_kernel

At the moment the live-image installer and SD card images will install
2.9.4 but update should be trivial (and possibly automatic)

RTAI is still supported, but in the short term building from source is
likely to be the most expedient way to get 2.9.6 on that platform.

Changelog

qtvcp -Qt5_graphics: issue 2753; preview wrongly uses INI startup code
Merge pull request #3567 from Sigma1912/2_9-Correct_bad_fix_for_2753
Gremlin: Don’t use RS274NGC_STARTUP_CODE when updating the preview
Docs: Address G52 Circular Link #3565

Acknowledgements

As always, we couldn’t do this without the contributions from the
community, so many thanks to:

CMorley
Sigma1912

 

Hello Spumco, no worries, I just wanted to know where you were with the C axis.

I launched linuxcnc, "ethercat slaves" are in OP state, everything seems correct in the XML configuration, what could be the problem?

0  0:0  OP  +  2DM880-EC
1  0:1  OP  +  2DM880-EC
2  0:2  OP  +  2DM880-EC
3  0:3  OP  +  2DM556-EC
4  0:4  OP  +  2DM556-EC
5  0:5  OP  +  DIEWU EtherCAT-IO (Digital 16-Input/16-Output)

When running the configuration, such errors occur:

Debug file information:
Note: Using POSIX realtime

HAL: ERROR: duplicate thread name servo-thread
THREADS: ERROR: could not create thread 'servo-thread'
threads: rtapi_app_main: Operation not permitted (-1)
./Sodick.hal:20: waitpid failed /usr/bin/rtapi_app threads
./Sodick.hal:20: /usr/bin/rtapi_app exited without becoming ready
./Sodick.hal:20: insmod for threads failed, returned -1
shutdown.hal:4: parameter or pin 'lcec.0.0.enable' not found
3184
Stopping realtime threads
Unloading hal componentsNote: Using POSIX realtime

I tried to fix the access error:

groups
sodick lp dialout cdrom sudo audio video plugdev users ethercat linuxcnc ecusers realtime

And all lcec files installed from linuxcnc:

/usr/bin/lcec_configgen
/usr/bin/lcec_conf
/usr/lib/linuxcnc/modules/lcec.so
/etc/linuxcnc/lcec.conf
/usr/lib/linuxcnc/modules/lcec.so

Hal file:

# Загрузка EtherCAT компонента
loadusr -W lcec_conf /home/sodick/linuxcnc/configs/Sodick/ethercat-conf.xml
loadrt lcec

# Загрузка дополнительных HAL компонентов
loadrt siggen
loadrt or2
loadrt and2
loadrt not

# Создание thread с уникальным именем
loadrt threads name1=servo-thread period1=1000000 fp1=0

# Добавление функций в поток (правильный порядок)
addf motion-command-handler servo-thread  
addf motion-controller servo-thread
addf lcec.0.read servo-thread
addf lcec.read-all servo-thread
addf lcec.write-all servo-thread
addf lcec.0.write servo-thread

Hello again everyone,First, I apologize for the late reply — I’ve been working on revising my plan and wiring, and it took longer than expected.I’ve updated my wiring/architecture plan (see attached diagram), and here’s where I’m at:

• Mesa 7i92 over Ethernet
• Two 5-axis breakout boards (5ABOB ×2)
• DM556 drivers for NEMA34 motors (3.5 Nm, 3 A/phase)
• THC Proma 150 for torche height control (Arc OK, Up, Down signals)
• Relays for torch, laser, pump, etc.
• E-stop, limits, probe via optoisolators
• Power supplies: 5 V/8 A, 24 V/3 A, 36 V/12 A

On one BOB (P1) I plan to handle signals like Arc OK, Up, Down, E-stop, relays; on the other BOB (P2) I plan to handle limits, probe, and driver step/dir lines.Questions

1. With that setup (7i92 + 2 × 5ABOB), is the wiring architecture I’m proposing feasible?
2. I was thinking of starting with the G540 HAL/INI config in pncconf as a base, then editing it . Is that a sensible approach, or is there a better workflow to generate a clean HAL/INI for this sort of layout?

Thanks again to PCW, tommylight,  Your help is very valuable. Any further feedback or corrections before I begin wiring would be hugely appreciated.

Vielen Dank für Eure Antworten, 

1. Parameterwert in einen Analog Hal pin schreiben (zB M68 E0 Q#31)

2. Parameterwert mit Gcode logging in eine Datei schreiben

1.) Parameterwert in Hal Pin werde ich testen. 
2.) Gcode logging: das praktiziere ich bereits, ist aber nicht so ganz "bequem" 

Über Debug kann man sich das im Fenster vorne ausgeben lassen. Z. B. #1234 = 12 + 32 ( debug, #1234 )
es gibt auch noch msg, und print, jenachdem ob es im terminal stehen soll oder vorne erscheinen soll

 
Der Befehl ist mit schon sehr wohl bekannt. Habe ich im Eröffnungsthread ja geschrieben.....
Nur wenn ich ein CNC Programm ablaufen lasse, Dann verschwindet das untere Fenster (F) und anstelle dem wird das CNC Programm angezeigt.
Wie bleibt dieses Ausgabefenster erhalten (für Statusreports und Fehlermeldungen) während das NC Programm ausgeführt wird?
(siehe Anhang!)


 

 

"Invalid output mapping" is what it says. infosys.beckhoff.com/english.php?content...stem/1058704779.html
What I think you should do is minimize the config to one slave, slave 0, and make that go OP.
Comment out all references to the other slaves lcec.0.1 and lcec.0.2 in the hal files.
Comment out/remove all sdoconfigs from ethercat-conf.xml and only leave slave 0 in there.
Comment out pdos, leave 6040, 6060, 607a, 6041,6061,6064 only.
With that, the slave should go to OP mode, check with "ethercat slaves".
Then gradually bring back the mods you took out, and fix what doesn't work.

There's been a couple of things I was thinking about for a while and the more I dig in the more I wonder about why they haven't become a thing with LinuxCNC. When I have other uses for something I tend to think "will this work with LinuxCNC too?" I suppose everyone gets used to doing things a certain way and only pick up new things if they are the hot new thing (like EtherCAT). There are probably a couple of interfaces that are "just there" that should technically be fully realtime capable. I think alot of it also stems from the fact that when people were using parallel ports on desktop motherboards, Mesa popped up with PCI and Ethernet cards and that's just the way it went. Nowadays I like to use mini-PCs like Odroid H3/H4, I still use some H2's as well. These have UART and I2C ports right on the "GPIO" header, interestingly the GPIO header doesn't actually have GPIO. I use these because they're cheap, small and have 2 ethernet ports. I would still use a Mesa Ethernet card for most bigger things but I run into alot of cases where they don't have anything convenient to use in the place I want to use it. The reason (besides being readily available) that I would think about UART and I2C is that they are simple and easier to deal with for something custom.

Unless I'm missing something, both UART and I2C should be fully realtime capable. Niether is the fastest interface out there but I don't think they really have to be. The appeal for I2C is there are already a bunch of kernel drivers for specific ICs, IO expanders like MCP23017. Currently these are only used in userspace components etc., but if the interrupt output is used I think it can meet RT expectations, especially if you can run the bus at 1Mhz+. I've gotten these IO expanders to work with the kernel driver on the H-series as I needed something to register as a gpiochip for use with other kernel drivers. The LinuxCNC RT bits just don't exist yet. The thing about it is there are clockgens, ADCs, etc,  that all have kernel drivers. There obviously needs to be a hal compenent for this stuff, I'm going to play with it soon but what it seems to me is that if the HAL environment existed, you could literally breadboard a controller based on just I2C chips that have suitable kernel drivers. There's a limit of chips that can be strung in there before transaction queues start to build up but besides that, I think this could be a thing. SPI could be used in much the same vein as many I2C chips have SPI variants and generally have an associated kernel driver.

UART/Serial is also probably realtime capable as a host interface (NOT USB serial). Again Ethernet is better but AFAIK I think Intel UARTs can be run at over 3 Mbaud, that's pretty quick but I'll have to test that as I've never actually seen or heard of it being done. I wouldn't expect this to be super popular since again there are better ways to do this but the main reason I'd want to use UART is for a control panel host. Right now I'm using Arduino Connector to a custom board running a Teensy 4.1. It works, it's fine but Arduino Connector is userspace/Python. Typical use is with the USB serial port, should be usable with a UART instead but probably not gaining anything being userspace. I'd like to replace Arduino Connector with a realtime UART setup to the Teensy board. At this point I'll probably just switch to an ESP32 S3 for other reasons but I don't want to deal with anything like Ethernet. This is something else that needs HAL implimentation but I will start with some simple tests just to see what I can do with it.

I'm curious if I'm missing anything from a bus/hardware perspective. I'm not concerned with why these aren't already popular choices, I think I've already mentioned that. More concerned with what I might be missing as far as implimenting them goes. I can't find a great reason why either of these wouldn't be perfectly fine to use as RT interfaces, albeit with some limitations.

 

Thank you for the response, Based on your idea of the #5400 I tried this code, but no luck: here is the current status of my toolchange.ngc
O<toolchange> SUB

(MSG, Toolchange subroutine called)
(MSG, Tool number param #1 = #1)
#2 = #5400
#<tool_num> = #2
;#<setter_z> = -3.0
#<safe_z> = -.5 ; safe Z height above tool setter
#<probe_z> = -4.0 ; how far down to probe
#<setter_z> = -3.0 ; Z height of the setter in machine coords

G49 ; cancel length offset
G53 G90 G01 X1.0 Y0 F50. Z[#<safe_z>] ; move above setter

; Begin probing
G38.2 Z[#<probe_z>] F1.0
(If probe failed, LinuxCNC will stop here)

#<measured_z> = #5063 ; captured machine Z from probe

(MSG, 5063)

; Compute tool length

(MSG, Compute tool length)

#<tool_length> = [#<measured_z> - #<setter_z>]

; Store to tool table
(--- Optional: print value to operator ---)
(MSG, Tool length = #<tool_length>)

G10 L1 P#<tool_num> Z#<tool_length>

G43 H#<tool_num>

; Done
O<toolchange> ENDSUB
M2

I feel my problem lies in the fact that my tool number is not getting passed to the tool.tbl When I enter (debug #5400) in MDI get 0.0000 after entering in a T1 M6 command in MDI, I assume that I would see a 1 for T1? My tool height seem to be registering. When I enter (debug #5063) the z value from the tool setter shows up as the #5063. I am still getting the Pvalue out of range with G10 L1 error after the probe is tripped when the G38.2 part of my file runs.

I made this change to my hal.io:

loadusr -W hal_manualtoolchange
net tool-number iocontrol.0.tool-prep-number => hal_manualtoolchange.number
net tool-change iocontrol.0.tool-change => hal_manualtoolchange.change
net tool-changed iocontrol.0.tool-changed <= hal_manualtoolchange.changed
net tool-prepare iocontrol.0.tool-prepare => iocontrol.0.tool-prepared

Here are some parts of my ini file:

[RS274NGC]
REMAP = M6 modalgroup=6 ngc=toolchange
SUBROUTINE_PATH = /home/dave/linuxcnc/configs/by_interface.pico.univpwmv/subroutines/
#/home/dave/linuxcnc/configs/by_interface.pico.univpwmv/subroutines/
PARAMETER_FILE = linuxcnc.var
FEATURES = 12


TOOL_TABLE = tool.tbl

RETAIN_TOOL_NO = 1

TOOL_CHANGE = manual

I should note that the the pinirq script runs as expected on the LinuxCNC/Debian 12 image

Thank you Tommy and Djdelorie, i appreciate your help so far, i had a few minutes and disconnected probe and assign individual pins and did not work but i did not have much time and I will be away form the shop probably till Tuesday (which sucks because i want to convert this machine so bad) but i like the idea of only using 2 pins this way ill end up opening one output. and ill get back here to report how ever i did not find the option of assigning multiple stepgens to one pin so i assume it will have to be done in .hal and .ini??!! ill include those once i try (if i get a chance ill sneak in the shop on Sunday (fiancé permitting lol)

thank you again for the help

Files attached.

 

   

 

Coming up with another problem:
When using toolchange with combobox toolselection and pushbutton, Toolchange gets completed.
Trying to jog with jog pushbutton afterwards, this error appears for any axis

Joint jog requested for undefined joint number=-1 (min=0,max=3)


Doing toolchchange Tn M6, jog works without problem
When a MDI command movement of any axis is done, afterwards jog is possible without error

Don't see anything wrong there.
To try to diagnose this, we would need to see
ini file
hal file
ethercat-conf.xml file
and last say 40 lines of ouput from the command "sudo dmesg"

Here you go, see attached. 

Change appTimePeriod as well. Lcec usually gives an error for mismatch with servoperiod, error somewhere after linuxcnc start command.
Are there any other errors in the window where you start linuxcnc?
Can you post the ouput from the "lcec_config" command?
I really only have two more ideas, try with sm sync and free run.
For sm sync change to assignActivate=100, and for free run test comment out the whole dcConf line/item.
If that doesn't makes things better I think you should hook it up to Twincat and get it going there.