Advanced Search

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

Is the Z axis switch Normally Open?

( a reversed axis and inverted home switch might behave like this as it would
back-off the activated switch instead of the search move )

 

Link to my current config: github.com/ccatlett1984/LinuxCNC_configs/tree/main/dmc_test 

I have attached a image of the machine, with limit switch locations and homing direction labelled.

I'm not getting past Z homing, it travels up (the correct direction), I can see the limit switch activate in hal show config, but it doesn't stop and mark the axis homed.

These are the limit switches: (I believe the not's are correct, as those switches are NC)
net min-home-x          <=  hm2_7c80.0.inmux.00.input-15-not
net min-home-y          <=  hm2_7c80.0.inmux.00.input-14-not
net max-home-z          <=  hm2_7c80.0.inmux.00.input-13

Hey Matt, I don't know where you are at with the retrofit but I thought I'd share some info about mine as it may help you.
I've just got the X axis going using closed loop to the controller this weekend. I am setting this up with Riocore, there is a very long thread on this forum about it, I'd recommend having a look.

I am using the original brushed DC servos, I removed all the resolver and tacho generator bits out from the end, mounted a perspex plate and fixed a CUI capacitive encoder. I did build my own H Bridge and controller board, had a couple of issues but it is now working.

The actual part doing the tricky stuff is a $30.00 fpga board (Gowin Tang Nano 9K)

There is something about turning the servo by hand without the motor drive engaged and watching the DRO update on screen!

Cheers.
Russell.

matn1 wrote:

Good day,
 Currently the Mesa is on a 5v3A wall plug

This is likely your problem. Replace with a Meanwell MDR-20-5 or similar.

Great. So now just work through the QT dragon docs and add the many enhancements to the GUI in a postgui file

Yes, there are generic Ethercat IO modules but many of them will require you to write a driver for them.
An alternative is to look at a Beckhoff EK1100 and add modules to it to unit your needs

 

These can be pretty expensive but man of them are supported in the Ethercat hal driver.
You can find them second hand reasonably priced on ebay