Advanced Search

Oh, I had forgotten about that. I will try if that works. Thanks for the idea.

That looks cool, but I added physical encoders for Jog, feed and spindle overrides, so I never use the buttons.

Since there are two Hall sensor triggers on X, do you get the same errors homing off each?

Ihr seid klasse!
Mit eurer Hilfe habe ich folgendes rausgefunden:
Unter P04.03 kann ich mit dem Wert 03 für das Relais 1 folgendes einstellen: "3:Arbritrary frequency arrival Time,
Relay=ON,Related to P02-10 settings" --> Unter P04.04 ist das für ein Relais 02 einzustellen. Dieses Relais gibt es aber (bei meinem FU) gar nicht.
P02.10 war dann nicht so leicht zu finden.: P02.10 Arbitrary Frequency Setpoint 0-400Hz 
Zuerst hatte ich dieses Manual: bulkman3d.com/wp-content/uploads/2019/08...Wk1gLYu__4-sQemlJnOc
Da fehlten aber einige Einstellungen. Dann habe ich noch dieses Manual (nur die Einstellungen) gefunden: bulkman3d.com/wp-content/uploads/2019/08...Wk1gLYu__4-sQemlJnOc
Jetzt schaltet sich das Relais erstmal ein, sobald sich die Spindel dreht. Ich denke, dass ich mit P02.10 da noch was besser einstellen kann.
Nun schaltet das Relais die Kontakte CM1 und NO1 durch, sobald sich die Spindel dreht. Ich denke, dass ich den Anschluss an die Mesa-Card (+24V auf CM1, NO1 an die Mesa-Card) und dann die Einstellungen in der HAL (siehe in der Antwort von 0x2102) dann hinbekomme. 
Vielen Dank!

Currently the value of the sliders can only be adjusted by the +/- buttons. This makes it impossible to change those values quickly.
Here are two implementations which opens a bigger slider with the possibility to drag the slider.

What do you guys think of those two versions?

The previous owner installed a magnetic encoder on the X axis. I did not disassemble it, so all there is to see is a thin cable coming out.

I installed a glass scale on Z. I will make photos tomorrow, there is perfect space for it behind the X-axis motor mount. The installation was really easy.

Oh, and to “home to switch (hall switch) and then to the next encoder count” that is what I did initially. That way I got about 0.4 mm variability on X.

I don't think you need to wire the motor encoder A and B signals in to LinuxCNC to try it. It is a standard LinuxCNC option to home to switch (Hal switch) and then to the next encoder count, which you already have wired in.

I am interested to see how they did the physical installation of the linear encoders. I considered adding them to mine, but didn't.

Found another bug/missing feature in tp1. Hitting feed hold sometimes breaks planning, I guess the remaining length of current segment is too short to calculate using ruckig?
Ruckig planning failed (first attempt),
Back to tp 0
feed_override: 0.330000
max_vel: 132.000000
cpos: 380.077500, tpos:
380.133525, dx: 0.056025
cvel: 33.000000, tvel: 132.000000
cacc: 3000.000000
maxa: 3000.000000, maxj: 120000.000000

I don’t think the linear scales are at fault. I tested them over the 20 mm range of my longest indicator in 1 mm steps, and that is flawless for both axes. I also had the axis move over nearly its full range for 5 minutes at rapid speeds and then come back to the indicator, again, no measurable deviation.

To test the motor encoder directly, I would have to solder them in, and I cannot imagine that this will be better, as I already use the index from there. But if I don’t have any other options, I may as well try it.

I can make some pictures tomorrow, do you mean the mechanical installation on the machine or the wiring, or both?

You are making great progress. Took me a year to get that far

I can't say why it is not working as it is, but I have no linear scales, so my homing is just the home Hal switch and then fine tuned off the motor encoder index, and that is rock solid. Could you ignore the linear scale, and home the same as mine (which I think is original Schaublin)?

Please upload some pictures of your linear encoder installations.
Cheers,
Mark

I’m a NativeCAM user and I really love it, so I’m very happy to see that you are taking care of it and moving it forward. Thanks a lot for the work you are putting into this!!! 

Are you planning further improvements as well?
Especially on the lathe side, NativeCAM has huge potential. In my opinion, it is really only missing one key feature: a polyline function for lathe.
As far as I know, Fern never implemented that because the G71, G72 and G73 contour cycles were not working properly at the time. Today this should probably be possible, but unfortunately it was never added, which is a real shame. sadly people who are not programmers like me, cant help, just cry. ^^
With that one addition, NativeCAM could become extremely powerful for lathe work, probably on the level of ShopTurn. Then many LinuxCNC lathe users would no longer need a separate CAD/CAM solution.

That said, I’m already very happy with what you have done now! I use NativeCAM a lot on the milling side, and it is a real time-saver and makes the work much easier.

greetings 

Tom

Hi,

I have a new update. Almost everything is working now. I have one hopefully last problem.

The X axis homing is not repeatable at all. Both axes have a hall switch (original Schaublin), and both axes have linear scales (these do not have index signals). I noticed the lack of repeatability and put the blame on the 50 year old hall switches.

I used the index from the motor encoder (provided by the motor drivers). I connected them to the index inputs on the encoder connector for each axis. So I don’t have the full motor encoder on a separate input on the 7i97T, but I have the A and B lines from the linear scale and the index from the motor on one connector per axis.

With this, the Z axis is rock solid, but the X axis is not.

I homed the axis and drove it against an indicator. Then I rehome and drive to the same position. This way I see about 0.25 mm of variance (I did this about 20 times). Without the index, it was about 0.4 mm.

For Z, the index increased the repeatability from about 0.03 mm to nothing I could measure with my indicators so around 0.001 mm.

What I tested already:

Mechanical: The axis has no noticeable backlash. Moving the axis by hand (with the motor dismounted and turning the pulley by hand) feels very smooth.

Index signal: Both HALScope and a “real oscilloscope” detect the index signal. It is not as clean as I would like it to be, but the pulse is clearly there, and the Z axis that works fine looks the same.

If anyone has an idea where this could come from, I would be thankful.

I'll add to this, this mostly works, but not perfectly, so any help appreciated about the reasons.

Answering this myself for the next person, it needs

import time
from interpreter import INTERP_OK, INTERP_EXECUTE_FINISH

def change_tool(self, **words):
# Perform actions
# ...

# Pause for 2 seconds, synchronized with motion
yield INTERP_EXECUTE_FINISH
time.sleep(2)

return INTERP_OK

I've created a pcb fiducial detector within camView, I'll assume this is running in the qtvcp/UI thread. 

I've exported HAL pins from the camView widget so I can control this, then added manual control buttons on the UI, and linked these in the postgui_hal file.

I want to control this manual button from a remapped m code, so I've exported another hal pin to do so.  The problem is that when I set this pin from the m code, the UI/qtvcp thread is never serviced, so nothing happens.

What are some ideas or solutions here?