Advanced Search

Today something strange happened to my setup. I was tidying some cables up in the control cabinet and must have fried something.
I have been running my machine for about a year now without any problems. 
Now my Y encoder readout follows my X axis. Even when I disconnect the encoder from the 7i77 it happens.
Changing from hm2_[MESA](BOARD).0.encoder.01.position
to hm2_[MESA](BOARD).0.encoder.04.position (and updating the other encoder lines from 01 to 04) and plugging it in encoder 04 position did not work.

X Z still works though. Spindle encoder reads nothing, although the actual encoder is functioning.

Have i fried my 7i77?

/Peter

Use the example configuration as a starting point and then add your hal configuration for end stop etc as you need.

github.com/scottalford75/Remora-RT1052-c.../remora-rt1052-basic

does "sudo mesaflash" get any further?

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.