Advanced Search

The links still work, you just have to change the URLs from https to http.

Having received and assembled my new mill a couple of days ago, I have some fresh impressions on this topic.

I know most of you know all the background, but for those that don't (I didn't, until recently), I'll include it:

There are two parts to the Grbl ecosystem:  the firmware itself (and I'm including GrblHAL, and FluidNC in this), and the "G-Code sender" user interface.  They're connected by a USB-based serial port.

Choosing the first part should be easy:  go with one of the newer 32 bit firmwares, so you're not feature limited by the 8 bit code in original Grbl:  every time they add a feature, they also have to remove something, because they're completely out of code space.  But it's possible you won't have a choice, because you're using the controller that comes with your mill.  That's my situation.  My controller runs Grbl 1.1h, the latest 8 bit version.

For the "sender" UI side of things, there are many choices.  Of course, since I run linux exclusively, that cuts the number way down.  And so far, I've only found one that's a) pre-built and b) works for me, and that's UGS (Universal G-Code Sender) which seems to be the granddaddy of them all.  Happily, it's also reputed to be the most feature-complete, and the most complex as well.  (Hmmm.  Reminds me of LinuxCNC.  

So:  using it.  The included setup wizard (again, talking about UGS) is very nice, and very simple.  It should be, since there are only a handful of config variables.  I count 35 of them, and of course most come in threes, so that makes it just 10 or 15, though a few are bitmaps.  It takes just 4 or 5 simple tabs in the wizard to get through it all.

The rest of the UI is familiar -- a previewer, a g-code window, jogging controls, axis touch-off, etc.  Nothing I use every day in LinuxCNC seems to be missing.  The difference is that you won't find words like "G54 offset" anywhere, though the concept is present.  It's all less "technical".

The distance between the UI and the machine does become visible when things go wrong.  Hit almost any error (limit switch, for example) and the controller gives up, and needs to be reset, which involves rehoming.  Which I'm sure is safest.  But it's pretty different then LinuxCNC which is pretty hard to lock up.

I've only done one carving so far -- a simple v-carved text engraving created by F-Engrave, which I've used before.  Worked fine, as you'd expect, with one glitch:  grbl doesn't support all G-Codes, and F-Engrave included a G64 in the preamble.  I suspect I'll trip over others soon.

It's likely that someday I'll be converting to LinuxCNC, just because it's more flexible, and the technical support is outstanding.  (Truly -- thank you all.) But that's a biggish project, with a lot of rewiring, so I'm going to put it off for a while.

(BTW -- my new mill is an AnoleX 3060 Evo Ultra -- it's a fixed gantry design with a 12"x24" 8mm thick aluminum bed.  It's driven by three big (speaking very relatively) NEMA 17 motors, and the axes all have linear rails and ball screws.  It came with just a 1/8" collet 300W spindle, but since I already own the ubiquitous Makita 701 router, I've ordered the 65mm mount and will mostly use that.  I'll miss the quiet of the small spindle though.  :-/ )

paul
 

I would be really interested too, my main developing process is on SW. I would love to have everything in one place.
Switching back to F360 each time I have to machine something is so painful.

Thanks everyone in advance!

Yes, to swap a tool for another tool that is the case, but my spindle was empty.

The carousel needs to move away to give clearance to the Z assembly during probing. Otherwise the probe can't reach X0 without the Z assembly running into the carousel.

If I would place the probe on the left side of the spindle, possibly the carousel wouldn't need to move away, only when it needs to swap for the toolsetter.

But the consequence would be not having full probing range on the end of X axis (without extending the gantry), which maybe isn't really an issue.
But I would need to find a way to block the spindle from going into the carousel work area during 'non-toolchange' events.

I am a little confused of the slide forward (move in Y) on this setup? it seems the x axis is the only motion required for a tool change with regards to removing the tool from the forks.

I found the issue with G1 — it's an easy fix. When I stop the program while it's running with G96, there is a G95 command loaded just before it. But when I start the program from the beginning, there's no G94 command in the G-code.

The PID problem is caused by the pid.s.maxerror constant — I had accidentally used the same name twice. I'm also adding the issue with Gmoccapy as described in the relevant topic. forum.linuxcnc.org/20-g-code/44739-g96-issue 

 

the more i think about this project the more it feels like a Rube Goldberg machine build But that's a good thing it creates innovation i think Rod pointed out an uncertainty about a tandem rotary axis but i am on to the why it makes sense thought process now, i think. i might be sick and not feel like doing physical work but my brain is in overdrive it seems.

Hi all,

I was wondering why lcnc don't have the data types U8, U16, S8, S16 to use with ethercat lcec?
To me it looks like the lcec is some times loading S32 types (bigger data types) when it could load a U8.
The result is in-effiecient memory management. Don't get me wrong if this is not the case.

This issue came to light when i made a few tests to automate the ethercat hal pin setup for lcnc.
After automated hal pin setup worked i added new hal data types into the lcnc source code : U8, U16, S8, S16

Now the ethercat data types can be used 1:1 with lcnc.
For example a ethercat U16 is loaded into a hal pin off type U16 and
not as a U32 as before. This saves us the memory size of a U16 i guess?

Mention the automated hal pin names and the new data types:


In above picture, a component called ecad.so is loaded in hal. (lcec replacement)
The component name: ecad.so

When the component start's up, it load's c++ code that has a automated hal pin setup under the hood,
looking what kind off data types are used etc.
Setting up the hal pins :  hal pin setup

And at runtime update the hal pins every cycle :
Update hal pins: hal_pin_update

So far above situation works quite well.

In the ecad.so component we don't need any .xml config file anymore.
As the component just throws out all hal pins from the ethercat bus by itself.

What i didn't code yet, is time dc synchronisation. I tested a stepper config in axis, and steppers run just
as fast as using the linuxcnc-ethercat config. However i am on a really bad desktop pc.
Axis stepper config, driving one stepper motor: axis config
 

That's really cool, I'm working on translating the captions but I notice you are driving an AC servo, does that mean we could theoretically drive some large AC servo motors with this ?

Hi Folks,

this is an awesome project, thanks for it!

Please could anyone support me, how I could able to install git and linuxcnc-web to my LinuxCNC VM?

 

Hi Aciera,

i can't thank you enough! You know I'm not afraid of all the mechanics and electrics and getting the whole thing HAL ready also with custom M codes and custom Components I feel okay. But the kinematics and PP stuff... it scares me. I'm so glad that you help me so much on getting this thing to reality! I wish i could do more than just saying thanks a thousand times.

Kind regards,
Jochen

EDIT: I would be nice if two features could be added. An X Axis Tool offset is needed for lathe tooling. Also i dont know if the kinematics change, but the B axis can only rotate +/-90° while 0° is the tool looking straight down the X axis.

But i would prefer the solution by Mazak. They used iirc a custom tool change command and added the desired spindle angle.

It looked something like this: T01XX while XX equals the desired spindle orientation.

This can be done using a remap of the 'M6' command.

I would be super thankfull for some help, cause this is really a critical feature. I guess the same problem is not just drilling but also milling pockets at an angle other then 0° or 90°.

This can be done using an additional custom kinematic and custom Gcodes that implement 'Tilted Work Plane' functionality.
For a demonstration see the sim config I linked earlier:
github.com/Sigma1912/LinuxCNC_Demo_Confi...lt/table_c-spindle_b

Note that your case probably only needs G68.3, G69 and a basic implementation of G53.1 (see link above for a description of these codes)

I'll have a look at expanding the mazak sim config in this respect.

Das Hauptproblem bei dir ist, dass du VIEL zu wenig Information lieferst. Ist halt mühsam wenn man jedes mal fragen muss 'wo hast du was wie gemacht und was geht denn genau nicht, wo sind die zugehörigen hal- und ini-Dateien'.

Also:

1. Skizze von deiner Verdrahtung zwischen Mesakarte und Umrichter machen und hier anhängen.
2. Bekannt geben welchen Umrichter du verwendest und wenn möglich einen Link zu einem Onlinemanual
3. Das 'Video von talla83' ebenfalls verlinken
4. HAL und INI Dateien anhängen wie du das versucht hast umzusetzen.
5. Bekannt geben was damit GENAU nicht funktioniert, wenn Fehlermeldungen erscheinen diese hier angeben.

Hello Aciera,

during the last few days I thought about how to implement the PP and functionality of this machine.
I stumpeled across this pdf. Its from a Doosan Mill but it has the same construction as the Mazak and a PP is already there in Fusion. Now what came to my mind is how to drill holes if the B Axis is not oriented at 0° or 90°. Lets say at 45°. It uses a custom G-code G368 see page 40. I dont even have an idea how to implement this into LCNC but the question is do i need it? Couldn't it be done via TCP or kinematics?

I had to .zip the PDF. Otherwhise it would >1.6MB.

I would be super thankfull for some help, cause this is really a critical feature. I guess the same problem is not just drilling but also milling pockets at an angle other then 0° or 90°.

Kind regards,
Jochen 

Not too much going on this weekend the grandkids and kids got me sick so i have slept through most of it.

but it does work as intended. hopefully now that i have a physical assembly made it's starting to make sense as a whole a little more.