Advanced Search

after reboot an old state of the workspace is restored. even when i close everything before reboot. It's not really a problem but it's annoying

type_2 ist doch ein Quadratur-Signal. Wäre hier type_0 im 'velocity' mode nicht besser geeignet?
linuxcnc.org/docs/html/man/man9/stepgen.9.html

Have you had a look at the 'xyzac-trt' config?

github.com/Sigma1912/linuxcnc/tree/maste...table-rotary-tilting

Vielen Dank,
habs nun mit  step_type 2 gelöst. 
Drehzahlregelung funktioniert super, allerdings hat  step_type 2 kein einfaches Direction Signal.
Gibts ne einfache Möglichkeit das Richtungssignal bei TYPE_2 zu bekommen?

awesome! do you think you could help use make one for the machine setup above so we can dip our feet and start troubleshooting some things in vtk?

Meinst du das hier:
wiki.linuxcnc.org/uploads/lube.py

Hi,

wollte mich heute um die Zentralschmierung kümmern, leider geht der Download der Lube.py nicht mehr, kann mir jemand aushelfen?

Danke
Grüsse
Steffen

Not an expert but I have made a few sim configs for 5/6 axis machines including adjustable geometric offsets for the rotary assemblies and documentation:
github.com/LinuxCNC/linuxcnc/tree/master...ndle-rotary-nutating
github.com/LinuxCNC/linuxcnc/tree/master...is/table-dual-rotary

As an alternativeThis would then grab the 'KINEMATICS' entry from the KINS section in your ini file.

Hey all,

@Turboss and I have been working on the vtk back plotter and making some great progress in improving its functionality, but we are getting into an area where neither have been yet with linuxcnc which is the 5 axis realm.  we were wondering if there are any 5 axis linuxcnc users in here that may be able to help lend a hand with a few things such as program generation and configuration help since it doesn't seem to be a config that the builders can make (seem to be capped at 4 axis, guessing its for a reason..lol).

If you have a working config/5 axis machine using tcp and switchkins, we would very much appreciate any assistance you could provide to take some of the learning curve out of things and allow us to get the simulation backplotter dialed in for each type of machine config and have the machine simulations plot correctly with the graphical representation. we plan to pull that data out of the ini and add in sections of the backplotter code to accomodate each type and allow how the graphical machine representation along with the gcode files interact.  as you can see in the short video below, we have the 5 axis machine simulation working sort of but just need to better define some parameters to determine if the machine moves or the work envelope moves and all of the camera translation magic.  it should be super sweet when done and be a very useful tool for being able to prove out complex gcode in linuxcnc before going to the machine itself and or having it on the machine itself for some additional cool factor!

Any help or guidance is greatly appreciated!

Chris

 

Mecanix wrote:

Hi, I'm not to familiar with the background of your issues (from a quick glance there's a hundred posts to decipher, it's overwhelming), but have you posted a concise and consolidated schematic, wiring installation and pictures of your entire set-up here or anywhere else?

Without that I highly doubt anyone (here at least) will be able to remotely assist. Although the noise issue you seem to be having has nothing to do with RIO let alone Linux CNC.

Ruling out RIO and Lcnc is easy, outputs can easily be probed while running a simple gcode program.
 

Yeah, you are probably right. But I think even then remote troubleshooting is pretty difficult. I may open up another thread in the forum. But right now I need a break and look for something else. Still need to get Modbus working for my spindle. Will be starting with that soon.

if you are on the develop branch, the latest update has fixed the 5 axis plotter now!

Polling requires a delay loop , which takes time, the higher your encoder resolution and the faster your machine moves, the closer you move to missing counts. So as each loop iterates you can and will at some point drop the count. I know that the asics on a lot of the cards and a lot of the new servo drives are broadcasting position info but there are limitations on all of this. The issue is that even if we have a infintely fast loop with perfect capture, you still want your position to be fed from the interupt into a calculation that handles the machine position in realtime, and if we are being honest we really want the machine to predict the position the machine will be in and at what velocity with a feed forward algorythm to really hone accuracy. given the speed of modern processors this isn't really much of a issue these days, but encoder feedback and position feedback should be interupt driven as just a good point of design. 

Alright, I figured it out!

Thanks for your time Aciera, RodW, tommylight and PCW, your efforts might not have immediately helped me and instantly solved my problem, but they kept me trying. And in the end solving it.

the solution was to edit a line in the hal file.
I changed "loadrt trivkins" to "loadrt trivkins coordinates=xyzy kinstype=b". I have not previously seen coordinates=xyzy added to the hal in any mentions. I found it looking up where I had to add kinstype=b, since I initially added it in the ini and it didn't change anything.
Maybe this should have been obvious, but to me at least it wasn't.

Thanks again for your time and efforts, I really appreciate it!

In the interest of contributing something and not solely sucking time asking questions about problems that may well not actually be LinuxCNC's problem...

I've got a Celeron J6412 fanless PC with integrated graphics running my mill. Arch Linux, kernel 6.10.2-rt14-arch1-2-rt from the official Arch repo. Jitter is ~32000 ns- plenty good for Mesa usage, longer than I'd like. That's the result of following this thread's guidance and the usual disabling of power management in the BIOS.

My actual contribution is around video drivers. Re jitter, fbdev works great (albeit slow), the legacy Intel and KMS/modesetting drivers were terrible- latency well over 100000 ns. I'm guessing that's why you see the "nomodeset" kernel option listed. In my case, I found that disabling glamor in xorg.conf lets you use modesetting with seemingly (placebo effect?) better performance, but without any hit to jitter: