Advanced Search

Giovanni,

Can you confirm something for me? I am going to attempt installing today.

Your guide was posted here 09/feb/2025 but when I downloaded the files from the link in the guide the files are all dated 04/oct/2024. I was expecting updated files from reading this thread. I thought there were recent file updates????

Thanks much for all the work on this.

When I started halscope, the trigger level slider worked as expected. For some reason it has become non-functional. The slider is gray, no green, no way to adjust it. I've tried restarting halscope and changing trigger channel. It doesn't matter if I'm in Normal or Auto trigger.

Thanks,
Steve

unknown wrote:

Here's an explanation of "Latching Relays", which is what my schematic shows. I made up some PCBs to make the connections easier.

www.pcbway.com/blog/PCB_Basic_Informatio...Relays_d665ce9b.html
 

Good evening Rob,

Thank you for the article link. In principle, I understand how it works.

Best regards,

...behai.

 

Thanks for the suggestion.
It turned out the following errors not related to the acceleration but to the EtherCAT configuration.
After searching Github for other LinuxCNC configurations (which I should have done in first place) using the EL7041 I was able to create a working configuration.
I'm not 100% sure why it works now, but I suspect the "srv-scale" wasn't set correctly.

In case someone has a similar problem getting started, the config is accessible on Github .

/Mark
 

Hi guys,

after performing probing (with Basic Probe routine), the results are not displayed in the GUI immediately. The results appear only after pressing the probing button again. Additionally, the values from the previous probing are still displayed each time a new probing is performed.It seems that the GUI is not being updated properly to reflect the new probing results.I am using the QtDragon_HD GUI with the Basic Probe routine. After performing several tests, the current situation is as follows:

• If you press the button for Z-axis height probing (probe down routine), the probe starts moving. If you change the feedrate or rapid override potentiometer value during this movement, the program does not wait for the probing to finish, but instead immediately displays the previously measured value in the table (in the case of the first probing, it shows 0).
• If you press the button for Z-axis height probing (probe down routine), the probe starts moving. If you don’t change the feedrate or rapid override potentiometer value during this movement, the program waits for the probing to finish, and only after successful probing does the value in the table update — however, once again it shows the previously measured value (or 0 in the case of the first probing)

Can someone explain to me why, even after a successful probing, the currently measured value is not displayed, but instead the value from the previous measurement is shown?
Could this be caused by a synchronization issue between the Basic Probe widget and the measurement subroutine?

Thanks a lot!

Sorry for the supid question but how do i check for that?
Sorry, this is my first time working with linuxcnc and remora.
Just for info, i'm using the ini and hal from the remora-octopus sample
     

Hey brains trust!

I'm working on converting an NVEM v5 board (says IMXR_NVEM_V6   2022-08-11 on the silk screen) to use Remora. I managed to get the firmware uploaded to the board, thank you Scott for the great vid. The board uses RT1052 chip and I was able to make a donor STLink into a DAPLink and upload the firmware by compiling the latest Remora-RT1052-cpp from source. I could initially see it working by toggling the eStop in software and seeing the LED light up on the board so I know it was responding to LinuxCNC at first. I basically just followed the steps in the video. 

I got the static IP set up, did the Halcompile of the ethernet component, and then successfully uploaded an unmodified full_config.txt with the upload_config.py script, I managed to get past needing to install the TFTP package via PIP successfully as it wasn't included on my machine by default. This is where I'm now running into issues. After installing the config, LinuxCNC will no longer allow me to get the machine out of eStop, where it did before. Clicking the button does nothing and the LED on the board no longer toggles. It no longer lets me upload new configs, and pinging 10.10.10.10 now no longer responds (it did before I uploaded the config. This happened once already and re-flashing the chip got me back to being able to ping, get the machine out of eStop and upload new configs, none of which I can do anymore after uploading the config. The chip definitely isn't bricked as I can erase, reupload and step over code using the makeshift DAPLink as a debugger. 

I've tried wiring up a serial connector for the little port in the corner, but I'm not even sure that works to begin with - I've only seen Scott do it to an EC500 board so this potentially could help in troubleshooting. Seems I can read serial with a loopback and I know the wiring pinout, baud rate, comms settings etc from the pic on page 1 of this thread, none of that has output any data to any of the serial terminals I've tried on both of my machines.

I'm using the latest LinuxCNC version which I believe is now using Debian Bookworm which now uses NetworkManager so some of the instructions used in the video are now slightly different. I've fiddled with firewall and port settings but I'm not sure that's it because uploading and connecting works the first time just fine - port 69 is definitely open for SFTP.

Hope that's a good enough starting point for troubleshooting, let me know what other details I can provide to help troubleshoot this one? It's an odd one!

Hello, please excuse me for the delay in replying but I have been sick.

Yes, I managed to adjust my PID but not exactly, I still have small ocillations at certain positions of my rotating B-axis.

I saw that there is an Autotune. But impossible to find any practical documentation on this program which apparently makes a PID setting automatically???

I'm looking at how to program an Autotune in python. Sending commands and retrieving data, tracking errors is quite simple with "Import Linuxcnc".

the regylge of a PID is very tedious in length. If an automatic program exists, I'm a taker.

If anyone has any information I'm interested.

Thank you

Here's an explanation of "Latching Relays", which is what my schematic shows. I made up some PCBs to make the connections easier.

www.pcbway.com/blog/PCB_Basic_Informatio...Relays_d665ce9b.html

To late...

Yes improvement, not the same error now.
DId you disconnect and reconnect? Or just unplug the LAN cable on one side and plug it back again.
Now it seems the Mesa is off or disconnected, so:
-check the cable is inserted fully on both sides
-check Mesa for red lights (on power on it probably does come on shortly)
-check the Mesa 5V power supply, anything under 4.5V and anything over 5.3V roughly is reason to change the power supply
-use another cable ( i had new out of the box cables not work, kinks and stepping on them will make them useless, etc)

All fixed.

new connection setup. And hey presto we are working again.

Thanks Tommylight !!!! life saver

Changes made. no improvement

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp3s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 78:7b:8a:b4:e1:b9 brd ff:ff:ff:ff:ff:ff
inet 10.10.10.100/32 scope global noprefixroute enp3s0f0
valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether a8:be:27:c0:1f:18 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.102/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp2s0
valid_lft 6652sec preferred_lft 6652sec
inet6 2401:d006:d001:9301:b2bb:20c1:e292:519/64 scope global dynamic noprefixroute
valid_lft 429sec preferred_lft 429sec
inet6 fe80::5009:8b29:227e:d171/64 scope link noprefixroute
valid_lft forever preferred_lft forever


$ linuxcnc
LINUXCNC - 2.9.3-125-g62642dde63
Machine configuration directory is '/home/cnc/linuxcnc/configs/T19'
Machine configuration file is 'T19.ini'
Starting LinuxCNC...
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Note: Using POSIX realtime
Found file(REL): ./T19.hal

identityKinematicsSetup: coordinates:XYYZ
Joint 0 ==> Axis X
Joint 1 ==> Axis Y
Joint 2 ==> Axis Y
Joint 3 ==> Axis Z
identityKinematicsSetup: Recommend: kinstype=both

hm2: loading Mesa HostMot2 driver version 0.15
hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
hm2_eth: ERROR: Could not retrieve hardware address (MAC) of 10.10.10.10: Resource temporarily unavailable
hm2_eth: rtapi_app_main: Resource temporarily unavailable (-11)
./T19.hal:9: waitpid failed /usr/bin/rtapi_app hm2_eth
./T19.hal:9: /usr/bin/rtapi_app exited without becoming ready
./T19.hal:9: insmod for hm2_eth failed, returned -1
Shutting down and cleaning up LinuxCNC...
Running HAL shutdown script
hm2: unloading
Note: Using POSIX realtime
LinuxCNC terminated with an error. You can find more information in the log:
/home/cnc/linuxcnc_debug.txt
and
/home/cnc/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal

RNJFAB wrote:

2: enp3s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 78:7b:8a:b4:e1:b9 brd ff:ff:ff:ff:ff:ff
inet 10.10.10.10/0 brd 255.255.255.255 scope global noprefixroute enp3s0f0
valid_lft forever preferred_lft forever

Yup, exactly, set to 10.10.10.10.
If you used the Network Manager to configure the PC, use it again to change it to 10.10.10.11 or 10.10.10.100 , save, disconnect and connect again.
If you edited the /etc/networks file, edit it there.

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp3s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 78:7b:8a:b4:e1:b9 brd ff:ff:ff:ff:ff:ff
inet 10.10.10.10/0 brd 255.255.255.255 scope global noprefixroute enp3s0f0
valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether a8:be:27:c0:1f:18 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.102/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp2s0
valid_lft 4044sec preferred_lft 4044sec
inet6 2401:d006:d001:9301:b2bb:20c1:e292:519/64 scope global dynamic noprefixroute
valid_lft 539sec preferred_lft 539sec
inet6 fe80::5009:8b29:227e:d171/64 scope link noprefixroute
valid_lft forever preferred_lft forever