Advanced Search

in the near future. The stepper-ninja hal driver run in the servo-thread so the minimum width of one input is 1 servo thread refresh in length, with 1KHz servo-thread its 1mS, something like this: when you see a ruler, all 1mm division represents a servo thread cycle, the signal only starts in the divisions and only end on the divisions. With low spindle speed its probably working, but if you want better threading you use printer port for the lathe spindle encoder.

Hi All,I’d like your input on my planned setup.
As I mentioned in my previous post, the latency on my new machine was so high that I had to switch from the parallel port to a Mesa card. Earlier this week, I received a Mesa 7i76EU board. It looks awesome—if a bit overwhelming at first glance!My plan:

• Motors:
  I’m using 3x Longs DM542A stepper drivers, which I plan to connect to Stepper 0/1/2 outputs on the Mesa board, using what I believe is called a “single-ended” wiring configuration. My plan is to connect +5V to the ENA+, DIR+, and STEP+ on each driver, and wire the ENA (5V), DIR-, and STEP- of each driver directly to the corresponding outputs on the Mesa card.
• Spindle:
  I have a Huanyang VFD 1.5KW for spindle control. For now, I’ll keep my Modbus-over-USB setup, which seems to work well enough. I’ve read that getting Modbus running directly on the Mesa board requires a bit more advanced configuration, so I’ll save that for later.
• Homing Sensors (Capacitive, 3x):
  My plan is to connect the +24V supply to the positive (brown) wire, and field ground to the negative (blue) wire of each sensor. I intend to connect the sensor output (black) wires to Input 1, 2, and 3 on the Mesa card.

Questions:

1. Current-limiting resistor for home sensors:
   For the capacitive homing sensors, do I need to add a resistor between the output pin of the sensor and the Mesa input to protect against overcurrent? In the past, I’ve blown a few sensors and started using resistors to protect them, but those were cheap sensors—the Mesa card isn’t!
2. 2-wire touch probe:
   For my two-wire touch-off probe, I plan to connect one side to +24V field power and the signal wire to Input 4. Here too, should I add a resistor to avoid potential shorts or overcurrent situations?

Bonus questions:

• Any recommendations for best practices when wiring sensors and stepper drivers to the Mesa 7i76EU?
• Are there things I should definitely avoid to protect my Mesa card or improve reliability?
• For those who have set up Modbus on the Mesa board, how steep is the learning curve compared to using Modbus over USB?

Thanks for your advice and experiences!

Hi, I my name is Chrstian and I tend to read more on forums than to write. But as many others I am in some kind of a dead end and could use some advice...

Backstory:
I bought an used self build CNC Router. The controls were build around an USB Smooth Stepper and Mach3. Since the controls are not repair friendly (too much stuff packed in too little space with custom layout boards and same color wires) and I am more a Linux than a Windows guy, I am in the process to upgrade to LinuxCNC.

I use an 7i92 and an 7i76

One of the last steps missing is the spindle control (1,5kw china spindle with ER16). For some reason the person, who built the router went with an "Lenze 822MV" 400V 2,2kw VFD.

After the long introduction, my question:
Where can I get my 10V reference (Spindle +) from this VFD? If someone might take a look and give me a hint, I would appreciate it.

The manual for the "Application IO Module" that is used, can be found here: www.becker-antriebstechnik.org/WebRoot/H...__v6-0__DE_EN_FR.pdf
(page 21 starts the english description)

The manual for the actual VFD (should not matter that much, just in case):https://www.lenze.com/en-de/products/inverters/previous-products-inverters/8200-motec

Currently connections A1, 2x7 (GND), 59, 28 and 2U are connected. I have absolutely no Idea where they go to...

In case the VFD does not have an 10V reference voltage, what are my options? Do the cheap 20€ 4channel 2,5V, 5V, 7.5V, 10V reference voltage things from ebay work?
Am I missing something?

Thanks in advance for the help (and all the help I got from the forum without having to ask).

Christian aka TheRealMable

I wouldn’t mind rewiring everything — my setup is quite simple, and the CNC machine is fairly small. For me, building and tweaking the CNC is part of the fun of the hobby.

I’ve read that many of you use various Mesa cards. I was hoping the 7i76EU alone would be a good starting point to learn how to work with Mesa hardware. Do you know if that’s the case? I saw some brutal shipment costs (like 200 dollar plus, so i will have to search for an European supplier, i'm in the Netherlands)

If the 7i76EU would allow me to completely move away from the parallel port, that would be a big plus — especially since I’m currently limited by base-thread latency.

[EDIT]

I see a seller with reasonable shipping costs, not sure if its a trusted compane EUSurplus?I think i am planning to switch to a Mesa board and wanted to check if the 7i76EU is the right fit for my setup. This is what I’m working with:

• 3x DM542A stepper drivers (they use step/dir signals)
• 3x LJ12A3-4-Z/BY inductive proximity sensors (used for homing)
• 1x Huanyang VFD (spindle, controllable via 0–10V or RS-485 Modbus (I think because i now use it over USB)

From what I’ve researched, the Mesa 7i76EU seems like the best option. Here’s why:

• It supports up to 5 stepper/servo axes via step/dir signals (perfect for my DM542A drivers)
• It has 32 opto-isolated inputs which should work well with the 24V NPN homing sensors
• It has 16 outputs, which are configurable (sourcing/sinking)
• It includes an analog spindle output (0–10V) for VFD speed control
• It supports RS-485 communication if I decide to use Modbus for the Huanyang VFD
• It isolates field I/O power from logic power, which helps protect the system

Important to note:

• The sensors might need a pull-down resistor to give clean logic signals when connected to 24V. I already solderd a pc to convert the 30V signal back to a 5V system with opto's
• I will need to supply 24V field power to the board 
• I understand the 7i76EU requires a second Ethernet interface on my PC (either a second NIC or a USB↔Ethernet adapter)
• I still need a PREEMPT-RT kernel, but I won't have to worry about tight base-thread latency anymore

Does this sound correct to those of you with experience using this board?Thanks in advance!

 

Spyderbreath wrote:

Warning: Spoiler!

At the risk of the blind leading the blind, to me that is not quite the right question. That chart is for your micro-stepping. Like the 800 is 4 microsteps, if you're using a 1.8 deg. stepper. I have always looked at it this way - What are you doing with the motor? If your opening a door or driving a ram, picking 800 would be fine, but using that on a belt or lead screw may very well end up leaving artifacts in the work due to the rougher movement between points. The downside is the more micro-steps you have the more torque you lose. 3200 (16 micro-steps) seams to be a reasonable middle ground that most use as standard. The controller will put out as many steps as directed by LinuxCNC to make a revolution, just a matter of how fast it can do it. Whatever you chose, that gets figured out when you tell LinuxCNC in your .ini file how many pulses it takes to move one unit. That is set with the SCALE on each axis. Like for me, I have 16 micro-steps (3200) and a 5mm pitch screw, which works out to SCALE = 640 or -640 depending which way you need the motor to move.

 

Thanks for reply,
I have set 12800 and testing some gcode only with Y working.
I don't want to cause problems when all the stepper and spindle are physically working.

1. Normally csp I would say. For a spindle motor csv.
2. I prefer to send position in machine units to cia402 and do the scaling closer to the drive. But that's just me.
3. lcec comes from here github.com/linuxcnc-ethercat/linuxcnc-ethercat and there is a link in there to a reference guide. Unfortunately it doesn't cover sdo uploads. But it's done like this. Example comes from one of my ect60 stepper motor drivers.The sdoDataRaw has some quirks. First you must enter 4 bytes for a 32-bit variable, 2 bytes for 16 bit and 1 for 8 bit.
Note the byte order, 4000 which is hex 0x0fa0 is entered as "a0 0f". 100 (hex 0x64) is entered as "64 00",

Hello everyone,

So, I have this configuration:

• Main board is Mesa 7I76EU
• 7I76U connected to main board expansion header P1
• 7I89 connected to main board expansion header P2

Main board's +5V is connected to P5; +24V field power - to TB1.
Actually, never mind, main 7I76EU is not a problem, it works, everything's detected, steppers are moving, spindle/spindle encoder are working, MPG is working.

Now, expansion 7I76U (on P1 header) is indicating communication failure (red led in the middle of te board). It doesn't show up in halconfig (should it?). Field power is there, cable power from main board is there.

For 7I89 I see all 8 encoders, but encoder inputs do not react to signals from encoders. None of the encoder input-a/input-b/rawcounts change despite the fact that physical signals from encoders are. Encoders are TTL and so 7I89 is jumpered accordingly.
+5V power to 7I89 is connected to its P1 and cable power from 7I76EU is activated as well (per 7I89 manual). Encoders are powered and working just fine (checked with oscilloscope).

Firmware I load is from mesa website: 7i76eu_7i76x1_7i88_7i89d.bin
It is somewhat strange as its 7i76eu_7i76x1_7i88_7i89d.pin file has stepgens 10/11 where 7I76U (P1) should have Sserial and it also has Sserial where should be MuxedQCount (spindle encoder). Basically I/O for DB25 pins 7-13 is all wrong for 7I76U.
Probably that's why my 7I76 doesn't work.

I'm afraid to load firmware from post www.forum.linuxcnc.org/27-driver-boards/...7i89-firmware#240149
That one has all the right pinouts, but seem to be for older generation of 7I76 (Spartan FPGA?), not sure it will work for my 7I76EU (Efinix FPGA)
It also has clock high frequency set at 200MHz, while 7i76eu_7i76x1_7i88_7i89d.pin shows 160MHz.

How can I get out of this predicaments?
Can anybody help?

Yes, to swap a tool for another tool that is the case, but my spindle was empty.

The carousel needs to move away to give clearance to the Z assembly during probing. Otherwise the probe can't reach X0 without the Z assembly running into the carousel.

If I would place the probe on the left side of the spindle, possibly the carousel wouldn't need to move away, only when it needs to swap for the toolsetter.

But the consequence would be not having full probing range on the end of X axis (without extending the gantry), which maybe isn't really an issue.
But I would need to find a way to block the spindle from going into the carousel work area during 'non-toolchange' events.

For now I'll just accept the situation and carry on with the small delay, until I got the whole toolchange process sorted.

Im at the point now where the carousel extends, gets detected, spindle moves to clearance height, spindle unclamps the tool etc..
All 5 sensors are working, Carousel Home, Carousel Index, Carousel IN position, Carousel OUT position and the Spindle Tool Clamped and Tool Released sensors.

Now its time to program the final movements, placing and removing a tool from a pocket.
Will be a little different probably compared to other carousel toolchangers where the carousel moving in and out takes the tool from the spindle.

When no tool is loaded it has to move down, clamp the tool, moving to the right to take a tool from the pocket, carousel retract, spindle up again and resume.
Or with a loaded tool it has to move in front of the carousel, moving to the left into the pocket, unclamp, up, rotate to new tool, down again etc.

Should be fun, hopefully it won't get fooked. :-D

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.

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.

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.

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.

 

 
 

[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.

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