Advanced Search

Hello, everyone. I have a problem configuring a servo from StepperOnline: A6-1000EC. My goal is to control this servo via the python api. It should be possible to position it between 0 and 360° as well as rotation with different speeds.

My first attempt was to configure the servo as an angular axis. Then I wrote a simple python program to control the axis via JOG_INCREMENT and JOG_CONTINOUS. For absolute positioning I switch to MDI mode and send my target position. This works totally fine, but I can't run gcode with this solution, because I can't turn the servo continuous in one direction.

So I tried setting up this as a spindle instead. At first I changed my xml so I can process target-velocity and control-mode. Then I used a mux2 to change the control-mode depending on the use of M3/M4/M5 or M19. This works fine and my frequency drive changes between mode8 and mode9. The spindle control with M3/M4/M5 also works fine, but when I enter a command like M19 R180 Q2 P0 the servo drive throws a fault. When the target position is near the actual position this works, so I assume it is some sort of following error. My bigger problem is, that the actual position of the motor after using M3 for some time is very large, cause it is not restricted to one revolution. Is there a way to change that? At my first attempt using it as an axis I used wrapped_rotary, but that only affected the display, not the actual value.

Does anyone know what I could do, or if there is a better way for the use of an servo as position and continuous motion?

Many thanks in advance

Someone should ask Mesa why the firmware is in the "Specifications" tab and not, for example, a "support" tab

linuxcnc.org/docs/html/gcode/m-code.html...programmed%20timeout)%20occurs.

A workaround might be to software-debouince your limit/home switches.
linuxcnc.org/docs/stable/html/man/man9/debounce.9.html
Or linuxcnc.org/docs/stable/html/man/man9/dbounce.9.html

If you insert M66 P0 L0 between the probe moves then the queue might be cleared as a side effect.

Great news, thanks for the idea. I'll check it out tomorrow with version 2.9.7 and let you know the results.

The GUI's don't always "know" that you have changed an override.

Which GUI are you using? And how are you overriding (ie, which HAL pins are the counts going to?)

For reproducible hardware the Pi5 is probably a good choice. It's not the absolute best of platforms, but it is a known quantity and that would be useful if you are making multiples of the system.

I'm looking for suggestions for a simple bread & butter Linux CNC install.

It seems like an Raspberry Pi 5 + Mesa 7i96S might be the current standard, but it's not super clear? A while back it seemed like the Beaglebone was a good option, but it seems things have not gone that way?

Background...
I've built/retrofitted a number of machines with Linux CNC, but not for perhaps 10 years.  I've done a lot of machining and I'm fully competent with Linux.

I've got a new project that wants to integrate 2 Sherline CNC chucker lathes with some additional widgets.  Each lathe would get its own LinuxCNC hardware & software and the integration would be via ssh/linux command line.

If I can get the system working well, I might get orders for 10 or 50 of these systems over the next few years, so I would really like to use a stable, easy to get, standardized off-the-shelf parts, that can be expected to remain available for the next 5 years. I'm *not* looking to cobble something together out of 10 year old PCs, and I'd prefer not to build on some wierd/cheapo/legacy PC off Amazon which may go away in 3 months.

I'm looking for a simple reliable bread & butter LinuxCNC platform.

Suggestions?

BB

abs32 wrote:

I am quite proficient with build-install-clone commands and have the ability to simultaneously have and use all the versions

I realised that several posts later, and could have saved myself a great deal of typing.

It is unable to work due to this, forum.linuxcnc.org/38-general-linuxcnc-q...bing?start=10#338958, bug[/b][/b][/b]

I will try to look into this, probably with a simulated probe input for simplicity.

Have you tried inserting an explicit queue-buster between the successive probe moves? (I almost feel that we should have a specific code for that, maybe related to M70)
If you insert M66 P0 L0 between the probe moves then the queue might be cleared as a side effect.
Doing some offline research about this I found wiki.linuxcnc.org/cgi-bin/wiki.pl?QueuebustersRevisited which whilst not immediately relevant does discuss some of the issues around the motion queue.

Get the file with git or copy from the browser
github.com/MetalMusings/cia402pv/blob/master/cia402pv.comp

sudo halcompile --install cia402pv.comp

Hi Unlogic, 
I took a look at using your code, but I have the opposite problem. Your spindle stops abruptly with max braking with the enable pin deactivated, but mine just disconnects the power section and lets it coast down.

I don't actually need the rapid overlay. If I could operate rapid and normal feed with the same encoder, that would also be OK.

Released debs (ie officially released 2.9 versions) are also now available from Github.

github.com/LinuxCNC/linuxcnc/releases

This covers Trixie and Sid and has both AMD64 and ARM64 packages.

It is not yet clear whether the buildbots will continue in the future, but at the moment they are how the docs get to the website.

The encoder works on the spindle and for normal feed rates. However, if I switch the input in the Mesa software to rapid feed rate overlay, the bar does not move with the same encoder as for normal feed rates and the same wiring.

Das ist nicht das Problem. Das Problem ist, dass es gar nicht angeschlossen und ausprobiert hast.
In Mach3 werden physische Pins des Parallelports angegeben. Wenn die Belegung nicht stimmt, ist es entweeder der falsche Motor (falsche Achse bewegt sich), er läuft in die falsche Richtung oder er macht bei Richtungswechsel nur einen Schritt (Takt und Richtung vertauscht).
Nachdem du den Strom über die DIP-Schalter eingestellt hast, schließt du die Motoren und die Spannungsversorgung über die Schraubklemmen an die Karte an (und trennst die auch nicht unter Spannung) und verbindest die Karte mit dem Parallelport. Dann testest du ob es läuft. Die Wahrsagerei ob die Pinbelegung richtig oder falsch ist oder Beschwerden über richtige und nicht richtige / unpassende Datenblätter aus dem Internet bringen hier keinem was.

Auch kann hier im Forum niemand wissen was "die alte Karte" ist, daher macht diese Referenz keinen Sinn. Was soll dieses "sowas", auf das du dich beziehst, sein und wie soll jemand wissen was es ist, ohne dass du es vorher geschrieben hast? Die ist aber sowieso nicht relevant, da deine Endstufe einfach an den Parallelport angeschlossen wird.