Advanced Search

Hi everyone, I've already done that. I've reinstalled the PC three times and always encountered the same problems. I included Mok Management during the second installation. I've done that again this time.

and yet something seems to have gone wrong:

With the workaround everything works so far (I hope) and thanks again

Hi rodw, thanks for the response. I think you are missing the problem so please allow me to clarify.

On my Tormach, this process makes perfect sense. I touch off with a probe or tool or edge finder or whatever, and then hit the zero buttons in the GUI. This sets the DRO readout to zero, puts the work offset origin symbol in the workspace viewer at the current position, and populates the offsets table with the position of the work offset in absolute coordinates. No problems here.

But on my new LinuxCNC mill, this process isn't working. When I hit the zero buttons in the gui, the DRO readout gets set to zero, the work offset symbol in the workspace viewer (3 colored axis arrows) gets put at my present position, but the offsets table doesn't update. It remains unchanged. You can see this in the images I attached to my previous post. More so, if I try to manually enter values in the offsets table, I get an error. I also included this info in my previous post.

Please let me know if there's anything else I can clarify. I understand that this is a bit of a subtle issue and I haven't done the best job of explaining it so far, so I hope this is a little better.

Edit: The mill is already homed in both situations described above. When run in what I call Bridgeport mode, moving the tool around manually and using the readout as a simple DRO, everything functions normally. The gui buttons zero the G54 work offset in the DRO correctly, it's just that the offsets table isn't updating along with this. When I load a G-code file, it appears to be respecting the offsets table G54 offset rather than the DRO-shown G54 offset, so the tool paths are not where I want them to be.

add loaded forces to the mix and i just learned something else this weekend. always something with this project, it seems. 450lbs of force is no joke or 2000N for everyone over on the other side of the pond.

Video links:

Hi guys ! Long time no see !
Back to this project after a long pause, a new mesa 7i77 board and some wiring mess cleaning. We managed to do some successful test cuts. The machine did even cut some 12mm sheets last Friday. But we still have issues with height control as the torch gets too close to the materiel and this messes up the cut and the torch tip. I'm uploading some test cut videos and will upload some more in order to have your feedback on height control and correct voltage values. Big Thanks for Tommy for his great help with this project. @Tommy, hope you're doing well and enjoying your projects !
Will update with youtube links soon.

Please note the update regarding tool-spindle orientation in the post above.

Also note that there is a sim config for fanuc style tool change and tool-wear, which you may find interesting:
github.com/LinuxCNC/linuxcnc/tree/master...im/axis/lathe-fanucy

Take a look at:

www.linuxcnc.org/docs/html//gui/gmoccapy...l#_tool_related_pins

It seems that you are missing the iocontrol connections. Putting these into the postgui file is correct.

pgf wrote:

More things I learned today, about Grbl:

Say you start a jog, and realize you meant to go the other way, and select the other direction. In LinuxCNC, this Just Works. Using Grbl, first the errant jog has to finish, and only then the next queued jog is executed. Not terribly efficient.
 

Not only "not terribly efficient", but can become very ugly. It all depends on the situation or machine. Those jog functions for a heavy machine are outright dangerous. Imagine it beeing set to a 10 mm jog distance. Push the wrong direction and off it goes into whatever is in the way.
If you are lucky it goes (pling) and the tip of the 3d probe ( 40 moneys ) is the only victim.

 

The device linked to from aliexpress should work, it is a simple interface that is easily configured with the generic device.
But be prepared to learn the translate tool in your browser, documentation is all in chines.
Here is a translated screen shot from the manual
 
If you understand what this is, go right ahead. If you don't understand it, take a safer and easier path.

That could be the case, good to get an explanation to this.
Was thinking of the lack of error messages when ethercatctl tried to modprobe ec_generic,
but the error messages might be in /var/log/daemon.log and not in syslog (dmesg).
Also strange that the module can be loaded by hand using modprobe.
If that's caused by secure boot, then that's clear.

Roger can you please check for secure boot in BIOS.
And yes, no problem to update.
Hopefully it goes away with the secure boot flag.

Still on the learning path of Gmoccapy.

Now trying to get the Tool Table to work.
I do not have a tool changer in operation, just manual.

On my Axis GUI, "Tn M6" initiates a pop-up dialog box with a prompt to accept tool number "n", and Continue.
Gmoccapy does not, it just stalls without an error declared.

Dug into the Hal files for Axis and Gmoccapy.
Discovered a Section " ... Use external manual tool change dialog ..." in the Axis file but not in the Gmoccapy file.
Perhaps I entered an incorrect response in the PnCConf Wizard when I generated my Gmoccapy install.

But, my searching found old posts that suggested inclusion of this section in the gmoccapy_postgui.hal file.
My Axis postgui.hal file is empty.
My gmoccapy_postgui.hal contains similar entries, but with differences.

This is my gmoccapy_postgui.hal file:
 #  ---manual tool change signals to gmoccapy's dialog---

net tool-change-request    => gmoccapy.toolchange-change
net tool-change-confirmed  <= gmoccapy.toolchange-changed
net tool-number            => gmoccapy.toolchange-number


Is this correct ?
Is there anything else I should do to get the Tool Change Dialog working ?

John.

Normally, you would touch off on your workpiece and set RefX, Y, and Z or use the probe screen (my preference),
Jog away from the home position and touch off all axes (using Ref buttons) then look at your offsets.
Press ABS and G54 to cycle between G54 and absolute coordinates.

The process is no different on a Tormach machine or any other machine including a manual mill with a DRO. Possibly your Tormach was dialed in on your vice long ago you forgot doing it.

I think your latch velocity is going the wrong way. You need it to back off the home switch so it can't have the same sign.
in your ini try

Did you verify that

joint.2.home-sw-in

Goes true when the Z axis limit switch is triggered?



 

Coorrect Z is a NO switch, X and Y are NC