Advanced Search

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.

Something I noticed looking at example #11 in the doosan manual:


Note that in LinuxCNC G18 (and also G19) do not rotate the coordinate system but only the interpolation plane for arcs. This means that in Linuxcnc you cannot use 'G18' to change Z axis direction as the example code seems to imply. Instead you will have to use the 'Tilted work plane' codes to be able to use 'normal' xyz gcode (where xy is perpendicular to the tool rotational axis).

I did the following:

ethercat debug 1
sudo service ethercat restart
sudo dmesg

The log file says the following:
[    5.747038] ec_master: loading out-of-tree module taints kernel.
[    5.748211] ec_master: module verification failed: signature and/or required key missing - tainting kernel
[    5.765973] EtherCAT: Master driver 1.6.4 1.6.4.g703b611-1+17.1
[    5.766146] EtherCAT: 1 master waiting for devices.
is that the problem?

I hope to get to test this this week as well as the s-curve modification. Waiting for a test system.

It isn't bad with a xml file as such. There can be the same pdo in several places, and one need to pick the right one.
I doubt an automatic system can handle all situations.
For prototyping and creating a config, a graphics tool is really nice. But for production I don't mind a static config.
It isn't supposed to change. If it does something is wrong.

The machine can hydraulically lock the spindle via hirth coupling in 12 positions. This is of course quite importent for tuning tools and broaching tools.

I think I misunderstood this. I thought this applies to the B-axis but it seems to be the tool spindle.
Are you saying that the kinematic also needs to track the rotation of lathe or broaching tools in the tool spindle?

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.