Advanced Search

Just to be clear.
The ipv6 issue is related to the installer, but a little bit of a search provided a fix.
The bottom panel issue was from the linuxcnc-live-build repo.
Neither issues were the result of the utility used to write the image to the the installation boot device.

If any would like to help in testing, as I can only test with the resources I have on hand, if no one is interested I'll let it drop and wont bother making a pull request, as I feel it would be untested to a decent degree.

I don't see that on my development system.
Is there any difference with different stylesheets?

Are you using the auto tool length probing on your machine?

Get the image from here
www.linuxcnc.org/iso/rpi-4-debian-bookwo...23-11-17-1731.img.xz
Write the image to a micro SD card using this
www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/
plug the micro SD card into RPI4
power on
enjoy

FlaredFins wrote:

Switch is at the top most portion of Z axis.

If that is the case then your ini settings should be one of  these , during homing Z moves to the top (switch) then to complete homing it moves 0.125" down which is the home position. If these don't work then something else is wrong.
I assume when you press the Z+ jog button then the Z axis moves upwards.
Does you home switch stay activated if the Z axis is on or past the home switch?

Grotius wrote:

@All,
I started making...

I think this output is a nice result for today. Now what should be done better?

Great job!

You can test 3D surface G-code with a large number of points. Its original surface is very smooth, without a sharp change in the direction of the tool path, which tells us that the speed graph should show a smooth speed without jumps, close to the maximum. Stops and speed changes create milling defects on the surface of the material due to shaking. 

One important metric could be comparing code execution time with the old planner and other cnc - it is obvious that S-curves are slower on a trajectory with sharp corners, but on smooth surface in theory there should not be a very big difference. (as an example, a strong difference in execution time can be seen in the graphs in the message - these are the consequences of not compressing small segments into one overall curve with smooth acceleration - a separate S for each small segment increases the overall acceleration time.)

I can share a test G-code similar to the one used in real work, which I used to adjust the PQ parameters of the post processor. There are several types of operations(adaptive and surface finishing), and several variants of the same trajectory, but with a different number of points = using different parameters P. The execution time of the code at a fixed acceleration and speed is also written in the comments. (10k-200k lines, ±5min machinig time)
drive.google TP g-code tests




There is also a list of plans for the future:

2) We need to figure out how to solve the problem of mixing linear and rotary axes at the same time - this is a big problem with the current planner - it does not do smoothing when connecting any rotary axis, and this problem does not allow working with rotary axes at sufficient speed. A solution to this problem has been requested by all A/BC axle users for many years...
The question may arise: how to calculate the geometric accuracy of this path?
after all, smoothing with a certain tolerance may require inverse kinematic transformations. But I know that many take into account only XYZ axis tolerance, and separately speed-acceleration and angle tolerance limitations for each ABC axis. Maybe someone can give some ideas...

Another feature: when using rotary axes, inverse time feed G93 is usually used - which sets not the speed, but the execution time of each line of code = for synchronous movement of linear and angular axes. Without G93 it is impossible to control them simultaneously, because F1000 mm/min ≠ 1000degree/min. 
Can calculating the average speed for each section complicate the compressor and planner algorithm?
g93-g94-g95
I also shared a couple of these files for tests.

3) The linuxcnc interpreter has support for interpolation G5 Cubic Spline, G5.1 Quadratic Spline, G5.2 G5.3 NURBS Block - They are not so popular, and there are few CAMs that can generate such code (mastercam and siemensNX can do this, with the corresponding post-processors), I'm not sure if they have an advantage over a good polyline smoothing algorithm, but at least it allows you to use less code to describe the curve. so it would be nice to use them for backward compatibility, maybe someone will need it...
g5-g5.1 splines, g5.2-g5.3 nurbs

One day I experimented with them, and recorded the log of speed and acceleration using them - it's similar to S-curve)
 

Also is there a way to change the Velocity position and Size on the screen?

Position - not easily (it's an open source project so there's usually always a way)
Size - yes. Follow these directions: linuxcnc.org/docs/devel/html/plasma/qtpl...#_add_a_custom_style

inside of qtplasmac_custom.qss, add these lines:


That will change the size of the VEL: label and the indicator to 14pt font, in this case.

Oh and switch the Buttons on the Jog like switch + and - 

Again, no, not easily. but why would you want to? The X and Y indicators in the preview point toward X and Y positive. The GUI buttons follow as pictured below:



To do anything else would be ... wrong.

Maybe you are expecting the table to behave differently given the orientation of your control console. In that case, .ini file changes are in order....

This part shows how to compile and copy the kernel where it needs to go.
 

Franklin wrote:

Hi, I recently built my new plasma machine with touchscreen control.
And in the process of settings, I discovered some inconveniences:

1. Tooltips are not shown when you use only the touchscreen (see the video 1).
2. Would like to have the zoom buttons in the preview on the  Conversational tab like on the Main tab.
3. The probe button does not work as it should, it is deactivated immediately after pressing it. (see the video 2).
4. Would like to be able to turn off the PC from the dialog when the holding the POWER button in qtplasmac.
5. It is impossible to delete the machine log without a computer mouse.

 I noted these inconveniences during the last month of working on a touch monitor without using a mouse and keyboard.
But overall I like using this program and will continue to test it on my machines. Thanks Phill and all the developers.

I tried to duplicate your issues on my VM with a touch screen. I do see that tooltips don't really work that great, but this is due to how PyQt5 handles touchscreen events in conjunction with tooltips and we have no control over this as we don't actually handle the tooltip events/triggering, etc., we just populate what the tooltip should say. Not really a fan of tooltips anyways, I think you can get FAR more information from reading the rather comprehensive manual we put together. Most of the buttons and controls are fairly self-explanatory.

We did push changes to add #2 above, as soon as the build-bots are done build-botting, you can update and enjoy.

As for the rest:

#3 - This is specific to your setup, be it the monitor, or the OS choices you've made. The probe button works as it should here with touch screen. I believe Phill confirmed this on his end too.

#4 - I will see what can be done down the track about adding this option. I'm not sure it would be a big deal but it's not really a priority either.

#5 - I don't understand what you're saying here. You can't delete log files from inside the GUI - this is by design, and not likely to change. If you're talking about deleting the log files outside of QtPlasmaC then I'm not sure how to help you there.

Yes, there is motion.is-all-homed pin, but is not writable.

Tried with setp motion.is-all-homed true

So where would I need to copy it to? I created my own directory I called rtkernel that the kernel that I compiled and did the menuconfigs on.

I used the documentation that you linked to figure out how to add the patch and compile the kernel but it was not working so I followed another "tutorial" on YouTube.

How would I copy it to boot? I did reboot the pi to boot into the new kernel but do I need to boot into it any specific way other than just rebooting or shutting down, unplugging and booting it?

Mostly because this is the first time I've ever done it and tried to follow a "tutorial" video on YouTube. If there is an easier way I am all ears. I tried to piece it together from posts on here and from things I watched trying to do it. I feel lost in this aspect of this project.

what happens if you remove init commands?
so that you will have onlyin your ethercat.xml file.

second try would be:
refClockSyncCycles="-1" and reorder, so that EK1100 goes first and DeMS300 second (you have to swap ethernet cables as well)
then
1) run in terminal ethercat slaves (post screenshot)
2) launch linuxcnc
3) re-run in terminal ethercat slaves again and (post screenshot)

also what ethercat master device are you running? generic?

That's too bad, if it would've improved the result I could add the WiFi driver, but if it doesn't show any difference you can remove it by first boot the previous kernel manually by selecting it in Grub at boot, (the grub menu can be quickly gone so press the arrow keys a few times at boot). Then:
sudo apt remove linux-image-6.10.0-rc1-rt1

After removing it should automatically update grub and select the previous kernel.

Sorry, you did not mention it is for parallel port lately, i now recall you did that on the first post.
In that case try installing the RTAI kernel, should be better for parallel port.
There is a howto on the downloads page.

It sounds like you just didn't copy the newly compiled kernel to wherever it needs to go to boot. Also, you need to reboot to boot into the new kernel. www.raspberrypi.com/documentation/computers/linux_kernel.html