Advanced Search

You need to "addf" carousel.0 too.

Though stuck on "reading" maybe hints at a file access problem.

Is there plenty of space on the SD card? Are the G-code files on the SD or maybe on a network drive?

I don't know if probing waits for spindle-at-speed. It might.

Have you checked the signal with halmeter?

In that case things may get a little complicated. It comes down to how the controller gets its position information. Often the drive will excite the resolvers, use them for commutation, and then pass a quadrature signal out to the rest of the system.

The Mesa 7i49 and (I expect) the Granite devices drives expect to be providing the excitation signal, and will typically sample position at or around the peak in the excitation signal. If the controller is also sampling this signal for position feedback then it's going to get complicated.

Do you have any details of the drive to motor and drive to contoller wiring? Is there any motor-to-controller wiring?

The 7I92 outputs can be sourcing or sinking depending output polarity
But they are push-pull 3.3V outputs. They will swing to 5V if they have
no load as they have 4.7K pullups to 5V.

Hello everyone,

I would like to revisit this topic.
The component has been working very well and reliably for three years now.
Unfortunately, I have already broken the spindle support twice, but this was not due to the component itself, but rather to the compressed air in our workshop.
I would therefore like to install a position switch to check the position of the cylinder and ensure that it is actually retracted.
To do this, the component would need to be expanded with an additional pin and a query.
Now my question to you, or rather to Rod, is whether you could help me with this again?
This is the current Comp file:

I keep meaning to write a documentation section about toolchangers, as they are a frequent cause of problems, but despite being the author of the carousel component, I don't actually have a toolchanger on my own machines.

This would be a complete bodge, but what happens if you just double the pocket number before sending it to the carousel component?

Can you describe exactly what feedback pins you have from the toolchanger hardware, and how they behave during a change?

I've looked again at the probe basic sim options...

Firstly, when I launch linuxcnc and the configuration selector comes up, under Sample Configurations > sim there are entries for other guis but none for probe basic. (It seems like that is where I should find the sim).

Instead under My Configurations there is:
probe_basic
> pb_required_ini_settings
> probe_basic

I think the last one is what you are referring to as the sim.

(I also have the probe_basic config I've been trying to get working but saved under a different name).

When I run that thing we are calling the "sim" it shows me the probe_basic screen and gives no errors. On the main page I can move the virtual spindle with the jog buttons.

However, I can't load a tool onto the spindle and all of the probe operations are greyed out.

Edit: I deleted the pb_required_ini_settings file and that option disapeared from the configuration selector. I also managed to load the probe into the spindle in the sim (which stopped the the probe operations being greyed out). However probe operations failed due to not hiting anything before the maximum distance. (which I guess is expected because it is a sim)?

So, I think the sim is working. Am I supposed to test more than this? If so, what?

I would be curious to see if the problem also exists with the v2 macros, but I don't know if they even work at all on 2.9 (it will depend on the Linux version more than the LinuxCNC version I think)

This feels like a problem with the embedded tab handling in the GUI rather than directly with the lathe macros, though it is entirely possible that, through ignorance, I am doing something wrong in the handler code.

Keyboard jogging issue
www.forum.linuxcnc.org/38-general-linuxc...elocity-fluctuations

The logic looks fairly simple, and is here:
github.com/LinuxCNC/linuxcnc/blob/2.9/sr...otion/control.c#L716

That only fails if "if (emcmotStatus->probing) {" (line 691) is false.

The confusion here is that I don't see any change in state in your motion.probe-in channel, it doesn't actually appear to be bouncing (or maybe only not in the plotted example?)

I don't know for sure that "SET_MOTION_ERROR_FLAG(1);" (line 726)drives motion.coord-error but it might be worth plotting that too.

As an experiment, is it all OK until you enter a decimal separator?

Do you definitely have a linuxcnc.var file in the config directory (ie the directory that the INI file is in?)

If you "ls -al" the config folder, do all the files belong to the same user?

There is something funny going on here, and it's not something we have seen before.

Unfortunately the documentation needs to be written by someone who understands how the configuration is supposed to be done. So, I can't help with that.

I saw that you had previously recommended testing the sim but it isn't clear how that is helpful. Does the sim work - well no, it doesn't control my machine, it can't do anything. It doesn't give any errors if that is what you mean?

Obviously most errors are going to be introduced by mis-configuration. But that problem will persist until the process is well documented.

Is it the intention that the user attempts to enter his machine specific configuration into the sim? If so, I missed this step, was it actually part of the instructions?

For the best chance of success, with the current code state, should I be trying the develop version then?

I did notice that when I tried to open one of the files it told me that it couldn't locate the src files (including these was not part of the normal install instructions).

Just to explain what was going on previously.

The config is set up with closed-loop control of spindle speed, using a PID component. You can look up PID elsewhere, but most references will tend to overcomplicate it. They have existed since long before digital computers. You run a PID controller in your head when you drive a car. Feedback is looking at the speedo, the command is how hard you press the pedal, and the output is how much power the engine makes.

To stretch the analogy, in your linuxcnc config you have a speedo that goes negative, but you are stupid (as you are a computer) and when told to do 70mph in reverse you see -70mph on the speedo, think "that's 140mph less than 70mph" and press the pedal to the floor.

You have to ensure that the domains of the signals are the same. If you are using single-sided speed command (spindle.0.speed-out-abs for example) then the PID neds to see a single-sided speed feedback, typically achieved by passing the measured encoder speed thorugh an "abs" component in HAL.

You might find it instructive to browse through the available HAL components, they are fundamental to the flexibility of lInuxCNC as you can do all sorts of manimpuations on the input and output signals.

You can see the list here:
linuxcnc.org/docs/stable/html/
if you scroll-down to "Realtime components and kernel modules" and (to a slightly lesser extent in this context) "Commands and userspace components"