Advanced Search

You are welcomed, always.

halType is limited to the data type that are in hal: bit, float, s32, u32.
Whatever comes from ethercat will be shoe-horned into one of those.

What I see many times is the difficulty the get the xml file right both in relation to the ethercat device and in relation to the hal code.
Unfortunately, halshow et al aren't available until linuxcnc is started and it doesn't start until the xml is right.

Yes debug is switched on. But restart the master "sudo service ethercat restart" so one can see messages from the startup of the server and hopefully figure out why it doesn't take control over the network interface.

I tried again and hope it is now correct

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.