Advanced Search

Hello,
is there anyone who can tell me what I should write because it's not clear to me?

i can see you configured its zynq ethernet  GMII module in vivado, does it work? have you tried it with lwIP examples to check if udp transport works?

you got some nice looking board with a heatsink, mine came as if it was found in a dumpster, with dust and corrosion. but surprisingly
it works fine. i agree this is a bargain considering specs with zynq 7010. 
 
 
 

I have the exact same issue randomly.

Look at this, it might help.

What hardware do you have?

At least for Mesa hardware and parallel ports, the GUI configurators
(pncconf  amd MesaCT for Mesa and stepconf for parallel ports)
know how to setup tandem axis for gantry machines.
 

Nevermind.  The CNC box and the power strip remained powered off for about an hour.  I powered on the the power strip and CNC box and knew immediately when the Ethernet lights next to the port were lit that a connection probably could be made.  I launched LinuxCNC and should be okay now.

Trouble with LinuxCNC and Gantry stepper motor setup. I have search for a long time to find anyone who knows anything about how to set up LinuxCNC to run the Y and A stepper motors in tandem, or jointly.
There seems to be many people who have done this but have very vague explanations on exactly how to do it.
I have come so far setting up this CNC router table only to come to a dead stop.

If there is anyone who actually knows how and would kindly lead me through it, I will be glade to give the needed info on what I have for there wise input. Also be very thankful too.

I would really like to do some routing on the table.

I launched LinuxCNC many times before, okay, and the Axis screen was operable.  Today, I powered on the CNC box and tried to launch LinuxCNC accidentally without the Ethernet cord plugged in.  An error report popped up, and I realized I forgot to plug in the Ethernet cord.  I plugged in the Ethernet cord when the CNC box was powered on, tried launching LinuxCNC again and an error report showed 'hm2_eth: ERROR: Could not retrieve hardware address (MAC) of 10.10.10.10: Resource temporarily unavailable'  I powered off the CNC box and the PC and power both on and tried launching LinuxCNC however still receive the same error report.  Please see my attached troubleshooting.  How can to make the hm2_eth retrieve the hardware address and launch LinuxCNC? 

i tried searching first  .long story short had to replace my pc (pitt falls of a maker space) still making some slight changes etc so not up and running yet.. i had kept the machine from updating since every thing worked.

in the past i used github.com/TooTall18T/tool_length_probe to set the machine up todo manual tool changes then the tool setter. my understanding with the newest update to probe basic variables called out have changed.      is there a better way to be able to use a tool length setter when the machine requires manual tool changes ?
ive attached the subroutine files .



 

Is there any possibility that this is configured as a WRAPPED_ROTARY?

linuxcnc.org/docs/html/config/ini-config...:ini:sec:axis-letter

wiki.linuxcnc.org/cgi-bin/wiki.pl?WrappedRotaryAxes

This isn't elegant, but if your python file imports "hal" then you can create a HAL pin, put the value on that, and then read that value in your G-code.
The most reliable way to do this is to "net" it to one of the G-code analogue inputs and read it with M66. But you can also use the #<hal[mymodule.pinname]> format in the G-code. Just be aware that the latter method will generally get the value that was on the pin when the G-code program starts and won't see any live updates.

linuxcnc.org/docs/html/gcode/overview.html#gcode:ini-hal-params

It's possible that the noise is due to the servos getting a bad rotor "home"
This only applies to brushless motors, but the drives need to know where the rotor magnets are relative to the motor windings.
If you are using EtherCAT then this is probably all inside the drives, so I am not sure how you could ever be sure if this is the problem. Do you know how the drives perform this step? (If they use absolute encoders or hall sensors then this is unlikely to be the problem)

I wouldn't expect G71 and friends to accept REPEAT/ENDREPEAT in the profile subroutine. It parses G1,G2,G3 commands into a profile internally then creates a toolpath to cut that profile.
I am not even sure that it can be expected to correctly read #<_x> etc.

Nice work mate