Advanced Search

timo wrote:

I had issues getting a 100ppr encoder to work reliable at 600 rpm. The cheap BOB seemed the issue, the system was loosing signals.
 

You are right, this is PC817 optocoupler bandwith issue.
I did some test, and PC817 response time depends on input current, if current increases, the bandwitch decreases (is this saturation?).
However 1 kHz is very low and PC817 sure can more.
If you use 5V encoder, you can safely connect it directly to LPT or MESA pins.
Most of 24V encoders with NPN outputs can be connected directly too, but you must check outputs voltage before (some has builtin pullup resistor an thats can burn low voltage inputs.)  
MESA can more than encoder. Low cost optical encoders have bandwith 100 kHz, this mean max 2000 p/r at 3000 RPM.
LPT depends on jitter, but in practice 100 p/r is max at 3000 RPM

I have a question.
At github.com/multigcs/riocore/blob/main/ri...ugins/fpga/BOARDS.md TangNano1K is marked as supported.
I know 1k gates is few, but is supported.
But I can't find any stuff for this board at repository.
I wonder is it possible to use this as one axis controller.
For example in situation when somebody have got working machine and could not make any changes to it, but needs to add 4/5th axis, rotary table, tools magazine or something similar.

Thanks for any replies. I managed to repair my machine for the time being, but I still want to upgrade the control system. I’m currently building a makeshift lathe so I can experiment and find the best control system. I’m planning to try LinuxCNC with the 7I96—since it’s constantly being developed—though I’m not sure if I’m capable of setting it up. Mach3 is no longer being developed, but it would be my second choice, paired with an Ethernet breakout board like the PoKeys57E.
Best regards,
Hans
 

Thank you for your help. The spindle PWM pin is now working.

         

rodw wrote:

... but thread milling solves the thread cutting dilema on all machines and is much easier on small machines.

Those things are magnificent and make tapping possible on low torque/power spindles.

@automata
See github.com/LinuxCNC/linuxcnc/blob/master...xis_9axis_scurve.ini

Well, it depends on how you derive your DH parameters. You'll just have to go through the process I'm afraid, so please look at the linked tutorial regarding modified DH parameters, there is a graphical explanation of how the coordinate system is manipulated to build the kinematic chain from the base to the tool tip and how that will give you the correct DH-{D,A,ALPHA} values.
That process will also define the correct sense in the joint rotations by using the right hand rule with the thumb pointing in the Z-axis direction. 

Your idea is to bring the arm in a position where every joint is slightly + - 5 deg? To go out of the singularity?

Not 'every' joint, but joint 4 and joint 6 must not be close to being collinear.
Again, please look at the linked explanation of wrist-singularity.


Also, I would just ignore the 'inverted Tool coordinate system' until you get things working like the 'puma560' sim. 

The B3 drives can definitely home in the drive with a switch + z-pulse just like you said: you send a home command from a DO on the Mesa and the drive will return a signal back once done.
But it's possible it can also home internally using only the absolute encoder value plus some gearing table for the Harmonic Drive. I didnt even think of that but will scour the manual:)

That would be the cleanest solution, I think.

hi grandixximo,
what is the progress of adding this liscio type of curve smoothing to linuxcnc master.
-automata

ahh, sorry, you need to set the scale (signals/dty)

if your spindle max speed is 20000rpm, you need to set it to 0.005
# 100 / 20000 = 0.005

EDIT: will try to add a little helper-tool for easy setup

X,Y moving together sounds like a hardware/wiring issue of some kind.

Can you check if the cross talk is from the encoders or stepgens?

 

Ok!

Thanks

What me help:

If i jog in joint mode... what is correct?

J0 + turns it left
J0 - turns it right

J1 + lift up
J1 - lift down

J2 + lift up
J2 - lift down

J3 + turns right
J3 - turns left

J4 + lift up
J4 - lift down

J5 + turns right
J5 - turns left

I ask this because i am still wondering with my setup frlm the first ini i can move the z straight up and down x and y small dent or bend..

But on the end the inversekinematic fails.

Your idea is to bring the arm in a position where every joint is slightly + - 5 deg? To go out of the singularity?

Thank you!

But what about the tcp in the simulation and my config?
Could you olease check if you have the phenomen with your sim config?

Could you please explain me what are the correct direction of turn + - joint 1 2 3 4 5 6?

That is a result of how the modified DH parameters are derived, see the tutorial I linked in my post above forum.linuxcnc.org/10-advanced-configura...al-ini-issues#348232

As a matter of fact I'm not even sure that having the Tool Coordinates pointing down is even a problem. Or if it is more a question of cosmetics. (ie having the A axis value '0' in the home position rather than '+-180 and thus having the tool cone in the preview in the usual orientation')

In the 'melfa-sim' config a workpiece offset is used to have the preview cone pointing the usual way. (eg 'G10 L2 P7 X0 Y0 Z0 A-180 B0 C0' in '428remap.ngc').

However your method of inverting the last rotation _might_ actually be the better solution. I just tried it in melfa-sim and it seems to make the offset shift for the A-axis unnecessary.
So I don't think that doing it your way would cause you trouble.

Thanks for your help... is it possible we can meet us in a teamview or zoom call or something? I am from germany.. timeshift... but if you can help me it would be so nice.

I can only work on stuff like this a little bit here and there so lets just keep going like this, it suits me better than having to allocate a chunk of time.


Generally speaking these kinematics are largely experimental so we should not assume that the examples are necessarily doing everything _right_.

Hello,I’m setting up an RF45-style mill with LinuxCNC on a Mesa 7i96S 7i85. The machine uses 86HSE12N-BC38(NEMA34 12nm) motors with HSS86 hybrid drivers, and I have installed linear encoders on X, Y, and Z. The encoder resolution is 0.005 mm, so I set the encoder scale to 200. I’m using switch homing only — I do not have an index pulse on the encoders.The machine already homes and moves, so the basic step/dir side is working. The encoders are assigned as:

• X = encoder 0
• Y = encoder 1
• Z = encoder 2

My goal is to use the linear scales for closed-loop correction in LinuxCNC while still keeping the HSS86 closed-loop stepper drivers in the system. The question is will these two fight for dominance? Second question is what is the correct way of doing it ?
The main problem is that i don't know what i am doing .
Second main problem is when i move x y is moving also ?!?!? And Linuxcnc e-stops with following error. None of changes i make in  PID values makes any meaningful change in my opinion (but i don't know what i am doing soooo....).
I have uploaded my .hal and .ini files any help will be greatly appreciated. 

The JSON file has been uploaded.