Advanced Search

Hello, I have been doing some research and I want to understand better the difference on these systems, for instance these setups in the videos use Raspberry pi 4 and Ethercat so he can directly talk to the servos and no mesa card is needed, I understand Ethercat makes wiring much more simple and the cabinet has less parts,also on some servos is possible to do homing directly, some cons seem that is  harder to implement because there is less info out there and hardware is possibly more expensive usually, but my question is to know if it is as powerful as a mesa card setup on the max step rate side of things? any other toughts I may be missing?

 


Thanks!
 

i do not understand what is a reset mode. and where to call it/place it and in which file.

Now it's time for the portal beam. I milled seats for the rails (the profile itself was bent by about 0.2mm) and drilled all the holes. 



I also decided to fill this profile with polymer granite.
Remembering not very successful variant with tabs in the base this time I decided to try a different way. I cut all the threads directly into the profile and then screwed the screws in. Then I poured the polymer granite and after a few hours, when the mixture began to harden, I carefully unscrewed it all. It was much quicker and easier than with tabs.

There will be a motor on one side, so the fill will not be full volume. I also decided to put the wires from the motor through the profile, so I used a cardboard tube for this. On one side it is held by an aluminum plate. When pouring the polymer granite to have support inside, I made a piece of thin MDF.

 
 
 

I would guess so, (dangerous half knowledge)

If you use y code instead of a, you can move

G01 x right_end y distance_1st F what_works
G01 x 0 y distance_1st_layer + distance_2nd F what_works
G01 x right_end y distance_1st + distance_2nd + distance_3rd F what_works
etc.

The y distance per layer will become shorter and shorter, as the motor needs to do less revolutions when the spool gets bigger, at the same time the x feed will become faster.

Hope that helps.

p.s. the described way should result in a constant material speed.

On the other hand when you keep the material under tension and move in a Thread-pitch fashion (lathe in threading mode) it should work just as fine. The pitch will be one material diameter per revolution and the material speed will increase when the spool becomes larger.
The speed increase can be counteracted by slowing the spindle speed down.
 

Updated the system today, including ProbeBasic from version 0.5.4 to version 0.6. The error is still there, but the error message is different.
Is the lathe version tested by anyone before release? If so, on what configuration?

is it doable with G-code though?

**the values in the Z axis config are just a replica of the parameters i used for A axis in a different config. (in reality i dont have a Z axis.)

the attached post is where i describe my machine, and the use case of Spindle, instead of A axis. but i would be really happy if you could give your 2 cents on this matter too!

forum.linuxcnc.org/20-g-code/54516-help-...usly?start=10#314987
 

One stupid idea:

Just program the rotary axis as y-movement. Then program it as a diagonal move based on the diameter. Basically reverse what the CAM software does when you "wrap a path around a cylinder".

Curious if that would do the trick. (it should)

Might be interesting to output the tool length offset of the current tool and check if it is the same as #<calculated_offset>. (Note the queue buster 'M66 E L0' that makes sure the DEBUG line is not executed prematurely by the read ahead)

Yay, I helped someone!