Advanced Search

I suspect that I may have found out what is going on.

I was reading thru the setup instructions in the qt_auto_probe_tool.ngc file being careful not to
"read-thru" anything that I may have missed. This sentence caught my eye:

The following workflow assumes using both a XYZ probe and a Z Toolsetter:
;    1 - Initial Setup: Before beginning the program, setup the Probe Tool as 
;        having a zero z-offset in the tool table.

My tool table file did not have an entry for the Z-Height of zero. So I added the entry as follows:

T99  P99  D+2.000000 Z+0.0 ;3D Probe

I started the test program that I had and everything worked as intended/expected. However, as it was getting late in
the evening when I tested I tested with a much shorter end mill than my previous tool which was the longest mill in my
inventory. Today, I will retest with the longer tool and report results. I'll have to look in the code and see if I can find where
the tool Z is picked up and see if there's any room for improvement if this is indeed the problem. Hence, if the probe Z has no value,
then assume zero?

 

That reading is enough to continue testing.
Latency test can not test for every scenario/load/whatever happening in a PC, but it is a good indicator as to usable or not usable.

Grotius wrote:

Hi Lcvette,

It's indeed a alternative controller, once it finished.
This can take a long time. Some are good coding day's, some are bad coding day's without good progress.

It turned out, modifying lcnc's code to do thing's i would see accomplished is almost impossible.
Best reason is entanglement.
Then just writing new code from scratch is 10x faster to get things done.

There are no goals for me. It's just a project to try out new things wich got my interest's.

It's not the purpose to outsmart lcnc or something like that. Or claiming thing are better etc.

Altrough it is interesting to find out differences in lcnc and this approach.

Like this has bi-directional hal pins and used modern boost interprocess for shared memory.

Today did a mayor bug fix. It turn's out that multiple shared memory regions updated by thread's, would not exchange data
properly. Even when mutex etc. was set.
In the end it worked by using a single shared memory region for all thread's.
 

Sounds very exciting! like an overhaul of linuxcnc without the constraints of outdated sections.  very cool indeed!

I have a question regarding the current Trajectory planner and since you have been in it elbow deep i was wondering if i could bounce it off you to see if it may be feasible for those of use who are experiencing some pretty bad effects of it.  I don't want to hijack this thread and was wondering if we might chat in realtime?  this is the QtPyVCP chat room link below please feel free to drop in, you can ping me with @Lcvette in the room and I will get a notification!

matrix.to/#/#qtpyvcp:matrix.org

Thanks Grotius, I hope to chat soon!

Chris

Hello expert, look at the picture description, can you optimize the memory usage?专家你好，看图片描述，你能优化内存使用吗？ 

   

hard to tell what is going on without more data, maybe tell us what the work offsets were set at as well as the current dro position readings at the time of the image capture. 

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.