Advanced Search

PCW wrote:

Thats a fairly odd pinout.
I can try making a matching bitfile some time this week
That was the usual Soundlogic pinout, M2 & Combo , for most of them .
Odd but they were well build bob .
 I plan to reuse a combo + an encoder from the same guy, + 7i92h , 
a bit file would sure help...
or i 'll use 5Abobx2.bit and , hmmm , and swap cables , because , you do got all my respect , you FPGA and ARM coders, 
or C coders ,python , well , all of you , i bow  to you.
  Could it help other having those olds bob , pdf for them here;
encoder

combo

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!

OK, I added these commands to my ini file.

MIN_SPINDLE_0_SPEED = 200
MAX_SPINDLE_0_SPEED = 2500
MAX_SPINDLE_0_OVERRIDE = 1
MIN_SPINDLE_0_OVERRIDE = 0.5

Please see attached error log Swanie-CNC-error2.txt.
I also attached my current ini file.

Swanie
 

Aciera wrote:

Open a terminal (Ctrl Alt t) and enter this command

linuxcncthen choose your config and check for errors in the terminal output. 

 

[DEFAULT.QTVCP.QT_ISTAT][WARNING]  INI Parsing Error, No DEFAULT_SPINDLE_0_SPEED Entry in DISPLAY, Using: 200 (qt_istat.py:515)
[DEFAULT.QTVCP.QT_ISTAT][WARNING]  INI Parsing Error, No MIN_SPINDLE_0_SPEED Entry in DISPLAY, Using: 100 (qt_istat.py:515)
[DEFAULT.QTVCP.QT_ISTAT][WARNING]  INI Parsing Error, No MAX_SPINDLE_0_SPEED Entry in DISPLAY, Using: 2500 (qt_istat.py:515)
[DEFAULT.QTVCP.QT_ISTAT][WARNING]  INI Parsing Error, No MAX_SPINDLE_0_OVERRIDE Entry in DISPLAY, Using: 1 (qt_istat.py:515)
[DEFAULT.QTVCP.QT_ISTAT][WARNING]  INI Parsing Error, No MIN_SPINDLE_0_OVERRIDE Entry in DISPLAY, Using: 0.5 (qt_istat.py:515)
not enough values to unpack (expected 2, got 1)

I've narrowed this down to SERR on some machines
If you disable PCI #SERR generation in the BIOS setup
its solves the issue with the Elite 8200 at least.

I will look further into this next week.
 

That fixed it! Thank you very much.

-- Ralph