Advanced Search

Thank you very much for your help, it worked, I've been trying to get this to work for a while, thank you for your help, I hope I have enough knowledge to be able to reciprocate someday

You are great, thank you very much. I will try to do it tomorrow.

Schematic for the wizzy part. In case someone needs that. Never know...

meister wrote:

it always depends on the application,
 

True. Let's hope that badboy will be fit for a 4ax mill, 2ax lathe and ofc a 3ax co2 retrofit (<- my first project). Nice connector link up btw, I use the same although in a 2.54mm pitch. 

Too kind, as always. Thanks for sharing your expertise. I've removed the uart interface, will add a ws2812b status led, and added an automotive 2A input supply from MPS (supporting 9~60vdc). That should work with my 24v and 48v PSUs. For the remaining bits you've advised, I'm eager to simply add bidirection translation for the 50 gpios and send that out "as-is" rather. Reason for this is; I want to test ALL gpios on that unknown-to-me fpga before sending out a final board version. Would that be a fair approach? 

Tiny motion control board, although likely to pack an incredible power (thanks to the Rio Cult!!). Still plenty real-estate for the translation and other upcoming gizmos. 

Hi

Is there an example on the forum of how to do this? I guess it would just be based on the relevant HAL pin?

If M3 is active, I would like a large red icon, if M5 is active either a grey version of that or nothing

tommylight wrote:

Screenshots should do just fine, upload her on the forum under the editor click on "attachments"
 

how to get screenshots ? push the PrtScr button ? I can also add pictures ?

also might be interesting to mention that you need to have a wired internet connection to do the install... probably because i missed some part in the 1330+ pages to read , i tried to get stuff done over wifi... it's not working over wifi
I hope that i will get linuxcnc-ethercat to work and i will for sure make a contribution to the forum with how i got it to work. super detailed ... taking notes about everything ... imagine when everybody was saying ... " when pc's will be completely integrated in modern society , the usage of paper will be decimated!" hahahahahahahahahhahahahahahha

There is really no control mechanism that can compensate for backlash
in a very satisfactory way, especially if the cutting forces can reverse.

Linear scales can compensate for ballscrew thermal growth, and flex
in the drive system in response to acceleration and cutting loads.
With any system you would need a way to read the scales and combine
the scale information with the main position loop.

Typically 2 PID loops would be involved as the tuning of the scale feedback
would have lower bandwidth than the much more tightly coupled rotary
encoder feedback.

 

I am a little bit confused about what to download, the one Rodw put on google drive or the one that was posted on 03/08
because I got the same errors about the opensuse stuff
it was really hard for me to get my boss to agree with changing from his hacked mach3 shit to linuxcnc with ethercat ...

Thanks.
Do I read between the lines, that you think it hardly makes sense?

If the hardware would be “perfect” with no backlash at all, there would'nt be an necessity for linear scales… And with backlash it is “problematic”.

Originally, the machine had tacho’s on the motors, to detect the motors were spinning and to control theirs rpm... Based on the position measurement of the linear scales (distance to go), the loop was closed until position was reached.

Would that principle be different if I would use step/dir instead of analog +/-10VDC in the old situation? The resolver needs at least 10x higher resolution than the 1um resolution of the linear scales I presume….

And is there then a necessity for a drive with two resolver inputs? Or can a controller-card take over the correction of backlash (which will be in any case)
Do they even exist without paying the highest price?

In the xml you can change mm to inch for the tab. Thats just optical change.

In the probe_pocket macro:

#<ff_distance> = 5 (5 mm distance to contact with fast forward speed)

Just change accordingly.

I dont have homing (I bought the limit switches but did not install them yet )

So every start I have to zero x,y,z and that will be my G53 every time.

What I am doing now is G53 G0 x0 y0 then I shut the machine

next start I will set x, y to zero again to set g53 again. For some reason G54 is saved. But it is useless if G53 is lost.

Thanks

Philip


Edit : 

apology

I just realized that my question has no meaning.

I have to install the limit swiches, be able to home, then G54 will work because it is saved.

 

 
It looks lilke aekhv has pulled the project There are are forks of it, but forking doesn't capture the wiki or the project or the releases. I'll attach the debian 3.2 release in case you still want to use it..

Since no advice was forthcoming, I decided to develop my own component that can monitor and change SDO parameters.
Essentially, this will be a similar component to the one currently working with EtherCAT LinuxCNC but specifically for manipulating SDO data. Unlike the existing driver, it will work with YAML, which is much more convenient than XML.
An approximate example of such a file will be attached. If there are any suggestions, I would be happy to hear them.
I think I will start this week and finish in about a week. Later on, it will be possible to integrate the old functionality for working with PDO.
Although the current one works well, it has its drawbacks.

PS Admins, please add yaml and yml formats to the editor.