Advanced Search

I am new to LinuxCNC, so please forgive me if this has already been answered.  I searched and could not find it anywhere so am asking here.  (I always hate on other forums when people just jump in with questions before searching.)

I have a 7i92TH connected to a Raspberry Pi 5.  The use case for it is for rose engine lathes, and we need to drive a spindle + 7 axes.

The break-out board we are using for both 26-pin outputs from the 7i92TH was developed using the input from Peter.  Fundamentally, we will have

• 8 outputs to drivers, all with Step, Direction, & Enable
• 7+ inputs for limit switches

Peter W. got us setup with the files needed to program the 7i92TH, and that seems to be working as expected.  When I run

         mesaflash --device 7i92t --addr 192.168.1.121 --readhmid

the output matches the .pin file supplied by Peter, telling me that the mesaflash --write command worked to load the .bin file supplied by Peter.

When running pncconf:

• I've tried with copying the contents of the .pin file into the Input tab on the Help screen, and not doing this.
• I was able to successfully discover the 7i92TH board, and it populated the Output tab on the Help screen (I didn't check word-for-word, but it seems to be duplicate of the output from mesaflash --readhmid).

When I want to proceed forward, assigning the pins to axes, I encounter the screens I've attached.

ISSUE for which I'm seeking help:  I can't figure out how the Num items (pin numbers?) match up to the .pin file.  What am I missing?

gekonko wrote:

hello hmnijp,
could you please elaborate on that? 
I have tryed to comment out this section of the code in interp_arc.cc and then make the build, but I still get error message.

CHKS((abs_err > spiral_abs_tolerance * 100.0) ||
          (rel_err > spiral_rel_tolerance && abs_err > spiral_abs_tolerance),
      _("Radius to end of arc differs from radius to start: "
       "start=(%c%.4f,%c%.4f) center=(%c%.4f,%c%.4f) end=(%c%.4f,%c%.4f) "
       "r1=%.4f r2=%.4f abs_err=%.4g rel_err=%.4f%%"),
       a, current_x, b, current_y, 
       a, *center_x, b, *center_y, 
       a, end_x, b, end_y, radius, radius2,
       abs_err, rel_err*100);

 

The simplest solution with minimal changes is to fix the upper limit in "interp_internal.hh" file:
#define CENTER_ARC_RADIUS_TOLERANCE_MM (2 * 0.01 * M_SQRT2)
for example
#define CENTER_ARC_RADIUS_TOLERANCE_MM 1.001

after that the setting in the ini file will allow to set a higher value than before 

Krulli_Fräser wrote:

I can't rule out moisture.

However it's curios that the computer boots up fine but then crashes and once I take it inside it's running just fine.
 

Frost melting when first turned can have this effect, Beware that too long operation with actual
liquid water from melted frost can cause permanent damage due to electrolytic corrosion.
 

ok, I got it, there is section for error generating with and without compensation.
thank you.

I can't rule out moisture.

However it's curios that the computer boots up fine but then crashes and once I take it inside it's running just fine.

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:
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.Add the following line:

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.
I named it rrt (run real-time). So to launch latency-histogram it's simply:
All spawned sub-processes inherit the policy and priority. So if linuxcnc is launched with rrt: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.