Double or Triple Rotarydeltakins on Ethercat

Hi,

I have done some short tests.

Setup : Did a double lcnc rip install. One rip started gmocappy, the other rip started gscreen.

Found :

- If lcnc starts there it places a lock file in /tmp/. This file is no problem. Can be erased from the source code.
- The shared memory want's to get the same adress, libnml tcp.src.cc line 280, line 281 has some problems.
- Motdot has some problems, if you comment out this at the second startup it looks a little better.
- Emcio also some problems.

Then i started something more simple. The halrun demo program.
Starting the first, and then starting the second, will terminate the first, here the solution is quite easy :
File : halrun.demo, decomment line 52.

** Result is running 2 linuxcnc programs the same time.

When i run my qtc++ program that is connected to lcnc hal and connected to ethercat i can connect as many qt apps as i want to hal.
That's because my app does not check if there is already something running. And if i use shared memory i use fixed memory names, so no interference.

Your interpolation is quite easy i see in the kins source file. With halcommand sending motor positions is easy.
Is your robot working with vision pick coordinate's and you send the coordinates trough gcode to the robot?

g-code
For example
We send to 192.168.0.1 g1 X100 Y100 F100
to 192.168.0.2 g1 X200 Y200 F200
by linuxcncrsh
It's now!!!

I think With new kinematic. We send to 192.168.0.1 g1 X100 Y100 A200 B200 F100 (Feed may by same)

Tommorow i will look into the current kinematics file if expanding to a total of 3x output is a easy step to do.
Have a good night ! Cheers.

Thank you so much
If it's easier you can start with a double. this option is also useful.
It is also worth considering the moment that the rotation of the coordinate system is used (G10 L2 P1 R30). It may not be necessary to use this command. And just write it into the variable table for XYZ and ABC.

One question also ivm convinced that you know what you are doing.
Why not using a cheepo rpi4 for every delta. Having thereon macros to trigger like
Go to pos xyz, lift and trow at position, go to start point.
And use a pc for sending thos submodules only the parameters for the macros. U could easily augment the numbers of deltas too.
Mike

Let me explain. This is not a garage project. There is no task here to collect a cheap product. These robots work 24/7 365 days non-stop.

It's all the same what to do spaceships base on Arduino.

Maybe i missexpressed.
Also, or especially, if we talk bussines, I'm a huge fan of modularity.
I would like to understand why do you wan't to have a one controller solution.

I don't quite understand what you said. I also want to use one controller for 2/3 robots. If you mean the main computer, then it performs mathematical calculations using tensorflow

Yes i see a 1 to n modular solution.
Seeing your picture i guess you wan't to have some kind of sorting mecanism.
I see optical (part recognition) and 3x handling (delta arms). In my opinion your deltas have a clear duty: grab parts on positions given from the vision controlled "master". You have that "grapping" three times.
I would judge such a delta as an autonomous module. I would give such a "slave" his own controller. And i think rpi4 are nowadays good with lcnc for such a duty.
So on a glance i see one pc plus 3x rpi4 as mcu's. I even could give that job to two different engineers.
That's my thinking. And i just wonder why you wan't to have all in one.
Mike

I'm going to make such a system on NVIDIA Jetson AGX (with my own motherboard) + Codesys. But this is already the next stage.