Advanced Search

Your screen shot looks correct. I added multi state labels on the 20th, how are you updating?






JT

Take a look at this thread for the coordination of an external E-Stop with LinuxCNC
forum.linuxcnc.org/47-hal-examples/25861-external-e-stop

I have not tested an external E-Stop so the colors may not stay in sync.

machinedude wrote:

you might want to try a feature in CAM like smoothing. that will reduce the number of line segments in your geometry which might help with acceleration.

i think when you get into the fine details of your cuts you just don't have enough space to get up to speed. it seems like you are getting a lot of heat buildup at the top around the head and at the base around the feet on your project.

fine details like yours are probably more suited for laser cutting and would produce what i think you are looking for, but you can try some stuff tommy pointed out to see how far you can get with plasma. i would try looking into the design and try to keep your geometry as simple as possible to keep your cuts flowing the best you can too. give the machine the best chance it can to maintain cutting speed aided by design choices.

Thank you, i understand. What i am trying to figure out is if i have problems that i need to fix as for the machine/hardware so i stay only to figure out the best i can do by settings/software.

STEP_SCALE in your ini file sets the number of steps per mm (assuming metric units)
Determine the resolution of your encoder in steps per revolution
Allowing for any gear reduction and ball screw pitch, calculate the distance travelled per motor revolution
Calculate the number of steps travelled per motor revolution
Calculate the number of steps per mm. 
Enter this as your STEP_SCALE

you might want to try a feature in CAM like smoothing. that will reduce the number of line segments in your geometry which might help with acceleration.

i think when you get into the fine details of your cuts you just don't have enough space to get up to speed. it seems like you are getting a lot of heat buildup at the top around the head and at the base around the feet on your project.

fine details like yours are probably more suited for laser cutting and would produce what i think you are looking for, but you can try some stuff tommy pointed out to see how far you can get with plasma. i would try looking into the design and try to keep your geometry as simple as possible to keep your cuts flowing the best you can too. give the machine the best chance it can to maintain cutting speed aided by design choices.

Probably ought to point out the misprint in your Basic Hal Tutorial Link.
linuxcnc.org/docs/html/hal/basic-hal.html (above)
linuxcnc.org/docs/html/hal/basic_hal.html (should be)

Also jetz versteh ich es langsam. Der Motor dreht zumindest mal wie er soll. Ethercat-Config verstehe ich jetz langsam auch. Wie kann ich nun aber den Weg einstellen, das der Motor bei angeforderten 5mm auch die 5mm zurück legt? Mit stepconf war das ja relativ simpel aber wie mach ich das beim Ethercat?

Besten dank für die Hilfe.

Dear meister：

When I tested RIO, I was a little confused。

1. I set spi clk is 10Mhz, but 6.4Mhz actually
 
 
2. and I set shiftreg clk 1Mhz, but 323Khz actually
 
 

FPGA is ice40up5k

Is that correct?Thank you.

Tim

Tried to install this modified screenset but got a lot of errors. If I understand correctly here I need a modified handler.py file too?

 

spumco wrote:

Joco wrote:

Don’t make that assumption re feedhold. And tapping. The planner is taking things direct from the Hal pin. Not from the lcnc motmod module.

it needs to be explicitly tested. Unless someone has done so already and can confirm what the behaviour is. 
 

I can confirm that LCNC 2.10 disables feed-hold while synchronized motion is in progress.  FH has no effect during a G33 or G33.1 command until after the synch move is complete.
 

And that behaviour continues under scurve planner?  That was what I was referring to. Not what standard planner does.

@Grotius

Glad I can help. Yes, the code is stupid fine detailed. So for me it is a benchmark (standard tp has trouble to keep the speed, your tp is in generell faster) and not a "normal" everyday nc code. I have the code with different segment length, but the longer ones also hangs up after a while.

I played a little with the cycle time of axis. There is something going on, but I didnt get it. Maybe after you finished your steps we can go into the topic cycle time? I saw that you use a way shorter time than default. But maybe it is just a unknowledge on my side.

Still the same problem, returns every entry in the forum because the title of the forum contains EC300.

Ubuntu 10.04 will work fine with 512MB of RAM.

Hello. Thank you very much for what you share with me. I have already subscribed to you, but unfortunately, you do not offer me the option to translate the audio from your videos into my Spanish. There is some tool in Linux to achieve this translation.
I will install the Ubuntu that they shared with me, but how much ram do they use to work with?
What USB board do you recommend for my 32-bit netbook? Very kind and excuse my ignorance...

After pulling my hair out trying to figure out why G33.1 wasn't working on my lathe while attempting to test the problem raised in this thread, @cmorely pointed out I'm having the same issue.

forum.linuxcnc.org/38-general-linuxcnc-q...pping-problem#319786

So I can confirm spindle synchronization start points vary with spindle speed in G33.1 as well as G76 - and it's way worse on my lathe than the OP reported on his.

In my case a difference of 140rpm (60 vs 200) resulted in appx 0.750" difference between the Z-start point when synchronization kicked in on a 1/20 pitch (0.050").

According the the formula Andy posted earlier, my Z-axis requires the following distance to get up to speed

 

I don't understand why there is such a significant difference between what I'm seeing and what the OP's lathe is doing.

Unless somone has other thoughts, I think this is a bug.