Advanced Search

After installing Wheezy the jitter reading is 24899 - much improved. interestingly after all the BIOS changes the installation process took much longer - but it worked .
Do you think this reading is good enough to proceed with this computer in its current state?

I've also continued testing and haven't made any progress.

and the m6 doesn't work under basic probe. It always tells me that the pin  #<_hal[qtversaprobe.searchvel]> doesn't exist.

I just found out that Flex GUI works on Gentoo!

JT

Yes, you can add a checkbox to disable the program view.





JT

Debian dpkg-buildpackage uses perl, perl complains when running menu-config without LANGUAGE set.

So perl hasn't anything to do with Linuxcnc but when building packages, I had to build linuxcnc to have the hm2_spix driver for the Rpi5.

I am following the steps from:
linuxcnc.org/docs/2.9/html/code/building...ding_debian_packages

but how can I disable GTK2 for the debian package build like I can do with "--disable-gtk2" for the normal build?



 

Why on earth are we using perl in a Linuxcnc project? What's wrong with Python? At least its supported by the project.

G05
High-speed and high-precision control Ⅰ
G05 P10000 High-speed and high-precision control opening
G05 P0 High-speed and high-precision control off
G05 P3 High-speed machining on
G05 P0 High-speed machining is off

G05.1
High speed and high precision control Ⅱ
G05.1 Q1 High-speed and high-precision control on
G05.1 Q0 High-speed and high-precision control off
G05.2 Q2 X0 Y0 Z0 Free-form surface high precision mode is on
G05.1 Q0 Free-form surface high precision mode is off

G05.1 Q1 R1 - coarse high-speed processing,
the feed at the corners does not change,
the corners are cut off, the contour does not correspond to the set one.
G05.1 Q1 R5 - high-speed processing, speed-quality balance,
deceleration at the corners, corners can still be cut.
G05.1 Q1 R10 - precise high-speed processing, significant deceleration
at the corners, the corners are not cut off, the contour corresponds
to the one set within the accuracy of the machine.

G64 P 0.01 may help. I think the professionals will correct me.

The RPi 5 has, from memory, has "engery saving malarkey" for it's ethernet, and no it's not on the USB bus, that foolishness was ended with the RPi4 I believe.

With regards to the mesa firmware....it's solid and reliable, a mesa card will need it's firmware updating as often as a Toyota Echo does for it's ECU.

Remember we aint in the Windows world.

Build each version as a Run In Place (RIP) setup.

Check the docs if you don't know what that means.

Perl complains if LC_ALL or LANGUAGE isn't set.

I recently commented on the absence of MDI queuing and Run-From-Here in the AXIS 2.9.1 release on my RPi4 B mill.

I tried going back to 2.8.4, but that seemed a retrograde step.

So I made a new 2.9.1 Gmoccapy adjacent to the AXIS on the same SD card for testing.
The queuing is there, not sure yet of the Run-From-Here.

Both AXIS and Gmoccapy seem to operate independently quite OK.
But, during stress testing of the queuing, I got an occasional Following-Error which prompted me to start reviewing HALShow and HALScope for assistance.

It was then that I realized that Gmoccapy uses names for the various files identical to that of AXIS.

Is it wise to re-name all the Gmoccapy files so that they are different to the AXIS names ?

What is the best way to arrange two or more LCNC versions so that any one can be selected ?

Keep well,
John.

 

The enable outputs and input common are still not right
The drive enables could be wired in parallel as there is typically
no reason to drive them separately

Parallel Drive enable wiring could be:

+5V --> OUT0+
OUT0- --> all Drive ENA+
GND --> all Drive ENA-

I think you're saying I can (and should) run all enable+ in parallel from output 0 and all enable- in parallel to GND for drive 0? Teknic previously advised me that I can tie enable-, step- & direction- together, but you said I should not do that on the 7i96s so I figured I would just give each input and output its own wire since I'm connecting all of this with a 64-conductor DSUB cable and I don't need to save on conductors. Obviously I am going to do it whatever the right way is, and I just need to figure out what the right way is, because there is no guide.

I don't fully understand what you mean in the first and second lines: +5v --> OUT0+, and: OUT0- --> all Drive ENA+. If I did not get it right above, can you elaborate what you meant?

The default  settings come from userdata.txt github.com/rodw-au/rpi-img-builder-lcnc/...9.3/userdata.txt#L40
I.m not sure LANGUAGE  needs to be set for the locale if its en_US.UTF-8 as we use for the default config 

On my chrome book,  locale reports
rod@penguin:~$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

On my Debian PC in my office, I get 
rod@debian:~$ locale
LANG=en_AU.UTF-8
LANGUAGE=en_AU:en
LC_CTYPE="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_PAPER="en_AU.UTF-8"
LC_NAME="en_AU.UTF-8"
LC_ADDRESS="en_AU.UTF-8"
LC_TELEPHONE="en_AU.UTF-8"
LC_MEASUREMENT="en_AU.UTF-8"
LC_IDENTIFICATION="en_AU.UTF-8"
LC_ALL=

 

Hello expert, can you optimize the problem of large capacity G-CODE occupying more memory?（Turn preview on and disable preview）