Advanced Search

Als erstes mal die Tippfehler in den Signalnamen in der HAL korrigieren:

Ist:
Soll:
Probieren und berichten (und bitte die korrigierte hal Datei wieder anhängen damit wir sehen was du geändert hast)

net spindle-enabe => hm2_7i96s.0.pwmgen.00.enable
net spindle-vel-cmd-rpm => hm2_7i96s.0.pwmgen.00.value
net spindle-vel-cmd-rps <= spindle.0.speed-out-rps
net spindle-vel-cmd-rps-abs <= spindle.0.speed-out-rps-abs
net spindle-vel-cmd-rpm <= spindle.0.speed-out
net spindle-vel-cmd-rpm-abs <= spindle.0.speed-out-abs
net spindle-enable <= spindle.0.on

Typo in hal file?

I performed the installation according to the instructions from rodw

forum.linuxcnc.org/ethercat/45336-etherc...-how-to-step-by-step

Mine looks like
so my installation goes on and loads the ec_generic module from igh ethercat.
And thinking of your "tainted kernel" message, do you actually have the ethercat network drivers installed?
I search for them here and find them as below

Hallo
Danke für die Antwort, einer erbarmt sich doch.
Zu Punkt 1: Verdrahtung ist lt Foto wie von Talla83 vorgeschlagen. Mesa Karte ist 7i96s
Zu Punkt 2: China Umrichter A2 Serie 4KW
Zu Punkt3: Erste Schritte mit Mesa 7i96s - VFD Analogausgang (Link ist auch am Foto ersichtlich.
Zu Punkt4: HAL und INI hänge ich an
Zu Punkt5: Es gibt keine Fehlermeldung, Am PWG wird kein Sollwert trotz Vorgabe ausgegeben. Auch sind beide Ausgänge (Out 0 und Out1 HI (13,5V))
Parameter sind im Inverter Umgestellt. Parameter 03=3 (0-5V Signal) Parameter 04=2 (External Signal Control)
Spindel habe ich getestet mit dem Display vom Umrichter da hat sie sich gedreht und konnte die Drehzahl gesteuert werden.

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