Advanced Search

blazini36 wrote:

A gradient would be good for something like a progressbar unless there's some other way to express zones.

Was messing with the qss builder a bit.....it definately needs an "open" function.

Also doesn't seem to be any way to apply the background colors. I assumed this would be part of "All" but it doesn't seem to work like that.

 

Gradients can be used to style buttons etc.

What would the open function do?

Can you elaborate on apply the background colors?

JT

No not all the realtime code is there (it is a very confusing situation, mainly thanks to tech bloggers, and other sundry types that aren't trying to build a fully preemptive arm kernel), there are still patches up on kernel.org. Without the patches at kernel.org there is no way to select a fully_preemptible kernel (and another one if working on the 6.1.69 kernel). The highest level you can chose is a low-latency desktop, but this is not the model really required for realtime. In another thread I post the differences between the different kernels, forum.linuxcnc.org/38-general-linuxcnc-q...6-12?start=30#318731

This has been a bit of a headache all weekend, I've built a successful image using the 6.1.y branch (unfortunatley first attempt didn't include the Linuxcnc binaries), the commit chosen is 6.1.69, the latest commit on that branch doesn't have a corresponding patch set is available.

I tried with the 6.12.y branch, but there was an issue with the build of the final image.

Finally working with the 6.1.y branch and the 6.1.69 commit it appears that I have a successful image, with the Linuxcnc binaries and spi turned on as default.

I think one reason for "rolling our own image" is to get away from any RPi Foundation branding. Another reason is that we can insert our own modifications in as well.

Note that some drives (even high quality ones like mitsubishi and yaskawa) have a noticeable lag in the simulated incremental encoder signal when using position loop.
forum.linuxcnc.org/10-advanced-configura...pain?start=30#193073

Absolute encoders should be very accurate but you may struggle to get the encoder data into Linuxcnc (ie to get the multiturn AND motor position ). If it does not offer the multiturn information then you would need a second signal from the rotary to indicate the correct rough orientation for the motor position to be valid. This would be very accurate if you can get a good index signal from the drive.

As an alternative you could also mount a separate incremental encoder directly on the rotary axis and use the encoder index signal for homing.

Yes but we were talking about 6.12 and up, of course for 6.1.x you still need patches.

Я сделал конфигурацию через pcconf, но linux cnc на нем не загружается. Если я загружаю конфигурацию с одной платой, то запускается linux cnc. Должен ли мой компьютер иметь два порта LAN для подключения двух плат?

 So is there a bug in the PREEMPT_RT support in the 6.12 kernel, or is it simply not implemented the way LinuxCNC has come to expect? Obviously LinuxCNC needs to support a working standard.

This conversation is a bit confusing because rodw and I are doing different things to get the same result.

I am starting with Raspberry Pi OS, switching to their 6.12 branch then building the kernel to enable PREEMPT_RT. I'm doing this because they don't have a kernel build of 6.12 with realtime enabled yet.

rodw is starring with plain Debian and using a build system to create an image for the Raspberry Pi.

Sidenote: all realtime code is merged in upstream 6.12 now, but you still have to enable it at build time with a configuration option. There's no way to turn realtime on and off after it's built. 

What version of linuxcnc are you using?
Can you post your config files?

How is the path displayed wrong?

I have setup a knee mill with qtdragon_hd within these limits in mm
X 0min 950max
Y -380min 0max
Z -400min 0max

But does not display in preview correct the path.
How can config this?
also does not show me in manual mode
spindle set rpm slide bar and spindle override rpm
 

camb0 wrote:

I assume you posted some info on your 4th axis build so I'll do some reading up on the homing.
 

I can't remember if I did or not, but the homing wound up being pretty convoluted because I was out of HS encoder inputs and had zero room to stuff another Mesa board in the enclosure.

• Solution - use the drive's internal home-to-encoder-index function (Copley XSL)
• I wound up using some relays and HAL logic so that when I pushed the "Home-A" button
  • LCNC sets home (i.e. G53 A0) without commanding the drive to do anything
  • joint.3.homing sends an output to trigger the A-drive to home itself
  • When the drive finishes homing, it sets an output that's connected to joint.3.home-sw-in

It works, and is like a low-tech version of the absolute homing the Ethercat folks use to 'trick' LCNC in to behaving with hardware capable of external homing.

If you are still having problems installing, I suggest you first uninstall all possible previously installed keys and repositories:

and then run the script from the first post.
Or you can run the updated script, which will do this immediately. I've attached it.

What have you set as your tool diameter and how much is 'too small'?