Advanced Search

I used the image "Armbian_24.8.1_Orangepi5_bookworm_vendor_6.1.75_cinnamon-backported-mesa_desktop.img" (the one in your link on page 35), and it boots and I can apply rt kernel to it.

The answer lies in the differences between the two non real time images. One boots and the other doesn't.

Maybe it's me but it's not clear to me, the message above means that you can boot now from nvme with the last rt kernel on the image I suggested in the first place?

I don't know what to say. I wrote the image 2 times on nvme and it doesn't boot.

Hi there
Could solve the GPIO Problem, but now i got another problem:
The homing switches don't react.
Tested the switches and pins, everything does as it should (input is normally 1, if it touches it opens ->0), but if the  machine touches the switches, it goes on with driving. what did I do wrong?
INI file:

HAL file:

BTW, i use KdenLive for video editing, it is a bit more complicated and feature rich.

Ein Camprogram ist das Program das aus einer Zeichung den G-Code erstellt zb. Sheetcam oder ein Unterprogram des Zeichenprogram.


Gruß
Juergen

I am trying to setup my router with a 5i25 card I inherited. I have a previously working config from a parport setup with the gecko and have been working to port it over. The 5i25 is running the g540x2 firmware and I have most of the motion setup.

I am still missing a few things. Biggest one is homing as its a dual motor gantry this is kind of critical to make sure machine is square.

I have setup the correct pins and have confirmed the status changes through the GUI but when I press home nothing happens. I am sure I am missing something but can't see it.

Any suggestions or ideas would be appreciated.

Files attached XYZCNC is new config for MESA. Gecko is old for parport.

Steve

[edit]

I guess I haven't really thought through the process yet as it probably starts to reoptimize the validate_<...>.ngc code in the background when I hit the run button with the already optimized code loaded.


Looks cool.

So are you thinking of moving on to the planner now or are you still thinking about representing the clothoid fillets in a more concise form rather than a bunch of G1 line segments? 

I don't understand exactly what you mean, here all the deb files work with boot from sata and nvme on the orange pi 5 and 5 plus, so now it also works on yours?

remapping is certainly a valid option for sure.

Then you may want to try the patch I posted above. If you want dedicated halpins, rather than use motion.digital-out-xx pins, you could create a python hal component that creates the pins as you want them and then use a python remap that writes directly to the python comp instead of the ngc remap setting the motion.digital-out-xx pins.

 At this point linuxcnc cannot be recovered and has to be restarted


Correction: If I wait long enough after hitting the 'Stop program execution' button it does actually stop the program and the GUI is responsive again but loading another ngc file (not even running it) makes it hang again.

termial output:

USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 1 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 53 timeout
USRMOT: ERROR: command 1 timeout
USRMOT: ERROR: command 38 timeout
task: main loop took 35.003955 seconds
USRMOT: ERROR: command 11 timeout
task: main loop took 1.001118 seconds

 

Ok, so just so we are on the same page, here is what I get.

It creates the validate_<...>.ngc :

Not sure if 'vector pointer is not valid' is a problem but I notice that when I run the created file it gets hung up after having run the first maybe 500 lines (this changes from one try to another). At this point linuxcnc cannot be recovered and has to be restarted.
 
 

Meanwhile more validate_<...>.ngc files have been created:


 


Are you seeing these hangups as well?

Hi there,
I`m actualy on optimizing my Probe Basic Installation.
One of an Error, which i had since the beginning was the following

After confirming this message i didn`t have any problems.
I run an Latency test and i think my system should be OK.
Further I`m using a MESA 7I96S, so it should be OK.

Is there something i can do?
Thanks a lot.
 

With the latest deb's from the Test directory it did not boot.

I downloaded the image you put "Armbian-unofficial_24.11.0-trunk_Orangepi5_bookworm_vendor_6.1.75_cinnamon_desktop-002.img" and big surprise, it stuck when booting.

I used the image "Armbian_24.8.1_Orangepi5_bookworm_vendor_6.1.75_cinnamon-backported-mesa_desktop.img" (the one in your link on page 35), and it boots and I can apply rt kernel to it.

The answer lies in the differences between the two non real time images. One boots and the other doesn't.

Do you think that if you applied configuration for rt-kernel on the image "Armbian_24.8.1_Orangepi5_bookworm_vendor_6.1.75_cinnamon-backported-mesa_desktop.img" it would result in deb's that would work?

Aciera wrote:

I cannot test this right now but looking at this makes me wonder if it could actually be this easy to add 'M7' and 'M8' to the list of remap-able Mcodes (considering that according to the documentation 'M9' should not be a remap-able Mcode somebody already seems to have done or at least tried to do something like this)  :

 

remapping is certainly a valid option for sure. 

Yesterday, i did some further testing and at least i could solve the issue with my tootlable.

Thanks to all.