Advanced Search

spumco wrote:

tommylight wrote:

Probably here, as far as i can tell, everything else will inevitably lead to here, and google still seems to find the forum easily.
What do you think about a new subfolder?

• Configuring LinuxCNC
  • HAL
    • HAL Examples
    • User-written HAL Components
      
      
      
      Maybe with a sticky at the top explaining what the deal is - i.e. non-mainstream HAL components that may or may not do what you want.
      
      ​​​​​​​If we just have a single thread called 'HAL User Components' it will instantly get polluted with random comments, tangents, and questions on how to use the component(s).
      
      A sub-folder might help keep it clean(ish) for a little while.

Well anyone can just submit a component via pull request to the linuxcnc repo. Not sure if the maintainers test them at all other than making sure they compile. If it's a good an useful component, there's really no reason not to just submit it via pull request.

I suppose some people just post components they aren't really 100% sure about or haven't fully tested. It doesn't really require an unofficial repo to store them, maybe just a place where people can look at it, maybe test it themselves then submit it. They shouldn't just live in some out-of-repo place if they actually do something useful.

Ok I’ll make a note of that.
Thanks for testing.

tommylight wrote:

Probably here, as far as i can tell, everything else will inevitably lead to here, and google still seems to find the forum easily.

What do you think about a new subfolder?

• Configuring LinuxCNC
  • HAL
    • HAL Examples
    • User-written HAL Components

Maybe with a sticky at the top explaining what the deal is - i.e. non-mainstream HAL components that may or may not do what you want.

​​​​​​​If we just have a single thread called 'HAL User Components' it will instantly get polluted with random comments, tangents, and questions on how to use the component(s).

A sub-folder might help keep it clean(ish) for a little while.

rodw wrote:

I just half wrote one here on the forum tonight forum.linuxcnc.org/49-basic-configuratio...-brake-with-linuxcnc
Blink could be improved a lot by using fperiod() so the on time and off time was specified in seconds if anybody wanted an intermediate project to practice on.
 

Well in the post the guy says it requires a floating point thread, but it is a nofp component, so you'd assume it was intended to run in a base thread.

My flash component started off with a counter, but wasn't very accurate timing. I'm using fperiod now, much better.

I say "my" component but really chatgpt wrote it lol. The nuances of comp trip it up pretty hard but you can get through it.

No image appeared on the screen, not working

@ vpomerleau, you may have to bypass the opticouplers on the board if it's over 2.5khz. rbobey1989 has a post in this thread about it.

If I ever manage to get mine going. I'll document what I did and what opticouplers to bypass etc

The pulse turning it by hand seemed good. Anything over about 150rpm the pulse was distorted , it was an open collector npn 500ppr

What was the part number of the original encoder?

If it was an open collector output, was your pull up resistor to high a value?

Did you look at the pulse train with a scope?

@Mudrat, I thought it was noise I was experiencing. But when I took the encoder apart I found it was a magnetic pickup instead of optical. It lost pulses above 200rpm and stopped counting. All omron e6b2 encoders have a dual board with disk inside. This was a single board. Pic below what it's suppose to look like inside(don't know if it genuine or a good copy)