Advanced Search

Hello bertoldo,
I have no experience with Raspberry Pi. I do with Laptop + Debian 12 RT kernel + LinuxCNC
Here is my files for SCARA with Gmoccapy demo.
You just need to revise EtherCAT "xml" file to meet your real motor servo controller.
Hope you find it helpful.
Tks.
 
 
 

Hello again everyone. Thank you all for your responses and for letting me know I shouldn't waste my time with RTAI.

I believe I have managed to solve the latency errors and am now at the next roadblock..

I had previously passed isolcpus=1 to grub as a kernel parameter, however I read up more and realized that was incorrect. LinuxCNC uses the last core for realtime processes from what I understand. I changed that to isolcpus=2,3 (extra core helped even more) and the latency is in my opinion very good now. <10k on idle and no more than 55k even with 20 instances of glxgears open (I should have tried glxspheres too, but I'm not sure how to install it on Debian). I let it run for quite a bit and there were also no random spikes to speak of.

Now the issue I will look into is a random "joint X following error" or a "joint X amplifier fault" (it is a seemingly random joint from 0-4 each time) at weird times. I had previously also been getting this error, however I neglected to mention that as I thought it was all due to the latency. Sometimes this will occur as my test program is running, but the weird thing is that it also happens as the machine is idle. Even more strangely, one time the program conducted successfully with no issues and immediately as it ended the joint following error appeared. All of this leads me to rule out the latency being problematic now after I improved it - I doubt the latency would "wait" for the program to finish before it caught up.

I also tested the same machine on another small fairly modern i3 >3GHz PC (the onboard one is around 1.2GHz) just to be sure. Same situation.

Only now that I look into it, do I think to focus on the word "following" in the following error. The .ini file does have an FERROR variable which the previous colleague has set to 0.5 all across and MIN_FERROR to 0.05.

I am going to spend the day reading the wiki page on the "Following Error" and making sense of it. In the first paragraph it says we can be almost certain this error implies a mistake in the .ini. I thought I'd post this beforehand to give an update and to let you kind folks know not to bother with the RTAI line of thinking anymore.

I am attaching my .ini once again just in case someone may have the time to point me in the right direction.

Also, since my issues have moved rather out of scope of the EtherCAT forum subsection, do let me know if I should make another post in a different section.

PS. Neglected to mention that the maximum velocity of the configuration is 6000mm/min. Interestingly, I have the impression that it works much better at lower velocities in the 2-3k range, which should additionally point to the FERROR not being configured properly. I can't conclude it for certain since my test program is rather long and I haven't had the time to extensively test it at even lower speeds.

Yes it should work in AXIS as well. See here for more information: github.com/verser-git/probe_screen_v2.9

This shouldn't be an issue anymore, right?

you can set
Global -> View -> Auto-Recalculation to False

to redraw/calc the new settings, you can use the toolbar button 'redraw' on the right side.

Moin,

die Werte werden im ini-File unter den jeweiligen [JOINT_<n>]-Abschnitten der Achsen festgelegt (Wert HOME) und sollten zwischen MIN_LIMIT und MAX_LIMIT liegen.

Grüße
Carsten

I think the 'single-step' test may have a problem with race condition which means that it may well pass if run again but I have not found a way to rerun tests on my pull requests on github.

Rodw was right, seems like they finally cleared the last printk/console hurdles now.

www.phoronix.com/news/Linux-6.12-Printk-Pull-Request

increasing the ohmic threshold to 23.5 seems to have solved this issue for me.
After the nozzle got wet from the watertable the ohmic voltage was showing at above 22volts.

Hi,
Curious to know if the script for the post processor in qtplasmac worked for anyone?
Currently I am using a different post processor and it runs through a filter on qtplasmac which works ok. But some files it has issues with and I can't use the option to start at a certain line.

So I thought I would try and run this cff to see if it was a better option, using 2015 hypertherm nestmaster.

I used the cff for pronest on this thread. Screenshot and gcode attached.
 

cakeslob wrote:

is "precise" a debian version or something?

Ubuntu

machinedude wrote:

Are there any tip or tricks for getting a tandem axis tuned? it seems like it is a lot harder to get settled into.
 

About the only thing I've seen that was reasonably successful was to disconnect the gantry from the motor to be tuned, and attach half the gantry weight to that motor's carriage.

This will get the inertia in the ballpark, and the values can be copied to the other motor.  From then on adjust the same on both motors.

This may be fairly easy, or it could be a royal pain - just depends on how the hardware is assembled.

is "precise" a debian version or something?

Was going to open a new thread, but thought the image authors might want to get some feedback that might relate to the image.

Installed the 2.9.3 image on a RPi5 and after a few self-inflicted hiccups everything seems OK, including qtpyvcp/probe basic.

Except the touchscreen isn't reconized.  lsusb does't show the touchscreen.

I've got the touchscreen connected through a powered external USB hub, and I've tried every other combination of ports.  The RPi5 seems really picky about what hardware works (or doesn't) on various ports.

Keyboard w/touchpad is fine, as is a usb trackball.  Both of those work through the hub and directly in one of the Pi's ports.

Any ideas on what to do about the touchscreen?  Monitor is one of those generic 15.6 things, and works fine on everything else it's plugged in to.