Advanced Search

You are missing the "servo-thread" for the "jogincr" component

that is:

addf hm2_7i80.0.read servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf pid.x.do-pid-calcs servo-thread
addf pid.z.do-pid-calcs servo-thread
addf pid.s.do-pid-calcs servo-thread
addf jogincr
addf hm2_7i80.0.write servo-thread

should be:

addf hm2_7i80.0.read servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf pid.x.do-pid-calcs servo-thread
addf pid.z.do-pid-calcs servo-thread
addf pid.s.do-pid-calcs servo-thread
addf jogincr servo-thread
addf hm2_7i80.0.write servo-thread

That is a realtime network error.

1. Have you run a latency test on the PC?

2. What s PC hardware is being used?

3. Have you disabled all power management in the PC's BIOS?

4. What is the result of the command (typed in a terminal)

ip a

?


 

If something needs 12V and 5V DC, having a 12V power supply and a 5V power supply with a common negative—effectively a single power supply with two output voltages—might make sense.

If the power supplies are powering seperate things, probably keep them isolated.

It all depends.

 

He cambiado U5 y U7 ahora me salta este error

There are (often) cases where negative sides of power supplies must be wired together, but usually not at the power supply, it is done on equipment from one part to another. This avoids loops and keeps stuff at the same potential.
There are cases where this is not allowed at all.
So the short answer is yes and no, you have to know what you are dealing with to know if this can be done or not, and is not something you can just read on the internet, it requires deeper knowledge of the subject.
-
It is easier to answer if you give us exactly what you need to do.

If a power supply has a ground/earth screw, connect it to electrical ground.

A metal chassis should also be electrically grounded.

But power should be isolated.

Don't connect power supplies together.

I was not implying there was an issue with the subroutines. While I don't use them as much as you, I have used them quite a bit without any problem. Additionally, my machine is a Bridgeport BOSS, which is quite rigid.

Having a log would provide the facts of what really happened, rather than relying on what I think I saw. Again, as probing has worked flawlessly, I was not 100% focused on the details. It looked like it triggered on the Z and kept going. I always test the probe connection prior to probing, with a manual trigger. So knowing if it triggered, how many times, the feedreate and movement, in chronological order, I could solve this definitively. I was thinking of saving the last 2-3 probes and rolling the logs so one the past probing, but not wasting disk space

The .txt file is actually a .sh file but I can't upload it here

No creo que sea real, pero lo pregunto los negativos de las fuentes de alimentación de diferentes voltaje hay que unirlos entre Ellos. También había escuchado algo sobre que todos estos conectados hay que llevarlos a la tierra AC Que me parece mal también, pero no entiendo así que lo pregunto. Gracias

Hi, I'm also looking forward to your conclusion because I need EL2502 too. Besides PWM, I also need duty cycle to controll a laser.
Thank you

Hello,
i think there is an error and think it must be:

sudo chmod +x /usr/share/axis/tcl/axis2.tcl instead of sudo chmod +x /home/donno/Downloads/axis2/axis2.tcl
(third line with sudo)

Donno wrote:

[b][b][b][code][b][b][b][code][b][b][b][code][b][b][code]I tested this on Linuxcnc 2.10pre and works great !

 [attachment=56124]axis2.png[/attachment]

Maybe add a readme.txt in zip with instructions to install ??


[code]Setup Instructions Main

set display = axis2 in your ini
sudo cp -a /home/donno/Downloads/axis2/icons/. /usr/share/axis/images
sudo cp /home/donno/Downloads/axis2/axis2.tcl /usr/share/axis/tcl
sudo chmod +x /home/donno/Downloads/axis2/axis2.tcl
sudo cp /home/donno/Downloads/axis2/axis2 /usr/bin
sudo chmod +x /usr/bin/axis2
sudo cp /home/donno/Downloads/axis2/glcanon.py /usr/lib/python3/dist-packages/rs274/
sudo chmod +x /usr/lib/python3/dist-packages/rs274/glcanon.py

Linuxcnc-DEV

set display = axis2 in your ini
sudo cp -a /home/donno/Downloads/axis2/icons/. /home/donno/linuxcnc-dev/share/axis/images/
sudo cp /home/donno/Downloads/axis2/axis2.tcl /home/donno/linuxcnc-dev/share/axis/tcl/axis2.tcl
sudo chmod +x /home/donno/linuxcnc-dev/share/axis/tcl/axis2.tcl
sudo cp /home/donno/Downloads/axis2/axis2 /usr/bin
sudo chmod +x /usr/bin/axis2
sudo cp /home/donno/Downloads/axis2/glcanon.py /usr/lib/python3/dist-packages/rs274/
sudo chmod +x /usr/lib/python3/dist-packages/rs274/glcanon.py


where "donno" should be your username
 

[/code][/b][/b][/code][/b][/b][/b][/code][/b][/b][/b][/code][/b][/b][/b][/code]

Probably important: the connected enconder is a 1000 increments TTL encoder connected to Enc3 on the 7i33 and in Halshow I could see the counts in/decreasing when turning it left/right- so it seems to work in principle and is recognized by LCNC
And I would for the moment want to be able to move the axes by handwheel without having to home the axes before.

The whole setup is  a 7i80hdt-->7i33-->7i37

Hi, though it seems to be rather a monologue I have still not given up  .  Ok mean while the error was found- the repaired 7i33 unfortunately still was not working correctly.
Now I have the two axis working properly and smoothly and would want to be able to implement a shared handwheel for the X and Z axis.
Therefore it was recommended to do a second config file with PC-Config and copy the necessary lines to the original HAL and INI files, sonot to overwrite the original config.
And so I did. But obviously I made some mistake and get an error message when starting LinuxCNC now telling me one infrmation is missing.
Can someone help me to get this corrected please? I am not able to find the mistake....

Thank you
Sigi
 

Hey, sorry if this isn't the spot to ask for help with this issue. 

So I've decided to try to build a new controller for my CNC converted lathe. Did some searching around and found remora. I already had an SKR 1.4 Turbo sitting in a closet from an old Voron machine. As far as I remember, I was running Klipper on it, but didn't mess with the bootloader or anything. 
So far I have:
grabbed the firmware.bin from the "github.com/scottalford75/Remora/tree/mai.../FirmwareBin/LPC1769"
placed it on a freshly flashed FAT32 4GB SD card.
placed my extremely minimal config.txt on the SD  card as well
inserted into my SKR 1.4 Turbo and powered it for 10-20 seconds, cut power.
removed the SD card and inserted it into my card read on my windows machine and confirmed the firmware.bin did in fact change to firmware.cur
ejected the SD card, re-inserted it into the SKR 1.4 Turbo.
Powered on my raspberry pi 4 running the: LinuxCNC 2.9.4 Raspberry Pi 4 OS based on Debian Bookworm Raspberry Pi 4 Uspace compatible with Mesa Ethernet and SPI interface boards. Img. from the linuxcnc downloads page.
SPI enabled in the /boot/firmware/config.txt on the raspberry pi 4
SPI and Serial Debugging wired and configured in the SKR 1.4 Turbo config.txt
Hal file for my config is setup minimally to only include two axis's and the rest of the standard Remora hal related stuff. (I may have missed something but I followed the remora documentation as best I could)
Everything "seemed" okay at first, with the SKR not powered, I could launch my probe basic lathe config, but couldn't take it out of e-stop (expected as the hal file has a remora e-stop function that prevents this without an active SPI link)
Boot the SKR up, and launch my probe basic lathe config and I am able to take the machine out of e-stop. 
However, this is where I hit a dead end. I went to add my limit switches, I configured my hal file to reflect what was in my SKR's config.txt for those data bits and I was hit with "remora.input.00" does not exist and the obviously probe basic lathe doesn't launch. 
I double checked my config.txt to make sure I didn't having any duplicated data bits etc. etc. etc. 
That's when I "tried" to watch the serial debug in terminal by adding the serial debug section into my SKR's config.txt. 
booted the pi 4, ran: screen /dev/serial0 115200 in terminal, started watching the window, powered the SKR up and it showed some things, however, not what I was expecting. It sets up some pins for the limits, but they aren't what I had in my config.txt... not based on the data bits I had selected. I also tried a variation of different data bits etc. and still couldn't get it to load the correct ones. I ended up just updating the hal file to reflect what it DID assign those pins to and probe basic lathe did launch at that point. So I triggered the input pins for both limits on the SKR while monitoring halshow and it's not showing a trigger. I also don't even think my serial debug screen is displaying correctly. I've tried re-flashing the SD card, double checked I was using the correct firmware.bin for my board. triple check my SPI wiring, replaced with shorter wiring, etc. I'm really stumped. I was going to try flashing the default SKR 1.4 turbo firmware and try re-flashing after that, but I was having trouble finding a pre-built firmware.bin to flash and I'm terrible at building from source. Any help with getting this running correctly would be really appreciated. I've spent the last 4 days or so struggling to figure it out on my own. I've attached a copy of my current hal file (it's rough/ not complete yet but it launches)
a copy of my config.txt that is in the root directory of the SKR SD card, and a screenshot of what my serial debug monitoring is showing in screen. 
(note: I left the pins for the x and z limit in my hal setup to whatever it created for them based on the serial debug screen because that's what allowed me to launch)

thanks again in advance.