Advanced Search

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. :|

For the simple stuff I'm doing with my bob, I don't think it'll be an issue. I'm well aware of what a nightmare it'll be to machine. The model needs a lot of love.

this is how it looks when i start the genserkins example 


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.

i attached 2 screenshots.. mygui is what i have after homing. i changed in the homing: homeoffset und home to 0. i move befor homeing in a extra osition.. form this position i hit home... then all 6 motors turn until the Z index of the encoder is reached.

i attached form this a picture.. pumaafterhoming.... thats the "ready position" but the in Wolrd Z moves are "ok" but in x and y it makes stuff wit the hand joints and get failure.. i attached again the used ini with editi to home and home offset 0.. to talk about the NOW situation.

i thank you!


aah befor i forget... there is a difference between puma 560 and puma 200... the shoulder of the puma 200 is of the opposite then on the puma 560. thats why i have on D1 a positiv value.. this value i got from stäubli via email. i measured.. and yes this values are correct... its from red green to green in the drawing i attached. i add then the puma560geo.png to the attached files that you see what i mean what is the difference... 

pum200geo


puma560geo
 

puma200afterhoming
   
puma200gui after homing



exampleguipuma560
 

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

The Mesa Card fixed the problem and I have not the slightest interest in trying to figure out what went wrong, only point (I should have spent the money earlier)

20000 pulses (if I am correct and did not make a mistake) It would limit a 1/8th 200ppr stepper motor with my lead screw (4mm pitch) to approx. 3000mm/min. This is in my book good enough for a sherline, but some commercial machines run approx. 10x that speed.

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

Yes, I'm pretty sure we can delete that one.

Ah, I see what you mean, the A value being 180° because the tool coordinate frame is pointing away from the flange. You are rotating the tool frame in the kinematics. Ok that shouldn't be the problem then.
Can you post a screenshot of the situation when you start the example program?

I went a bit deeper into this rabbit hole and picked up some used panels. Still waiting for them to arrive. Not Haas though - I missed out on that deal.

But it turns out, sometimes (often?) these panels are a mix of both a raw matrix output and USB or PS/2. Like the Syntec and their clones as shown here . In the latter case, the "CNC'ish" buttons are all just a matrix but the keypad/numpad come out as a standard PS/2 protocol.