Advanced Search

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

pgf wrote:

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

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?

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! 

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?