Advanced Search

Search Results (Searched for: stepper spindle)

  • IB_CnC
  • IB_CnC
30 Apr 2025 02:18

Probe Basic and Carousel ATC with Geneva and Stepper

Category: QtPyVCP

Anyways, the basic functionality is working.
I still have to wire up and map the ATC spindle PNP sensors to detect clamping / unclamping and the sensors for the out position of the Carousel cylinder, before I can try to run a toolchange. But that should work out fine.
Once everything is working, I'll do a writeup how it's configured.
  • yngndrw
  • yngndrw
27 Apr 2025 16:25 - 27 Apr 2025 16:26

Thought experiment: Let's design a modern THC (+ Closed loop discussions)

Category: Plasma & Laser

Hello,

Let me start off with the purpose of this thread. I've never built a plasma CNC and I've never used a THC. The purpose of this thread is partially to confirm some of the research I've done and partially to probe as a bit of a thought experiment, as from what I can see, things seem to be in a transitional state between a few control schemes. I don't know if what I've identified is valid, or if there's a reason behind it. Maybe it doesn't matter, but either way, I thought it might be fun to design a system (At a high level) from scratch and ask "what if?".


Let's take a step back and first talk about closed loop, older analogue controls and the like as that's quite important. (Or at least, my understanding. I'm basing some of this on an old Cincinnati Sabre 500 VMC with Fanuc controls I researched a while ago as I was looking to purchase it - It turns out that a 4t machine is a logistical nightmare, but the control findings were interesting.)

In ye-olde-days, you had motor drives with an analogue velocity signal. The drive didn't know what the position was, nor did it care. The motion control managed the position, and you had a full closed-loop setup. This was, I suspect, because back in those days, sharing digital signals over multiple devices was a pain, so it was easier to keep the digital stuff inside the motion controller and to have a fully analogue motor driver with analogue signals. An interesting part of this was the spindle motor orientation used for the tool changer - The spindle drive had a motor orientation board which was connected to the encoder. This meant that when the motion controller stopped the spindle, the spindle drive would automatically park it in a specific orientation. The motion controller didn't control this, it just told the drive to sort it out and the responsibilities were clear.

Next we have our standard step/direction drives, with stepper motors operating in a fully open loop. The motion controller assumes that when it commands a movement, that the motor and driver will keep up and hopes for the best. We know about the limitations, so let's not dwell.

After this, we have the hybrid closed-loop setups with step/direction signalling controlling either a "closed loop" stepper or an AC servo. (Which is closed-loop by nature) Some would say that these are not true closed-loop systems, but as long as there's a fault signal being fed back into the motion controller, it really is closed-loop by definition. Some servo drives allow a second machine encoder for increased accuracy.

Most of the more expensive Centroid offerings include ways to close the loop right back to the motion controller, but I believe this is more for compatibility with older hardware. (See above) I don't believe there's any benefit in a new setup as long as the motor drive can report a fault back to the motion controller; they are both closed-loop, just with different responsibility splits.


I wanted to take that detour about exactly what closed loop means because I think it applies to THC. There are many approaches, but I think it's also worth considering where the respective responsibilities should live between each component, and I think a good test is whether or not the system could, at least in theory, support buffered motion planning. I know that doesn't apply to LinuxCNC, but I think it's a good benchmark for responsibility splits either way.


As with motor drivers, there are many ways of approaching THC:
- You have "fully" stand-alone systems such as the Proma unit, which intercept the Z-axis motor control and over-ride it mid-cut.
- You have fully closed-loop systems where the THC is implemented within the motion controller in software with a hardware interface such as the Mesa THCAD.

I think most people would say that software solutions are superior as they can look ahead, implementing features such as anti-diving. However, from my research, I'd argue that the stand-alone systems are not actually standalone; there's a lot of confusion regarding responsibility, as both parts in these standalone systems control Z axis position. I'd also argue that a purely software solution isn't ideal when you start getting into Ethercat and certainly doesn't allow for offloading via buffered motion planning. I would propose that there's another way.


Fully stand-alone THC, with "fully" no longer in quotation marks. Consider the following statement: The motion controller does not care about the Z-axis position for a CNC plasma machine at all. It cares about the target arc voltage, it cares about anti-dive, it cares about the initial torch height - But it doesn't directly care about the torch height. What if the motion controller told the torch height controller about the target arc voltage, when to start/stop the torch, what initial torch height and dwell to use when starting, and when anti-dive should be considered? What if the THC handled probing and piercing itself, if it fully and directly controlled the Z axis, including the limit switches? What if the THC told the motion controller when it was good to start the motion, rather than just when the ARC is okay?

This is the step which I think is missing. You could wrap all of this up into an Ethercat device and it's a lot closer to being able to handle buffered motion. (Although it's not perfect, as the X/Y motor drivers would need to wait until the all-clear from the THC before they start their motion.) It could handle all things plasma, including gas and current control (E.g. Hypertherm's RS485 interface), it could report back all of the diagnostics (Such as current arc voltage, current torch height relative to the probe position, information about the torch tip. I think this would also be much closer aligned to the modern Fibre laser setups with how their focus control works.


I'm curious about people's thoughts. Have I made any mistakes or misunderstood anything? Is it nonsense or even just a waste of time? I'm also hoping my explanation on closed loop helped others understand what it really means, as it took quite a lot of research to get my head around what exactly it meant and why "proper" CNC machines used to have velocity control.
  • 3404gerber
  • 3404gerber
27 Apr 2025 07:15
Replied by 3404gerber on topic comparing to Grbl, or FluidNC

comparing to Grbl, or FluidNC

Category: Milling Machines

I retrofitted my first engraver with GRBL; took an Arduino nano, read the manual for 3 hours, connected everything in 2 more hours and had a working system that I used till my spindle controller card burned while milling a pcb... I then retrofitted a small desktop mill and went this time for GrblESP32, which became FluidNC later. Again, the set up was quick, efficient and functional.

I started to read about LinuxCNC when I was trying to use TMC5160 stepper with their internal motion controller rather than with step/dir signal. For me this could be the first big difference; if you look for a G-Code interpreter to generate up to 6 axis step/dir signal at a fairly high frequency and need the standard Start/Stop/Pause inputs, then go for Grbl-like system. If you need more complex interaction with hardware, then LinuxCNC is the answer.

The second big difference is probably the difficulty; maybe not the best example, but after several months I still don't have a working system. But to be fair, it has a lot to do with my poor coding skills, and the fact that my mill is currently working well under FluidNC. Anyway, even for a standard project, you will have to find a reliable step generator (PC-based or external), find the correct configuration, adapt the INI and hal files, choose a GUI. There are many options and that's fantastic, but it takes time to figure everything out. FluidNC works on ESP32 and uses one config file. That's it.

Speaking of figuring things out, this forum is certainly the third big difference; yes, FluidNC has a nice wiki, yes 3D printing Grbl-like systems like Klipper, Marlin, etc have also a lot of users and forums. But this forum is a real gold mine and there are so many different information about so many different subject that you can spend hours here without thinking about your mill. :) Congratulations guys!

The fourth and for now last difference I'll mention is the GUI; as said before, Grbl-like systems are G-Code interpreters and they do not offer any user interface. So one option is to use none and just put your G-Code on a SD card and start it with a button or a small touch screen, or to connect an external PC that will host the GUI. There are different existing software and I don't know them all; I use bCNC and tried UGS. They are very fine for simple setups, to home machine, use camera for alignment, Z and tool probe, etc.

In my current project, I try to use LinuxCNC on a Radxa Zero 3E as a headless 6-axis motion controller. For this, it would be fantastic to have a module similar to linuxcncrsh but "speaking" Grbl standard; I could use any of those existing G-Code sender with my LinuxCNC board. On the other hand, the Remora component use external micro controller to generate steps/dir signals, but in theory, a Grbl component could completely replace the EMCMot+Stepgen components in LinuxCNC for stepper motors signal generation.
  • IB_CnC
  • IB_CnC
26 Apr 2025 22:13

Probe Basic and Carousel ATC with Geneva and Stepper

Category: QtPyVCP

Thanks, I will try to set it up the same way with both sensors needing to be high for homing.

I've made a little setup with optical sensors and for indexing just added a "flag" to my drive wheel.
The homing sensor and flag are below the pocket which is the pickup location for the spindle, as it just happened to be a good spot.

 

 
 
  • spumco
  • spumco
20 Apr 2025 21:03

Determining Angular Scale - Help w/ Microsteps

Category: Configuration Tools

[Sorry for the following Wall-O-Text, but I got on a roll ]

OP-
Incremental encoders have a resolution which can be expressed either as 'lines' or 'counts'.

In the case of a wheel with slots, each opening is considered a line.  For optical glass encoders, a line is one of the etched or printed black lines on the encoder disc.

If you have a 1000-line (or 1000-count) encoder, that means the disc has 1000 of these interruptions in the optical sensor/reader.

What causes things to get a little confusing is that the drive doesn't just sense one pulse for each line that passes the optical sensor.

There are two sensors in the read head, and one is slightly advanced from the other.  Both of these sensors send signals to the drive, and we call them the "A" and "B" pulses.  So that's two pulses per physical line on the encoder disc.

But it gets better... the drive can sense the rising edge of each electical pulse, as well as the falling edge.  For example, when a line goes past the A-sensor the drive sees a voltage change from 0 to 5v.  Then when the line gets all the way past the sensor the drive sees a transition from 5 to 0v.  Each transition - 0-5 and 5-0 - counts as a 'pulse' to the drive.

Same thing is happening on the B-sensor, and since the A-sensor is advanced a little bit from the B-sensor, the drive can count 4 pulses for each encoder line.  So we basically get a 4x improvement on encoder resolution for free.

Since your motor has a 1000-line encoder, the drive expects to count 4000 pulses per revolution.  This where the "1000/4000" jargon I dropped on you earlier comes from.

www.motioncontroltips.com/faq-what-do-x1...ncremental-encoders/

You can imagine what happens if the drive is programmed to expect 4000 pulses per rev, but the encoder is a 800-line (or some other non-matching value).  The drive thinks the motor is spinning at a different RPM than reality, and the motor magnetic poles don't line up with what the drive has calculated should be the case.  The drive won't turn on/off the coils at the right time, and the motor might turn but would make noise and not move to the correct position.  A significant mismatch would probably result in the drive erroring out.

That's why I suggested checking what value the drive was programmed.  It was unlikely there was a mismatch as most of (if not all) these cheap closed-loop steppers have 1000-line encoders so the drives are generally programmed for 4000 pulses, but it doesn't hurt to check while you're in the tuning software anyway.

You do NOT adjust the 4000-pulse encoder setting in the drive, regardless of the INPUT steps-per-rev setting in the drive (or in LCNC).  That encoder number is explicitly determined by the encoder on the motor.

Input steps per revolution on a programmable drive can be just about any arbirtary number.  While the motor has 200 physical steps (positions) due to it's construction, you can program the drive to move however far you want per input pulse (not encoder pulses).  If you program 1ppr input, then the motor will turn one full revolution for each pulse.  If you program the drive to 3157ppr, it will move 1/3157 of a rotation per input pulse.

Setting the drive to a higher input ppr than the encoder pulses means the drive is just guessing - the encoder resolution has to be higher than the input pulse setting for everything to work cleanly.  You can set the input higher than the encoder in the software, but there's no way the drive can accurately move the motor exactly where you want it because the drive has to guess where the motor is between the encoder pulses.

Older, non-programmable stepper drives were limited to either 200 input steps/rev for a 1.8 degree motor, or some multiple of that native 200 selectable via dip switches.  So when you see '4x', '8x', etc. that means you got to pick 200ppr, 800ppr, 1600ppr and so forth.

If after you take in to account the mechanical transmission (ball screw, belt ratio, etc.) the math didn't work out cleanly, you wind up with some strange number of input steps per machine unit (inches, mm, degrees).  Thats how you get from a drive set to 8x (1600ppr), through a 3:1 belt, and your units are in degrees (1/360)... so you have to tell LCNC to output 13.3333... steps per degree of spindle rotation.

LCNC can't output one third of a step, so whenever you have a non-whole number of steps per unit of measurement, there's a bit of "ish" involved with where the motor lands. LCNC doesn't lose track of where it is, but it can't move the motor exactly where you want.

However... if you program the drive with an input ppr that results in a whole number for each machine unit - degrees in your case - then LCNC can output a number of steps/pulses that can resolve to exactly one degree.  For your belt drive, that means 1200ppr at the drive input results in 10 steps per degree - a nice whole number which means LCNC can resolve to 0.1 degrees per step.  And 2400ppr gives you 0.05 degree per input step resolution.

Remember a few paragraphs ago when I mentioned keeping the input ppr lower than the encoder resolution?  Both 1200 and 2400ppr input values are lower than the 4000 pulse encoder, which means the drive would still have a chance of positioning the motor fairly accurately.

You machine isn't going to actually be 0.05 degree accurate due to variations in the belt, pulleys, friction, lost step here or there... but your INI file will certainly look neater.

Hope that helps.
  • Jabbery
  • Jabbery
19 Apr 2025 01:04
Replied by Jabbery on topic Spindle will not stay running

Spindle will not stay running

Category: General LinuxCNC Questions

Yes. I don't always trust over seas items so even if they don't have a ground lug they are grounded. All wire has grounded drains, 7i96s frame ground, emi filter, spindle, machine frame, stepper drivers are all grounded to earth ground
  • tommylight
  • tommylight's Avatar
19 Apr 2025 00:41

Are the program's extents available to the g-code?

Category: General LinuxCNC Questions

Secondary question: I don't have a Z+ limit switch. My mill is so slow I'd really have to not be paying attention for the carriage to get close to the stepper. A lower limit would be nice, but I really don't understand how that could work. My spindle is a router, so the bit length varies a lot. Is there any way to configure this to work? I see people say that they don't bother with a lower Z limit, and just rely on a soft limit there, but what would you set it to? Is there something about "real" spindles that I don't know? Are the bits always the same length?

No need for lower limit switch, LinuxCNC is very good at obeying soft limits, and you set it to the actual hardware limit, so if say Z is able to move 200mm it is set at -200mm in the ini file as the min_limit.
Upper limit switch is nice to have as it is also used as the home switch in LinuxCNC, so the top of the Z becomes 0 in G53 coordinates, then you put the tool in, jog till the tip of the tool touches the surface of the material and you do a touch off in G54, jog up a bit to avoid hitting something and press run.
All the usual CAM software outputs gcode where 0 it the top of the material and everything below it is negative values, hence the above -200 example.
As for tools, no they are not the same length, and above is how to deal with them.
The thing with hardware limits is, no matter what G54 is set to, LinuxCNC will not allow the machine to move beyond what limits are set in G53.
And then there is G55... :)
  • pgf
  • pgf
18 Apr 2025 18:30

Are the program's extents available to the g-code?

Category: General LinuxCNC Questions

I wish y'all had been around when I first configured my machine... 20 years ago. :-)

After Tommy's first reply, I did some reading, and realized that since I have X and Y limits, configuring them as homing inputs as well would be trivial. And so it was, plus or minus a "+" or "-", here and there.

I think I never thought there was any point to having a true home, and really, I've gotten by without it until now. I hit the limit switches when jogging reasonably often, but they're soft-mounted, so it's not a big deal.

In any case, I'm fully configured with home+limits on X and Y now, and I have proper soft limits configured, so I'm all set. <Another high five!>

Secondary question: I don't have a Z+ limit switch. My mill is so slow I'd really have to not be paying attention for the carriage to get close to the stepper. A lower limit would be nice, but I really don't understand how that could work. My spindle is a router, so the bit length varies a lot. Is there any way to configure this to work? I see people say that they don't bother with a lower Z limit, and just rely on a soft limit there, but what would you set it to? Is there something about "real" spindles that I don't know? Are the bits always the same length?
  • FPM
  • FPM
18 Apr 2025 12:01 - 18 Apr 2025 12:03
Replied by FPM on topic converting a tos/intos fngj 40

converting a tos/intos fngj 40

Category: Milling Machines

I connected the 7i77 to p1 and the 7i78 to p2, i assume this is the correct order.
I've tried to modify the hal so that the z-Axis is the stepper connected to the first interface of the 7i78. The encoder for the z-axis is connected to the 7i77. Is this more or less done correctly? (hal is attached).
Since the 7i78 has no enable signals for the steppers, is it possible to use the enable pin from the spindle, since i am not using this? and how do i need to mod the hal?
Thanks! 

File Attachment:

File Name: intos.hal
File Size:10 KB
  • theslawek
  • theslawek
18 Apr 2025 03:38

Need help making rotary axis behave like second spindle

Category: Advanced Configuration

Adding MAX_REVERSE_VELOCITY did the trick for M4 commands. Thanks.

Yes, I do have an abrupt stop with M5 $1, completely ignoring my acceleration parameters. I wonder if there would be any benefit in disabling my stepper motor driver (cheap DM542T) just as the M5 is issued. On one hand, the freewheeling could be more harmful than the coil being energized hard to stop, but on the other hand if the workpiece is delicate, freewheeling for however short of time as it can give it a better chance of survival.

If it's still a bug and 2748 is closed, is there a newer issue open? Does someone have a patch perhaps? Is this my opportunity to dive into the code? 
  • spumco
  • spumco
18 Apr 2025 02:00

Determining Angular Scale - Help w/ Microsteps

Category: Configuration Tools

So it looks like the drive is software-configurable.

I'd suggest going back to basics and connecting the drive to a Windows PC and verifying all the drive settings via the drive tuning software.

SIDE NOTE: make sure the motor's encoder count (1000/4000) matches what the drive is expecting.

Set the dip switches to 'software' (i.e. all ON). The reason is that you can (probably) set the microsteps to a useful number in software and are not limited to one of the 200/800/1600/etc values as with dip switches.

This will allow you to set the microstepping to a value that makes the steps per spindle rev a whole number, making the math for LCNC much easier.
Since LCNC's rotary axes units are set in INI [TRAJ] ANGULAR_UNITS = DEGREES, you need the [JOINT_N] STEP_SCALE to be in steps per degree.

For a 3:1 belt reduction and a 1.8deg motor, if you set the microsteps to 2400/rev (12x microsteps), you will wind up with 20 steps per spindle degree.

If you find that 12x is too fine and the positional accuracy is kinda 'ish', you can go down to 1200/rev (6x) and adjust INI to 10 steps per degree.  That might give the drive a bit more of a chance to hit a particular position rather than somewhere close-ish on either side of the target.  Either way you're still below the encoder's resolution so the drive isn't going to be totally guessing on a position.

And while you're in there, you should adjust the drive's following error tolerance.  I've found that Stepperonline's drives have a following error alarm set extremely high.  As in the motor could be 1/2 a full rotation out of position before it alarms out - not OK for CNC use.
  • sajurcaju
  • sajurcaju
17 Apr 2025 18:48
Odd estop problem was created by sajurcaju

Odd estop problem

Category: General LinuxCNC Questions

My machine is self designed/built, 3 axis wood router. 2.2kW spindle, conventional steppers, LinuxCNC 2.9something, LMDE6.
G540 motor driver at 48V, software stepping with parallel port(s).

My estop circuit is really simple, there is a NC emergency stop switch with a 5k pullup. For the past couple of months, estop has been randomly triggered with no cause I've been able to find. It could happen in 10 seconds after motion enable, it could run for an hour before being triggered. I can enable LinuxCNC and watch it, 10 seconds to 10 minutes (i.e. random) and it will go into estop, with the motors powered (locked) but not moving.

Estop randomly triggering will only happen when either at least one motor is connected to the g540, or a heavy resistive load (15 Ohms, 2x across where the stepper coils would be). With no load on the g540 estop will stay off. I have looked at the power supply voltages, they are fine during an estop event (using a DVM, not looking for a transient with a scope).

The machine has been working fine before this. The only things I can think of that I've done to the setup:
1. Fried one of the outputs on the motherboard parallel port. Now I have 3 parallel ports, two PCI cards and the motherboard. I'm only using the two PCI cards, but the motherboard parallel is still visible to the system.
2. Replaced the estop cable (!) with nicer wire.

What I've tried:
1. Replaced the estop cable again. I realized that the first replacement was no longer twisted pair. I replaced it again with shielded cable, shield connected at the box containing the g540 and power supplies. Interference seems unlikely since the switch is a short.
2. Cleaned the switch contacts, which didn't help. Jumpered the switch, which didn't help.
3. Removed the C10 breakout board. One parallel port goes directly to the g540, the other went to the C10. There were only two switches connected to the C10, the estop (!) and the electrical touch probe, I just hardwired them to the parallel port. Appeared to greatly improve the problem (a lot longer between estops), but now it's back to 10 sec - 10 min.
4. Greatly improved cooling on the g540.

I don't really see how the g540 can be causing this estop problem. The only estop connection to the g540 is estop OUT from the computer. Symptoms, however, seem like the g540 has something to do with it. I did check the 48V is rock steady through an estop. Note that the g540 stays powered up (motors still powered) when an estop happens. I can reset the estop and it will be fine again for 10 sec 10 min. This doesn't sound like a thermal problem.

Any advice?
Thanks, Steve

 
  • theslawek
  • theslawek
09 Apr 2025 17:45

Need help making rotary axis behave like second spindle

Category: Advanced Configuration

I have a turning application that's better suited towards a constant RPM on the rotary. I have my A axis functioning fine right now with position control.

I'd love to be able to just issue a M3 S1000 $1 instead of playing with the inverse time mode approaches.

I've searched the forum and tried several things without luck. Honestly, anything HAL related is an instant headache nightmare for me. Believe it or not, I'm an embedded programmer and did ladder logic in college, but the HAL stuff just does NOT click for me. I'd be willing to pay for someone's time to figure this out for me. I have a project for my church that is way behind.

I'm using Probe Basic for the GUI. I'd be willing to give up some GUI control as long as I can issue gcode commands.

Attached are my current INI and primary HAL.

Tried: 
- Changing control_type from 1 to 0, but had no idea what else to do
- Considered the rosekins but that doesn't really apply to my needs

Other forum posts I've read:
C Axis as Second Spindle - LinuxCNC
Using A axis as second spindle with stepper motor - LinuxCNC
Lathe spindle question turning and milling. - LinuxCNC

Thank you.
  • irwinger
  • irwinger
03 Apr 2025 20:40

Spindle control not showing in Axis window...

Category: Basic Configuration

Coming back to my CNC wood router after a good year off (controller PC hard drive died and I got busy renovating my house). I have a new hard drive, doubled the memory (16G), fresh and latest install downloaded last week from here (linuxcnc.org) and I have everything back 'moving and stopping'... except the spindle.

I have an old TB6560 3-axis, chinese controller board (Wantai) driven from my parallel port. It has the outputs for the 3 axes (yes - that is plural for axis - I looked it up) and a spindle on/off control output that I use to control a relay that switches the 120VAC to the Dewalt router.

Back in the 'old days' (when this system worked), there was a section just below the jog/home/tool touchoff buttons where I could turn the spindle on and off. It's not there any more. I've been trying to use Google Gemini and ChatGPT for help (and they are surprisingly helpful if the question is worded well), but I'm just not getting it to work.

I'm using steppers and configured my pins using StepConf. I set the pin for the spindle as parallel port pin 9. But I'm not seeing a [SPINDLE] section in the .ini file nor am I seeing any spindle references in the .HAL file. I can't control the spindle speed (it's a router), only whether it's on or off.

Anyone out there with a good idea of where to start?

Thanks
Arden
  • ffffrf
  • ffffrf
03 Apr 2025 00:56

Using a servo as a spindle and positional axis - keep getting vague errors

Category: Advanced Configuration

Hello,

  I have a little lathe that was originally using a bldc motor. I wanted to change it out with a servo motor and use it both in positional mode, but also with turning. I went through the basic configurations in pncconf using my mesa 7i96s and got it to work as a turning machine with a stepgen spindle. 

  I read about the possibility of using mux2 to switch between the two modes but I am stuck getting strange errors like command 176, etc. I cant figure out how to debug or what I need to change in my INI and HAL (I have two hal files I am using). I am wondering if someone could look over my files and see if I am missing something obvious? I keep staring at it and am getting nowhere...

I config'd it as an XZ lathe with stepgen spindle originally. I have to HAL files I use: C+turning and the mux HAL

My current issue is as follows: The program compiles and opens. I then home axis, which causes my X and Z axis to home. I can now move those freely. However, when I go to try and move the C axis, I get "error on joint 2" and on terminal it just gives all sorts of "command" errors that I cant seem to debug further. Has anyone experienced this?

Main HAL:
# Generated by PNCconf at Wed Apr  2 16:24:00 2025
# Using LinuxCNC version:  Master (2.9)
# If you make changes to this file, they will be
# overwritten when you run PNCconf again

loadrt [KINS]KINEMATICS
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS
loadrt hostmot2
loadrt hm2_eth board_ip="10.10.10.10" config="num_encoders=1 num_pwmgens=1 num_stepgens=5 sserial_port_0=0xxxxxxx" 
setp    hm2_7i96s.0.pwmgen.pwm_frequency 20000
setp    hm2_7i96s.0.pwmgen.pdm_frequency 6000000
setp    hm2_7i96s.0.watchdog.timeout_ns 5000000
loadrt pid names=pid.x,pid.z,pid.s,pid.c
loadrt near

addf hm2_7i96s.0.read          servo-thread
addf motion-command-handler   servo-thread
addf motion-controller        servo-thread
addf pid.x.do-pid-calcs       servo-thread
addf pid.z.do-pid-calcs       servo-thread
addf pid.s.do-pid-calcs       servo-thread
addf pid.c.do-pid-calcs servo-thread
addf near.0                   servo-thread
addf hm2_7i96s.0.write         servo-thread
setp hm2_7i96s.0.dpll.01.timer-us -50
setp hm2_7i96s.0.stepgen.timer-number 1

# external output signals

# --- X-ENABLE ---
net x-enable  =>     hm2_7i96s.0.ssr.00.out-00

# --- Z-ENABLE ---
net z-enable  =>     hm2_7i96s.0.ssr.00.out-01


# external input signals

# --- MIN-HOME-X ---
net min-home-x     <=  hm2_7i96s.0.inm.00.input-00-not

# --- MAX-HOME-Z ---
net max-home-z     <=  hm2_7i96s.0.inm.00.input-01-not

# --- ESTOP-EXT ---
net estop-ext     <=  hm2_7i96s.0.inm.00.input-02


#*******************
#  AXIS X JOINT 0
#*******************

setp   pid.x.Pgain     [JOINT_0]P
setp   pid.x.Igain     [JOINT_0]I
setp   pid.x.Dgain     [JOINT_0]D
setp   pid.x.bias      [JOINT_0]BIAS
setp   pid.x.FF0       [JOINT_0]FF0
setp   pid.x.FF1       [JOINT_0]FF1
setp   pid.x.FF2       [JOINT_0]FF2
setp   pid.x.deadband  [JOINT_0]DEADBAND
setp   pid.x.maxoutput [JOINT_0]MAX_OUTPUT
setp   pid.x.error-previous-target true
# This setting is to limit bogus stepgen
# velocity corrections caused by position
# feedback sample time jitter.
setp   pid.x.maxerror 0.012700

net x-index-enable  =>  pid.x.index-enable
net x-enable        =>  pid.x.enable
net x-pos-cmd       =>  pid.x.command
net x-pos-fb        =>  pid.x.feedback
net x-output        <=  pid.x.output

# Step Gen signals/setup

setp   hm2_7i96s.0.stepgen.00.dirsetup        [JOINT_0]DIRSETUP
setp   hm2_7i96s.0.stepgen.00.dirhold         [JOINT_0]DIRHOLD
setp   hm2_7i96s.0.stepgen.00.steplen         [JOINT_0]STEPLEN
setp   hm2_7i96s.0.stepgen.00.stepspace       [JOINT_0]STEPSPACE
setp   hm2_7i96s.0.stepgen.00.position-scale  [JOINT_0]STEP_SCALE
setp   hm2_7i96s.0.stepgen.00.step_type        0
setp   hm2_7i96s.0.stepgen.00.control-type     1
setp   hm2_7i96s.0.stepgen.00.maxaccel         [JOINT_0]STEPGEN_MAXACCEL
setp   hm2_7i96s.0.stepgen.00.maxvel           [JOINT_0]STEPGEN_MAXVEL
setp   hm2_7i96s.0.stepgen.00.step.invert_output   true

# ---closedloop stepper signals---

net x-pos-cmd    <= joint.0.motor-pos-cmd
net x-vel-cmd    <= joint.0.vel-cmd
net x-output     => hm2_7i96s.0.stepgen.00.velocity-cmd
net x-pos-fb     <= hm2_7i96s.0.stepgen.00.position-fb
net x-pos-fb     => joint.0.motor-pos-fb
net x-enable     <= joint.0.amp-enable-out
net x-enable     => hm2_7i96s.0.stepgen.00.enable

# ---setup home / limit switch signals---

net min-home-x     =>  joint.0.home-sw-in
net min-home-x     =>  joint.0.neg-lim-sw-in
net x-pos-limit     =>  joint.0.pos-lim-sw-in

#*******************
#  AXIS Z JOINT 1
#*******************

setp   pid.z.Pgain     [JOINT_1]P
setp   pid.z.Igain     [JOINT_1]I
setp   pid.z.Dgain     [JOINT_1]D
setp   pid.z.bias      [JOINT_1]BIAS
setp   pid.z.FF0       [JOINT_1]FF0
setp   pid.z.FF1       [JOINT_1]FF1
setp   pid.z.FF2       [JOINT_1]FF2
setp   pid.z.deadband  [JOINT_1]DEADBAND
setp   pid.z.maxoutput [JOINT_1]MAX_OUTPUT
setp   pid.z.error-previous-target true
# This setting is to limit bogus stepgen
# velocity corrections caused by position
# feedback sample time jitter.
setp   pid.z.maxerror 0.012700

net z-index-enable  =>  pid.z.index-enable
net z-enable        =>  pid.z.enable
net z-pos-cmd       =>  pid.z.command
net z-pos-fb        =>  pid.z.feedback
net z-output        <=  pid.z.output

# Step Gen signals/setup

setp   hm2_7i96s.0.stepgen.01.dirsetup        [JOINT_1]DIRSETUP
setp   hm2_7i96s.0.stepgen.01.dirhold         [JOINT_1]DIRHOLD
setp   hm2_7i96s.0.stepgen.01.steplen         [JOINT_1]STEPLEN
setp   hm2_7i96s.0.stepgen.01.stepspace       [JOINT_1]STEPSPACE
setp   hm2_7i96s.0.stepgen.01.position-scale  [JOINT_1]STEP_SCALE
setp   hm2_7i96s.0.stepgen.01.step_type        0
setp   hm2_7i96s.0.stepgen.01.control-type     1
setp   hm2_7i96s.0.stepgen.01.maxaccel         [JOINT_1]STEPGEN_MAXACCEL
setp   hm2_7i96s.0.stepgen.01.maxvel           [JOINT_1]STEPGEN_MAXVEL
setp   hm2_7i96s.0.stepgen.01.step.invert_output   true

# ---closedloop stepper signals---

net z-pos-cmd    <= joint.1.motor-pos-cmd
net z-vel-cmd    <= joint.1.vel-cmd
net z-output     => hm2_7i96s.0.stepgen.01.velocity-cmd
net z-pos-fb     <= hm2_7i96s.0.stepgen.01.position-fb
net z-pos-fb     => joint.1.motor-pos-fb
net z-enable     <= joint.1.amp-enable-out
net z-enable     => hm2_7i96s.0.stepgen.01.enable

# ---setup home / limit switch signals---

net max-home-z     =>  joint.1.home-sw-in
net z-neg-limit     =>  joint.1.neg-lim-sw-in
net max-home-z     =>  joint.1.pos-lim-sw-in


#*******************
#  AXIS C JOINT 2
#*******************
setp   pid.c.Pgain     [JOINT_2]P
setp   pid.c.Igain     [JOINT_2]I
setp   pid.c.Dgain     [JOINT_2]D
setp   pid.c.bias      [JOINT_2]BIAS
setp   pid.c.FF0       [JOINT_2]FF0
setp   pid.c.FF1       [JOINT_2]FF1
setp   pid.c.FF2       [JOINT_2]FF2
setp   pid.c.deadband  [JOINT_2]DEADBAND
setp   pid.c.maxoutput [JOINT_2]MAX_OUTPUT
setp   pid.c.error-previous-target true
setp   pid.c.maxerror 0.012700

net c-index-enable  =>  pid.c.index-enable
net c-axis-pos-cmd => pid.c.command
net c-pos-fb        =>  pid.c.feedback
net c-output        <=  pid.c.output

# ---closedloop stepper setup---

net c-vel-cmd    <= joint.2.vel-cmd
net c-output     => hm2_7i96s.0.stepgen.04.velocity-cmd
net c-pos-fb     <= hm2_7i96s.0.stepgen.04.position-fb
net c-pos-fb     => joint.2.motor-pos-fb
net c-enable     <= joint.2.amp-enable-out
net spindle-enable => pid.c.enable



#*******************
#  SPINDLE
#*******************

setp   pid.s.Pgain     [SPINDLE_0]P
setp   pid.s.Igain     [SPINDLE_0]I
setp   pid.s.Dgain     [SPINDLE_0]D
setp   pid.s.bias      [SPINDLE_0]BIAS
setp   pid.s.FF0       [SPINDLE_0]FF0
setp   pid.s.FF1       [SPINDLE_0]FF1
setp   pid.s.FF2       [SPINDLE_0]FF2
setp   pid.s.deadband  [SPINDLE_0]DEADBAND
setp   pid.s.maxoutput [SPINDLE_0]MAX_OUTPUT
setp   pid.s.error-previous-target true
# This setting is to limit bogus stepgen
# velocity corrections caused by position
# feedback sample time jitter.
setp   pid.s.maxerror 0.012700

net spindle-index-enable  =>  pid.s.index-enable
net spindle-enable        =>  pid.s.enable
net spindle-vel-cmd-rpm     => pid.s.command
net spindle-vel-fb-rpm      => pid.s.feedback
net spindle-output        <=  pid.s.output

# Step Gen signals/setup

setp   hm2_7i96s.0.stepgen.04.dirsetup        [SPINDLE_0]DIRSETUP
setp   hm2_7i96s.0.stepgen.04.dirhold         [SPINDLE_0]DIRHOLD
setp   hm2_7i96s.0.stepgen.04.steplen         [SPINDLE_0]STEPLEN
setp   hm2_7i96s.0.stepgen.04.stepspace       [SPINDLE_0]STEPSPACE
setp   hm2_7i96s.0.stepgen.04.position-scale  [SPINDLE_0]STEP_SCALE
setp   hm2_7i96s.0.stepgen.04.step_type        0
setp   hm2_7i96s.0.stepgen.04.control-type     1
setp   hm2_7i96s.0.stepgen.04.maxaccel         [SPINDLE_0]STEPGEN_MAXACCEL
setp   hm2_7i96s.0.stepgen.04.maxvel           [SPINDLE_0]STEPGEN_MAXVEL
setp   hm2_7i96s.0.stepgen.04.step.invert_output   true

#net machine-is-on           =>  hm2_7i96s.0.stepgen.04.enable
#net spindle-vel-cmd-rps     =>  hm2_7i96s.0.stepgen.04.velocity-cmd
# ---Encoder feedback signals/setup---

setp    hm2_7i96s.0.encoder.00.counter-mode 0
setp    hm2_7i96s.0.encoder.00.filter 1
setp    hm2_7i96s.0.encoder.00.index-invert 0
setp    hm2_7i96s.0.encoder.00.index-mask 0
setp    hm2_7i96s.0.encoder.00.index-mask-invert 0
setp    hm2_7i96s.0.encoder.00.scale  [SPINDLE_0]ENCODER_SCALE

net spindle-revs             <=   hm2_7i96s.0.encoder.00.position
net spindle-vel-fb-rps       <=   hm2_7i96s.0.encoder.00.velocity
net spindle-vel-fb-rpm       <=   hm2_7i96s.0.encoder.00.velocity-rpm
net spindle-index-enable     <=>  hm2_7i96s.0.encoder.00.index-enable

# ---setup spindle control signals---

net spindle-vel-cmd-rps        <=  spindle.0.speed-out-rps
net spindle-vel-cmd-rps-abs    <=  spindle.0.speed-out-rps-abs
net spindle-vel-cmd-rpm        <=  spindle.0.speed-out
net spindle-vel-cmd-rpm-abs    <=  spindle.0.speed-out-abs
net spindle-enable             <=  spindle.0.on
net spindle-cw                 <=  spindle.0.forward
net spindle-ccw                <=  spindle.0.reverse
net spindle-brake              <=  spindle.0.brake
net spindle-revs               =>  spindle.0.revs
net spindle-at-speed           =>  spindle.0.at-speed
net spindle-vel-fb-rps         =>  spindle.0.speed-in
net spindle-index-enable      <=>  spindle.0.index-enable

# ---Setup spindle at speed signals---

net spindle-vel-cmd-rps    =>  near.0.in1
net spindle-vel-fb-rps         =>  near.0.in2
net spindle-at-speed       <=  near.0.out
setp near.0.scale 1.000000
setp near.0.difference 3.333333


#******************************
# connect miscellaneous signals
#******************************

#  ---HALUI signals---

net axis-select-x  halui.axis.x.select
net jog-x-pos      halui.axis.x.plus
net jog-x-neg      halui.axis.x.minus
net jog-x-analog   halui.axis.x.analog
net x-is-homed     halui.joint.0.is-homed
net axis-select-z  halui.axis.z.select
net jog-z-pos      halui.axis.z.plus
net jog-z-neg      halui.axis.z.minus
net jog-z-analog   halui.axis.z.analog
net z-is-homed     halui.joint.1.is-homed
net jog-selected-pos      halui.axis.selected.plus
net jog-selected-neg      halui.axis.selected.minus
net spindle-manual-cw     halui.spindle.0.forward
net spindle-manual-ccw    halui.spindle.0.reverse
net spindle-manual-stop   halui.spindle.0.stop
net machine-is-on         halui.machine.is-on
net jog-speed             halui.axis.jog-speed
net MDI-mode              halui.mode.is-mdi

#  ---coolant signals---

net coolant-mist      <=  iocontrol.0.coolant-mist
net coolant-flood     <=  iocontrol.0.coolant-flood

#  ---probe signal---

net probe-in     =>  motion.probe-input

#  ---motion control signals---

net in-position               <=  motion.in-position
net machine-is-enabled        <=  motion.motion-enabled

#  ---digital in / out signals---

#  ---estop signals---

net estop-out     <=  iocontrol.0.user-enable-out
net estop-ext     =>  iocontrol.0.emc-enable-in

#  ---manual tool change signals---

net tool-change-request    <= iocontrol.0.tool-change
net tool-change-confirmed  => iocontrol.0.tool-changed
net tool-number            <= iocontrol.0.tool-prep-number

#  ---Use external manual tool change dialog---

loadusr -W hal_manualtoolchange
net tool-change-request    =>  hal_manualtoolchange.change
net tool-change-confirmed  <=  hal_manualtoolchange.changed
net tool-number            =>  hal_manualtoolchange.number

#  ---ignore tool prepare requests---
net tool-prepare-loopback   iocontrol.0.tool-prepare      =>  iocontrol.0.tool-prepared

Auxillary HAL
# Include your custom HAL commands here
# This file will not be overwritten when you run PNCconf again
loadrt mux2 count=1
addf mux2.0 servo-thread

# Mux inputs
net c-axis-pos-cmd joint.2.motor-pos-cmd => mux2.0.in0
net spindle-vel-cmd-rpm    => mux2.0.in1


net spindle-enable            => mux2.0.sel
net spindle-enable => hm2_7i96s.0.stepgen.04.enable

# Mux output to stepgen.04
net mux-out mux2.0.out => hm2_7i96s.0.stepgen.04.position-cmd


# Feedback and enable
net c-pos-fb <= hm2_7i96s.0.stepgen.04.position-fb
net c-pos-fb => joint.2.motor-pos-fb

INI FILE
# Generated by PNCconf at Wed Apr  2 16:24:00 2025
# Using LinuxCNC version:  Master (2.9)
# If you make changes to this file, they will be
# overwritten when you run PNCconf again

[EMC]
MACHINE = Turn+C_lathe
DEBUG = 0
VERSION = 1.1

[DISPLAY]
DISPLAY = axis
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
MAX_FEED_OVERRIDE = 2.000000
MAX_SPINDLE_OVERRIDE = 1.000000
MIN_SPINDLE_OVERRIDE = 0.500000
INTRO_GRAPHIC = linuxcnc.gif
INTRO_TIME = 5
PROGRAM_PREFIX = /home/maksym/linuxcnc/nc_files
PYVCP = pyvcp-panel.xml
INCREMENTS = 5mm 1mm .5mm .1mm .05mm .01mm .005mm
LATHE = 1
POSITION_FEEDBACK = ACTUAL
DEFAULT_LINEAR_VELOCITY = 13.333333
MAX_LINEAR_VELOCITY = 41.666667
MIN_LINEAR_VELOCITY = 0.500000
DEFAULT_ANGULAR_VELOCITY = 12.000000
MAX_ANGULAR_VELOCITY = 180.000000
MIN_ANGULAR_VELOCITY = 1.666667
EDITOR = gedit
GEOMETRY = xyz
CYCLE_TIME = 100

[FILTER]
PROGRAM_EXTENSION = .png,.gif,.jpg Greyscale Depth Image
PROGRAM_EXTENSION = .py Python Script
png = image-to-gcode
gif = image-to-gcode
jpg = image-to-gcode
py = python

[TASK]
TASK = milltask
CYCLE_TIME = 0.010

[RS274NGC]
PARAMETER_FILE = linuxcnc.var
RS274NGC_STARTUP_CODE = G21 G40 G90 G94 G97 G64 P0.025

[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
SERVO_PERIOD = 1000000

[HMOT]
# **** This is for info only ****
CARD0=hm2_7i96s.0

[HAL]
HALUI = halui
HALFILE = Turn+C_lathe.hal
HALFILE = c_axis_mux.hal
HALFILE = custom.hal
POSTGUI_HALFILE = custom_postgui.hal
SHUTDOWN = shutdown.hal

[HALUI]

[KINS]
JOINTS = 3
KINEMATICS = trivkins coordinates=XZC

[TRAJ]
COORDINATES =  XZC
LINEAR_UNITS = mm
ANGULAR_UNITS = degree
DEFAULT_LINEAR_VELOCITY = 4.17
MAX_LINEAR_VELOCITY = 41.67
NO_FORCE_HOMING = 1

[EMCIO]
EMCIO = io
CYCLE_TIME = 0.100
TOOL_TABLE = tool.tbl

#******************************************
[AXIS_X]
MAX_VELOCITY = 41.666666666666664
MAX_ACCELERATION = 500.0
MIN_LIMIT = -0.0
MAX_LIMIT = 100.0

[JOINT_0]
TYPE = LINEAR
HOME = 20.0
FERROR = 10.0
MIN_FERROR = 1.0
MAX_VELOCITY = 41.666666666666664
MAX_ACCELERATION = 500.0
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 52.08
STEPGEN_MAXACCEL = 625.00
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
# these are in nanoseconds
DIRSETUP   = 10000
DIRHOLD    = 10000
STEPLEN    = 10000
STEPSPACE  = 10000
STEP_SCALE = -800.0
MIN_LIMIT = -0.0
MAX_LIMIT = 100.0
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = -13.333333
HOME_LATCH_VEL = -0.500000
HOME_FINAL_VEL = 5.000000
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE = 2
#******************************************

#******************************************
[AXIS_Z]
MAX_VELOCITY = 25.0
MAX_ACCELERATION = 750.0
MIN_LIMIT = -432.0
MAX_LIMIT = 0.0

[JOINT_1]
TYPE = LINEAR
HOME = -20.0
FERROR = 10.0
MIN_FERROR = 1.0
MAX_VELOCITY = 25.0
MAX_ACCELERATION = 750.0
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 31.25
STEPGEN_MAXACCEL = 937.50
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
# these are in nanoseconds
DIRSETUP   = 10000
DIRHOLD    = 10000
STEPLEN    = 10000
STEPSPACE  = 10000
STEP_SCALE = 800.0
MIN_LIMIT = -432.0
MAX_LIMIT = 0.0
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = -13.333333
HOME_LATCH_VEL = -0.500000
HOME_FINAL_VEL = 5.000000
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE = 1
#******************************************
#******************************************
[AXIS_C]
MAX_VELOCITY = 360
MAX_ACCELERATION = 720
MIN_LIMIT = -999999
MAX_LIMIT = 999999
ANGULAR = 1

[JOINT_2]
TYPE = ANGULAR
HOME = 0
FERROR = 5
MIN_FERROR = 1.0
MAX_VELOCITY = 360
MAX_ACCELERATION = 720
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 400
STEPGEN_MAXACCEL = 800
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
# these are in nanoseconds
DIRSETUP   = 10000
DIRHOLD    = 10000
STEPLEN    = 5000
STEPSPACE  = 5000
STEP_SCALE = 27.77778
HOME_SEQUENCE = 0

[SPINDLE_0]
MAX_VELOCITY = 3.3333333333333335
MAX_ACCELERATION = 300.0
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 4.17
STEPGEN_MAXACCEL = 375.00
P = 0.0
I = 0.0
D = 0.0
FF0 = 1.0
FF1 = 0.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 2000.0
ENCODER_SCALE = 8000.0
# these are in nanoseconds
DIRSETUP   = 10000
DIRHOLD    = 10000
STEPLEN    = 5000
STEPSPACE  = 5000
STEP_SCALE = -1000.0
Displaying 16 - 30 out of 154 results.
Time to create page: 0.599 seconds
Powered by Kunena Forum