Advanced Search

I think that Granite Devices drives handle resolvers, but the current drive (IONI) only handles 700W. (you need at least twice that)
The older "Argon" drive might fit the bill, though it's a bit down on power compared to the existing drives.
granitedevices.com/oldsite/digital-servo-drive-argon
Lists the following feedback sources:
Incremental encoder
• Analog Sin/Cos encoder
• Resolver/synchro
• Serial SSI & BiSS (upcoming feature)
• Tachogenerator
• Hall sensors

What is the feedback system used for axis position? Are there separate scales, or does that rely on the resolvers on the motors too?

STMBL would work, but doesn't fit your "industrial" and "don't want to build it myself" criteria. (though see the thread about a new STMBL on this forum.)

Much easier to use another GUI.
PlasmaC and QtPlasmaC are made with that automation embedded into them as they are essential for plasma use.

kn612 wrote:

Is it possible to use stall force tolerance for z axis home and detecting the sheet metal in qtplasmac? 

Yes for a DC motor, no (at least not easy at all) for steppers.
For a DC motor you would need a reed switch and wind some 5-10 times one of the motor cables around it (not both), wire the reed switch to any input and set it in hal as limit switch or probe.

Emco use encoder from spindle for ramp up and down speed between toolslots and calculate the way in theorie.. then the other sensors looking for the real position

I have found 2 problems: in turning and tool-change operations.
I found a workaround since at this moment I have no time to really understand and find a solution for the errors.
So, please do not consider it a solution.
In the folder /home/your_user_name/nativecam/cfg/lathe/ you should find the
config .cfg files.
(Or maybe the files you are using are in /usr/share/linuxcnc/gladevcp/NativeCAM/cfg/lathe/)
Edit the turning.cfg file and search for the word "parent" (without quotes).
(maybe you could make a backup copy before editing)
I have found it in line 71, 99, 100
Place a semicolon (that it means comment) at the beginning of each line containing the word "parent".
Save the file.

Same procedure for the tool-change.cfg file.
Please comment lines 76 to 80 and 198 to 203 containing "parent"

The turning operation and the tool-change seems to work.
I don't know if there would be side effects.
Hope this helps.

Regards
Giovanni

I have built 5 of Voron 2.4 and 4 (i think, maybe more) or Voron Legacy.
This is after buying 11 or more of Creality CR printers (not the cheap ones, some pricing errors so got them all cheap).
Having got that out of the way, if you can get the Elegoo Centauri Carbon for 300-400$, get it, do not ask, do not think, just get it. For that price you can not source the parts only.
Now, building one will teach you a lot of things, a lot, but it will also want to shot it with a bazooka many times if you do not follow the instructions.
Voron has very good instructions, browse through them once or twice before even starting to order things, and if you do start ordering things, get a kit, it will save your hair if you have any left by then.
For a low budget, build a Legacy, but if you can stretch a bit, build the 2.4, it is a magnificent piece of engineering and it is a workhorse.
And in case you go all DIY, here is a version of 2.4 that uses linear rods for Y and Z axis instead of linear rails, easier to source and cheaper:
www.printables.com/@Toma3D_1991434/models

I think you need
[EMCMOT]
EMCMOT = motmod num_extrajoints=1

It's worth knowing that in many (but not all) cases INI file entries are simply copied into the HAL file.

Typically you will see:
(INI)
(HAL)
What you want to end up as the HAL command is something like

It doesn't matter what order the modifiers after "loadrt motmod" are, which means that you can either have the num_extrajoints as part of the [EMCMOT]EMCMOT substitution, or you can add it yourself to the loadrt..... line

Can you post you current hal/ini files?

Note that tuning a velocity mode servo is largely a matter of setting FF1 correctly.
 
Here's an older velocity mode tuning guide:

gnipsel.com/linuxcnc-old/tuning/servo.html

Are you using the "orient" component? I _think_ that should allow you to set it to orient angles > 360 degrees.

Did you try this?

freeby.mesanet.com/basic7i97.zip
 

issue is the toolchanger is turned by the spindle.. with spindle orient it works but its crap..

need spindle in velocity as spindle and in position mode for referencing the toolchanger and make toolchange...

I will add a floating head for initial height and a z max limit then. I am going to try and use the original hyperthem vdc3 board for ohmic and divided voltage.  Looking at pncconf it looks like I can use the ohmic enable output and input with the vdc3 board to do an ohmic circuit. 

I can get motion on all axis now with the analog servos and 7i97t on qtplasmac.  I am having a hard time getting them tuned.  When enabled they lock in pretty hard and the axis will jump.  The lower P Proportional value parameter the more they jump.  Around 100 they move the least amount (1/16 inch) on enable.  Changing anything else from 0 makes it worse.  I think the settings on the servo driver themself are causing issues. Going through the manual for these schneider lxm05ad10m2 drivers but its over my knowledge level.  

I am also reading up on Hal oscilloscope.  This is all new and challenging.  Ive only used steppers motors up to this point

hitchhiker wrote:

now i came to the point that orient not works for the toolchanger because 2 spindle rotation are 1 positionchange from slot to slot.
 

Can you elaborate on this point? 

You could look at the HAL "debounce" too, to require ms of stable signal before tripping. But that does, in principle, lead to a position error (possibly small, at low probe speeds)

A chap at my Hackspace likes the Voron design so much that he has built 3 of them. Might be worth a look.