Advanced Search

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.

i only see the screenshot

My settings are as follows, JSON file attached.
 

Ok!

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

Ok a negative sign on pwm scale and encoder scale is not the issue?

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

Possible that there is something wrong... i dont understand the MDH with flipping the coordinate system correct possible.. thats why alpha 0 to 5 has this values.

Possible my length and side shifts are not correct because the puma200 and puma560 are different on which side is shoulder to upper arm and upper arm to lower arm.

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.

Thanks

Thats pretty cool. I'll give it a go. If you have Home Assistant it was dead simple to publish this
 

In fact it was stupid simple once I enabled mqtt which I already had on my server (A pi4b Ive been running for years), it was done for me.

 

If the drive and motors have absolute encoders and if you are not having encoder feedback to Linuxcnc, you may be able to program the drive to move to the "home" position when Linuxcnc sends it a home command. Then have send a homed signal to Linuxcnc which Linuxcnc could see as the home switch.

Linuxcnc also supports absolute encoders and if the absolute encoder position is being fed back to Linuxcnc, then homing is not necessary at all.

I've already found the repo, but it would be better if it were separate from the LinuxCNC source—that's what I meant by having its own repo.

It would also be cool if you could pass in additional HAL signals, like sensors or 'door-open' inputs.

EDIT:

My first AI project (A simple status page for MTConnect): 
github.com/multigcs/riocore/blob/dev/rio...nect/files/stat.html

to test it, you can simply overwrite the twin.html file with it.

 

Jugo2 wrote:

Thanks Guys, My main problem is that Always Homed is not working, and the issue with Homing my dual Y Setup Precisely. :|

Re homing, please read this link until you understand it. Probably at least 6 times 

linuxcnc.org/docs/stable/html/config/ini-config.html

Yes its pretty cool. His repo is here github.com/sliptonic/linuxcnc/tree/feature/mtconnect-agent
I've added this link to the video description (and installed it on my machine including a Home Assistant panel)
I have asked in another thread if anybody has a 3 axis vismach model we could use in our PR to linuxCNC

The next step is to discuss with the devs how best to package this. My thought is to have a userspace driver that you added to your Hal file something like:Because all parameters are contained in the ini file, I think this approach will require passing the ini file name to the driver.
 

timo wrote:

@logthor: The stl you posted, will be a nightmare to machine .

Glad someone else looked!

With some spindles, its not possible to fit an encoder (I've had a couple) but thread milling solves the thread cutting dilema on all machines and is much easier on small machines.

could it be a problem that i change the signs on m joint 1,3 and 4 (linuxcnc joints!).. there have minus sign... please look at the ini you will see what i mean.

If you mean the 'SCALE_PWM' then that is not necessarily wrong as long as the joints rotate in the correct directions when you are jogging.

but the in Wolrd Z moves are "ok" but in x and y it makes stuff wit the hand joints and get failure

That sounds like you may be getting close to a singularity. Try setting the B joint to something that is not so close to having it point along the arm because if the wrist is collinear with the lower arm the C axis and the A axis are collinear which is a singular pose.
Sim configs CAN rapidly change the orientation of a wrist joint when approaching a singular pose, doing this with real hardware will trigger joint following errors and the kinematic will eventually fail.


 

for more on singularities in 6 axis manipulators:
mecademic.com/insights/academic-tutorial...es-6-axis-robot-arm/

Try it with a pose more like this:

He's done a really great job with his MTconnect;
it works perfectly, so I integrated it directly into my riocore system as a plugin.
It would be nice if there were a dedicated repository for it.

Thanks Guys, My main problem is that Always Homed is not working, and the issue with Homing my dual Y Setup Precisely. :|