Advanced Search

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.