Advanced Search

Here's a short video showing how probing is setup and used  and the example is in the Flex GUI examples.


The documents page for probe are here .

JT

bentiggin wrote:

I just went through and changed all the joint 0 to joint 1 and joint 1 to joint 0.
That seems to make it work. I don't think qtplasmac is ok with y being joint 0 and x being joint 1.

This is OK in theory, but is likely to cause confusion. 

It is possible that the behaviour you see is because you are jogging before homing. (In so-called "joint mode"). This bypasses kinematics. Depending on how you are jogging this may map X to joint 0 and Y to joint 1. Keyboard jogging in the GUIs will tend to do this, but if you are button-jogging through HAL this would just suggest that the HAL connections are wrongly allocated. 

If this is what is happening you will see the XY swap before homing then it will do what you expect after homing. Which is probably a situation worth avoiding. 

For a new servo setup, I would go ethercat servos.
Sell the Mesa board (there is plenty of demand for Mesa).

I would only buy servos with software available for setting parameters and tuning.
Setting multiple parameters with the few buttons on the drive is awful.

The format of a "net command" is

net signal pin (pin, (pin, ...))

ie a signal name (which has no special meaning, and can be anything you choose) and one or more pin names (which do have meanings, are exported by HAL components, and must exist at the time the net command is issued)

You can only have one output / writer pin per net, but as many inputs / readers as necessary.

Nets can be split over multiple lines, and over multiple HAL files.

So, in your case,
net spindle-vel-cmd-rpm <= spindle.0.speed-out
Is creating a signal called spindle-vel-cmd-rpm which is getting a value from the motion module which is the commanded spindle speed in rpm, but this signal is not being connected to an output pin.

One way to get a full list of all the pins and parameters on your specific system is to add the commands "show pin" and "show param" to the HAL file after all the "loadrt" statements. Then start LinuxCNC from the command line.

To get the default pins of just the Mesa card you can run an interactive halui session (really useful for debugging)
With linuxcnc _not_ running:
If you want to actually run the card and chek inputs/outputs then you need to load, link and start a realtime thread too.

Then you can play about with "setp" and "show" to set and read pin and parameter vaues.

Use "exit" to get out when finished.

DMM
Vague memory that analog is an issue due to delay in output of the encoder signals from the drive. So closing the loop in LinuxCNC was not workable because it was too slow / delayed
(step/dir not an issue as the loop closed within the drive and there was no delay issue there)

For starters, the develop version is about to become the current stable version, meaning your next update if installed via apt will require the latest updates in the config folder. So it's in your best interest to make the changes if you haven't yet per the notification on the status page.

Probe speed is required to be the same for setting the z zero height and probing the tool, the trigger distance may be the difference you're seeing.

That said, 0.038" is a big change and sounds like a different issue. I'm not certain I follow your description of the spinle nose, and am not familiar with the type you labeled, but my guess is that somehow in your calculation something is off. Maybe some pictures? More clearly show the setup?

I think that you only get .ko files if you are running kernel-mode realtime, ie RTAI (basically).[1]

If you are running preempt-rt then the components are compiled into .so files.

But as has been said, you don't need to know where they are normally.

[1] It's possible to run RTAI kernel and user-space Linuxcnc. And also Xenomai is supprted in both kernel and user modes too.
I don't know if you can run preempt-rt in kernel mode, but it wouldn't surprise me.
However, the main use cases are user-space preempt-rt and kernel-mode RTAI.

Thank you, I will check it tomorrow.
What about this: "net spindle-vel-cmd-rpm <= spindle.0.speed-out"
It is so written in my HAL-file.
I have a problem to find out, which terms are for HAL and which are for Mesa 7i96s,
what is a parameter and what is a pin (hardware).
I assume that your "hm2_7i96s.0.pwmgen.00.value" is a parameter that Mesa wants to know or has to know. Is there any library where I can find all those necessary orders and parameters for this card (7i96s).
Please apologize if my questions are dumb, but I'm willing to learn

BR Rex

You might be able to get away with not converting the Z screw, as long as upwards cutting forces never exceed the mass of the table. Which is quite likely.

Though in the case of my Harrison (much smaller) I needed to convert because the torque required to move the trapezoidal screw was too high.
Another consideration is if you plan to use the horizontal spindle in CNC, as upwards forces are more likely then.

Ryzen 5 3500 is 6 core 6 thread CPU, so it has no hyperthreading.
Also had a Lenovo ThinkBook 14 (i think) with Ryzen 5 5500U that was perfectly OK for use with Mesa boards, tested on a machine for several days.
Now i only have a 3600 non X on a B550i board, not tested yet, but the same board with 3700X was perfectly OK.
Use bigger coolers, although series 3 and 5 do not heat much, the temperature does fluctuate at the higher end when RT is in use, so might cause throttling and subsequently latency spikes.
And if there is no need for base period, there also no need for very low latency.

DMM?

www.dmm-tech.com

I seem to recall that there was an issue with their analogue voltage control on the Dyn3 drive (I have never actually used them)
But I think that they are familiar enough with LinuxCNC to be able to advise if you contact them (they are in Canada)

Is it possible that you have a G92 or G52 offset stored?

ihavenofish wrote:

That's leadshine. A potential option here, but their prices are way too high.

Yeah, sorry for that, lack of sleep as usuall and shooting from the hip.

You could try switching to joint mode (halui.mode.joint ) then homing, but I am not sure that is preferable to unhoming then rehoming.

What is the input that prompts this? Are you literally just working at the command line, or is the rehoming prompted by a soft or hard button?

Use this
latency-histogram --nobase --sbinsize 1000 --show
You have latency excursions outside the visible area on both screenshots, and IRC you do not need the base thread.