Advanced Search

Thanks for the feedback
Yes =>  inductive sensor
Yes=> position sensor for the ram/cylinder
Yes=>Maybe using the values from that sensor to home or to check and retract the ram at LinuxCNC start

I am currently in the electronics lab, I will do some simulations and post them here for everyone to see. And when I go to the machine I will already have a theory to be applied. Thank you very much to everyone, I am available if anyone needs any more information about this machine or the process I am doing with the electronic boards from the manufacturer Mesa 7i77.

 

I will attach the technical data in case anyone needs to work with this type of machine.

 

 


Repeat accuracy ± 10 µm
Voltage output 0 ... 10 V

​​​​​​​note: I used google translate, sorry for any inconsistency

Hallo

ich habe einen Lichuan TLC57-E-36V-3
Vorerst nur den einen.
Mit der der *.ini und *.hal hab ich ihn mal zum laufen gebracht, nur eben die scalierung habe ich noch nicht einstellen können. Aber viel dank für eure hilfe!   

Iv got a pawn  

youtube.com/shorts/vlgv4FAAmmc?si=jZdAi8ldJxhEXNjL

Hi guys, I've tried a few things with these drivers, they work relatively well, but they are quite expensive and there are no new ones.

I was thinking of using an h-Bridge, could you recommend some, the motors have powers of 200W 48V 4.2A, thanks in advance, greetings

Tried this one, unfortunately same errors. 

I live near the winds and the fires in Pasadena, California, and after the sudden power failures (several trees made spectacular messes all over our neighborhood, so it was a sudden spike-outage: also fried my fridge) my CNC mini-computer has taken to randomly rebooting.

So I ordered a replacement mini computer, and repeated all my installation steps, except for a scratch re-make of pncconf.

Instead, I copied back all the config files, directories and symbolic links from the old computer (it still runs, just inconsistently).

But at the end of everything, I get this error report and I'm stuck.

I was able to get a version of QtDragon interface to run (as far as actually displaying on the screen, haven't run the machine yet) by going through the pncconf process...
... but I will have to make a lot of changes to get back where I was, so I was hoping to make that restore route work.

If anyone can take a peek at this error report and have an insight into what I've screwed up, it would save me a bunch of time.

If not, then time is what it will take ;-/

Thank you all!

Vector

As you'll only be able to run in simulation mode and you just want to get familar with Linuxcnc an arm install will be fine.

After doing a quick read I'd research the following:
Is Debian Bookworm able to be run. The kernel versions and X server versions seem to be limited.
Is the Kernel version that is on the Linuxcnc iso compatitable ?

Part of the hole processing smarts is in the qtpyvcp code base.  In the programe used by monokrom to parse out the incoming gcode file and adjust it if necessary.  I still want to come back to this and refine/improve it.  Just on a long list of other things in life to see to.

tommylight wrote:

This time you can blame it on me as if i recall correctly, Parallels is the software running on Apple hardware and makes it possible to run other operating systems in it, in short running virtual machines.
If that is correct, then all my answers are on point, it should run any ISO without making images on other hardware, that is the whole point of it.
Then again, it is Apple, so maybe only runs ARM stuff?
 

Both links I included explain in explicit detail why I need someone with an Intel Mac and Parallels to create a VM on that hardware for me load into my Apple Silicon Mac. It was, and still is, all that I need to try out x86 emulation in Parallels 20.2.

Changing the Z-axis accel only slightly affected the rapid distance, if at all.

The earlier tests were done with MAX_VEL = 4, and MAX_ACCEL = 175.

Dropping down to MAX_ACCEL = 2 resulted in approximately the same pre-synch rapid distance at all speeds.

Much less violent rapids, of course.

Update here:
forum.linuxcnc.org/38-general-linuxcnc-q...blem?start=10#319865

So my lathe's behavior is closer to the OP's when running a program vs. MDI.

But as I mentioned in the other thread, I don't think this behavior is correct even with the reduced 'dive' towards the synch point.

Thanks for the troubleshooting suggestion.

Yes, same behavior, but much less Z-distance during the initial 'dive' than when using MDI.

Approximate position the Z-axis rapids to before synchronization while running a program:
G33.1 Z-0.5 K0.05 $0
(Starting at Z0.500")

• 60rpm: 0.440"
  • rapid dist: 0.060"
• 100rpm: 0.390"
  • rapid dist: 0.110"
• 200rpm: 0.370"
  • rapid dist: 0.130"
• 400rpm: 0.300"
  • rapid dist: 0.200"
• 750rpm: 0.140"
  • rapid dist: 0.360"
• 1000rpm: -0.125"
  • rapid dist: 0.625"

So perhaps 1/4 the distance vs MDI.

Still don't think this behavior is right.

Have you tried menu-config to configure the wireless network ?
will show whats happening with the wireless network during connection, then you can use google to search for any issues you see, eg associating, disconnection and the like. As this will be a general Linux issue.

gene_weber wrote:

Rather than starting a new thread about jitter mitigation, I'm just going to add it here.

First, I'm keeping in mind that Peter Wallace said " The jitter is basically unimportant with a 7C81 unless its so bad you
get real time errors at the normal servo thread rate."

I'm also treating the Raspberry Pi + 7C81 as a dedicated controller, not a PC. By that I mean I'm not going to be doing anything on the Pi except LinuxCNC. I may turn on WIFI to update packages, or use email to transfer a file. But I plan to even turn off WIFI before I launch LinuxCNC.


I ran several tests to see which combination of settings offered the most optimized jitter. I ran two Glxgears for all tests as I though that was reasonable, and ran the tests for long periods of time unless they looked bad early on.

I thought that turning off all unused services would decrease Jitter. So I turned off 9 of the 23 services, such as CUPS, Bluetooth, etc. To my surprise this did not decrease jitter.

Screen blank increased jitter a bit, so I turned that off. It doesn't make much sense anyway on a CNC controller.


These are the settings I added to the line already in /boot/firmware/cmdline.txt:

skew_tick=1 kthread_cpus=0-2 irqaffinity=0-2 rcu_nocb_poll rcu_nocbs=3 nohz=on nohz_full=3 isolcpus=3

I tried a few others that some people recommended on various blogs. Nothing else I tried had any noticeable positive impact on jitter, and some noticeably slowed down the responsiveness of the Pi.


Turning off timer_migration did reduce jitter. What I read said that you could make this setting permanent by adding it to the boot command line, or setting it in either of two different system files. Oddly none of that worked. So I setup a cron job to disable it at boot, and that works.
[code]crontab -e
Add the following line:
[code]@reboot sudo sysctl kernel.timer_migration=0


The other thing that helped reduce jitter was changing the scheduling policy to real-time and increasing the priority. I decided to create a shell script to launch latency-histogram, and eventually linuxcnc, which changes these things on the process.

[code]#!/bin/bash
#
# Run with the SCHED_RR real-time policy at the highest priority level (99)
# Uses chrt to switch the process policy and priority immediately after launch.
#
# Gene Weber - January 2025
#
# "The difference between SCHED_FIFO and SCHED_RR is that among tasks with the same priority,
# SCHED_RR performs a round-robin with a certain timeslice; SCHED_FIFO, instead, needs the task
# to explicitly yield the processor." -Claudio

priority=99

# Truncate $1 (the command) to 15 characters starting at 0.
command=${1:0:15}

# Execute the command line provided to rrt as a background task.
`$@` &

# Get the process ID of the command.
PID=`pgrep $command`

# Change the real-time policy to SCHED_FIFO with a priority of $priority.
sudo chrt -r -p $priority $PID


I named it rrt (run real-time). So to launch latency-histogram it's simply:
[code]rrt latency-histogram --nobase --sbins 1000

All spawned sub-processes inherit the policy and priority. So if linuxcnc is launched with rrt:
[code]rrt linuxcnc
all of the processes that are part of LinuxCNC have the policy of SCHED_RR and priority of 99. I used Round Robin scheduling to make sure no LinuxCNC process "starves" another.

I don't know if this will work in the end, but I'm going to give it a try. Nothing ventured, nothing gained.

Implementing all of these, here is the jitter histogram. Good enough.
[attachment=67004]final-16Jan2025-3117.png[/attachment]
 

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

 

I think it's just easier to isolate 2 cores, it really doesn't affect performance. And reading the docs, mainly pertaining to amd64, the general rule is to isolate cores on the same physical die, for reason beyond my pay grade.

One thing that might be worth of note, as development moves along, is to check the Makelfile in the top of the directory as minor revisions can change for the the rpi-linux kernel.

Or you can run