Advanced Search

Haha no problem! Yes, I know I still have a lot to learn but I think I'm getting there in my own time. 
I won't bother with pics of floors, roofs or pipes but here's some metal I did earlier in 2019. I look forward to hearing where I'm going wrong!
Like a lot of people on here, I also have a day job - in my case power electronics product development that requires a fair bit of travel to Korea and Japan, in addition to time in the office each week away from home.

Valuable advice NWE, I will keep this in mind going forward.

I can confirm that the home function works. I made a connector from an old VGA cable and tested it on one axis.
Pin 13 <- 0V
Pin 8 <- Home switch (DI3)
Reference run method: 6
I am now waiting for the cables I ordered, and then I can test and complete the other axes.
Note 1:
The DI status (U40.04) is contradictory.
The inputs do not show as switched high.
When they are activated, they go low.
The driver interprets a low as 1, which is confusing.

Note 2:

There may be a problem with cia402homecomp.comp.
Once it has started, it cannot be stopped.
This happens, for example, when the servo moves to a limit switch.
It is not possible to move freely; the error “Home movement is still active” occurs.
This error also occurs when only one axis is referenced.
After completing the home movement, it is displayed as referenced, but can no longer be moved. The error “Home movement still active” also appears here. I will see how it behaves when I perform the home movement on all axes.

Note 3:

Since recently, I have been getting an amplifier error on the Y-axes (gantry) when starting Linuxcnc (gmocappy). The error can be acknowledged and does not reappear during runtime. 
However, this may have another cause.
 

Thank you very much, you are great.

net rro-count <= [HMOT](CARD0).7i73.0.0.enc3.count

# verbinde max Geschwindigkeit Neufestetzung Inkrement - MPG (connect max velocity override increments - MPG)

setp halui.rapid.rapid-override.direct-value false
setp halui.rapid.rapid-override.scale 0.666667
setp halui.rapid.rapid-override.count-enable true
net rro-count => halui.rapid.rapid-override.counts

Is that correct? Does PNCCONF need to be adjusted? Does MESA CT use the new values?
 

Note
For GMOCCAPY 3 some HAL pin names have changed when new controls have been implemented. Max velocity does not exist any more, it was replaced by rapid override due to the demand of many users.

For the record, don't repeat the mistake I made a while back. I mounted the encoder inside the belt drive housing to some shaft driven by gearbelt. If I remember right I used a hal mux switch to select encoder scale according to backgear position. It all worked pretty good, but foiled all attempts at tapping because the encoder was not at a 1:1 ratio to the spindle. I think the big problem was index changed with each spindle revolution.

I figure it would have worked better to drive the encoder at a 1:1 ratio with the actual spindle.

I explain above that with every settings off the difference is about 5000-7000
Edit: Anyone know how to use gpio on the board?

Edit 2: i really hate this style off editing of the forum. 

I used last night the iso from youre post
www.forum.linuxcnc.org/9-installing-linu...-rtai-and-rt?start=0

Linux Mint 19.2 with the bios settings off (single core) RTai
Run it like 2 hours and it never froze.
And the latency was about 12000

I do like your thinking!
I have been toying with putting an encoder on the spindle. (I have some spindle encoders that was salvaged off Mori-Seiki lathes in a box somewhere) Using the index marker on those should give an accurate rev counter for the MESA and HAL implementation. I would also have a solid encoder for the spindle, should I want to venture into rigid tapping...:thinking

Considering the Atom N450 is a single core CPU I'm unsure how isolating a core that doesn't exist would work.
You may get better latency if you disable Hyperthreading.
I'm assuming you are going to use the parallel port.

Thanking you kindly sir.

unknown wrote:

Does this mean I should remove the link to the RPi5/4 images I've been working on. Which I have no issue with if this is the way it should be.

Cheers
Rob

If you mean the GitHub link, no, you don’t need to remove it. It’s not a mirror. It’s your own work and it’s been communicated as such.

That is not the image I'm referring to. That image has been uploaded via one of the mods.
I don't not have access to any of the Linuxcnc resources. Even if I did I would ensure that the image was vetted and approved by others.

tommylight wrote:

Not near a machine so i can not confirm this, but IIRC:
Yes it does Disable the machine.
No, it does not trigger e-stop.

Near as I can tell, this is correct. It disables the the machine, requiring it to be re-enabled, but it does not turn the machine state to "OFF". This is why you see the GUI turn "OFF", and halui.machine.is-on turns False. But that's not the same as toggling halui.machine.off. I don't think this is a bug, I think this is a misunderstanding of what happens when a amp-fault is triggered. If you want this to work, I think the best course of action would be to connect the pin to machine.off as suggested previously.

github.com/LinuxCNC/linuxcnc/blob/69d26e...otion/control.c#L838