Advanced Search

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）

Doesn't have an option for setting LANGUAGE.

Had to use
Then log out and login for it to take effect.

Thanks, that image was prepared by James Walker (Joco) one of the qtpyvcp developers.
All of these features can be set using sudo menu-config which brings up this menu.

 

Just checked out your new image that you linked a couple of posts ago. Video works ok when using min hdmi to DVI adapter.
Just for those of us that are a bit silly what is the correct procedure & values to setup
1: LANGAUGE (currently unset)
2: LC_ALL (currently unset)
LANG = "en_AU.UTF-8" is fine.

Currently starting to test the new hm2_spix driver

Oh, yeah. so i was wondering if my assumption is correct, in that i am having trouble because of the ethernet controller...
Do you know of any reason that the intel nics would be an issue?

Hello 
i have been using qt dragon HD and like it. 
i would like to add some buttons to my screen and was looking for the directions or a resourct to help me. 
i have three things i want to add.  
i have a work light
a spindle light
and a relay that switches between my prob in put and my tool setter.  both the tool setter and probe are normaly closed. seamed like the best way to do it. 

i could put them on a tab or in utilitys.  but still a littel unclear on how to do that. 
thanks for the help.  


 

Masterdrive wrote:

scotta wrote:

Hi, there is no cpp source code for the NVMPG. I decompiled the extracted firmware and managed to find the serial transmission section. The communication protocol was derived from that. The attached spreadsheet simulates the protocol. You should be able to use that for your purpose or alternatively look at the code of the NVMPG LinuxCNC component.

github.com/scottalford75/Remora-NVEM/blo.../MPG%20protocol.xlsx
Hi Scott,
thanks for your time and dedication.
I've owned a NVEM 2 since 2018, but buried it long time ago since I was not able to make it work reliably.
www.cnczone.com/forums/controller-cards/...084.html#post2154084
At that point in time, and till now, I've been using Mach3 (yeah... no LinuxCNC... i know...)

2019, after migrating to an UC300ETH controller, I tried to make the MPG work with Mach3 without using the NVEM.
I didn't want to waste such a nice MPG.
At that time, I did some reverse engineering... not as professional as you did... mine was mostly trial and error and listening to the serial communication between the MPG and the NVEM after opening it and finding a MAX232. I captured hundreds of packages, and tried to find the similarities on what was displayed on the MPG and what was within the payload. I almost got the payload down to your level.
I was too dumb to know about headers and such -_-

I also tried to create an Arduino program for having the MPG communicate with a PC using MODBUS.
But again, I was too dumb to find a smart solution, like having the Button-presses being reflected as Output-Pin changes on the Arduino, and hook those up to my motion-controller. Or using the Arduino Pro-Micro as a HID. Instead I tried to make the communication work with MODBUS and Mach3 "Brain", which resulted in a complex, and unreliable solution.
So I buried that solution almost 4 years ago as well.

That being said... I'm surprised about the NVEM still being a topic after stumbling about this thread by accident.
Would you mind if I would revive my idea of a NVMPG to PC connection, utilizing some of the "wisdom" you've gathered throughout the years?
Don't get me wrong... I'm an "enthusiast", far away from being an "achiever", my programming days are more than 20 years in the past now... but it's been bugging me a lot looking at this "unfinished project" (a lot of them exist though -_-)

Kind regards,
David

Hi David, 
No problem from my side. This is exactly why I love open source projects. One builds from another.